Studi bahasa yang diketik secara dinamis vs statis [ditutup]

69

Apakah ada penelitian yang dilakukan pada keefektifan bahasa yang diketik secara statis vs dinamis?

Khususnya:

  • Pengukuran produktivitas programmer
  • Tingkat Cacat

Juga termasuk efek apakah pengujian unit digunakan atau tidak.

Saya telah melihat banyak diskusi tentang manfaat dari kedua belah pihak tetapi saya bertanya-tanya apakah ada orang yang telah melakukan penelitian tentang hal itu.

productivity comparison type-systems dynamic-typing static-typing Winston Ewert
sumber
8
@ Bigown, bagi saya sepertinya masalah produktivitas dan cacat tidak berhubungan dengan teori ilmu komputer
Winston Ewert
2
@ Winston: Mempelajari masalah seperti ini adalah tugas ilmuwan komputer, bukan pemrogram.
Maniero
9
@Bigown, ya ini masalah ilmu komputer tapi itu bukan masalah teori ilmu komputer. Teori CS pada dasarnya berkaitan dengan apa yang dapat kita buktikan secara matematis tentang program dan komputasi. Masalah produktivitas programmer bukanlah pertanyaan teori cs. Ada diskusi tentang pengetikan dinamis baik di sini maupun di stackoverflow. Tidak ada satu pun di cstheory.
Winston Ewert
8
Pertanyaannya sempurna pada topik. Pertanyaan ini membahas salah satu properti terpenting dari alat yang kami gunakan untuk memprogram.
Frank Shearar
4
@ Winston: Sistem pengetikan memang termasuk dalam teori CS, tetapi studi praktis tidak.
David Thornley

Jawaban:

42

Beberapa menyarankan membaca:

Tidak persis pada pengetikan statis, tetapi terkait:

Beberapa artikel atau esai yang menarik tentang subjek atau analisis statis program secara umum:

Dan bagi mereka yang bertanya-tanya tentang apa ini:

Namun, saya meragukan semua ini dengan memberi Anda jawaban langsung, karena mereka tidak melakukan studi yang Anda cari. Mereka akan menjadi bacaan yang menarik.

Sendiri, Saya dengan tegas mempertimbangkan bahwa pengetikan statis atas pengetikan dinamis memfasilitasi deteksi bug. Saya menghabiskan terlalu banyak mengetik mencari kesalahan ketik dan kesalahan kecil seperti ini ke dalam JavaScript atau bahkan kode Ruby. Dan ketika sampai pada pandangan bahwa Pengetikan Dinamis memberi Anda dorongan dalam produktivitas, saya pikir sebagian besar tergantung pada perkakas. Jika bahasa yang diketik secara statis memiliki alat yang tepat untuk memungkinkan kompilasi latar belakang dan menyediakan antarmuka REPL, maka Anda mendapatkan manfaat dari kedua dunia. Scala menyediakan ini misalnya, yang membuatnya sangat mudah untuk dipelajari dan prototipe di konsol interaktif, tetapi memberi Anda manfaat pengetikan statis (dan sistem jenis yang lebih kuat daripada banyak bahasa lain, selain ML-bahasa). Demikian pula, saya tidak berpikir saya kehilangan produktivitas dengan menggunakan Java atau C ++ (karena pengetikan statis), selama saya menggunakan IDE yang membantu saya. Ketika saya kembali ke pengkodean hanya dengan konfigurasi sederhana (editor + compiler / interpreter), maka rasanya bahasa yang lebih rumit dan dinamis sepertinya lebih mudah digunakan. Tapi Anda masih mencari bug. Saya kira orang akan mengatakan bahwa masalah perkakas adalah argumen yang dapat dibalikkan, seolah-olah perkakas lebih baik untuk bahasa yang dinamis, maka sebagian besar bug dan kesalahan ketik akan ditunjukkan pada waktu pengkodean, tetapi itu mencerminkan cacat pada sistem menurut pendapat saya. Namun, saya biasanya membuat prototipe di JRuby dan akan membuat kode di Jawa nanti sebagian besar hal yang saya lakukan. seolah-olah perkakas lebih baik untuk bahasa dinamis, maka sebagian besar bug dan kesalahan ketik akan ditunjukkan pada waktu pengkodean, tetapi itu mencerminkan kelemahan dalam sistem menurut pendapat saya. Namun, saya biasanya membuat prototipe di JRuby dan akan membuat kode di Jawa nanti sebagian besar hal yang saya lakukan. seolah-olah perkakas lebih baik untuk bahasa dinamis, maka sebagian besar bug dan kesalahan ketik akan ditunjukkan pada waktu pengkodean, tetapi itu mencerminkan kelemahan dalam sistem menurut pendapat saya. Namun, saya biasanya membuat prototipe di JRuby dan akan membuat kode di Jawa nanti sebagian besar hal yang saya lakukan.

PERINGATAN: Beberapa tautan ini tidak dapat diandalkan, dan beberapa melalui portal berbagai komunitas komputasi menggunakan akses berbasis biaya untuk anggota. Maaf tentang itu, saya mencoba mencari beberapa tautan untuk masing-masing tautan ini tetapi tidak sebaik yang saya inginkan.

haylem
sumber
Temuan bug itu - apakah itu terutama karena nama variabel yang salah ejaan, atau nama metode, atau di antara keduanya? (Saya benci deklarasi variabel implisit karena alasan ini: di Smalltalk, Anda mendeklarasikan semua variabel Anda di bagian atas, sehingga Anda segera tahu ketika Anda salah ketik nama variabel. telah digunakan dalam gambar sebelumnya.))
Frank Shearar
Tooling ulang, saya harus mengatakan bahwa itu tergantung pada bahasa Anda - Smalltalk memiliki alat yang sangat baik, termasuk Browser Refactoring yang Eclipse (saya diberitahu) belum mengejar ketinggalan.
Frank Shearar
@ Frank Shearar, sejak saya mulai dengan Ruby (berasal dari Jawa), saya menyadari bahwa apa yang dikatakan @ haylem mungkin tidak berlaku untuk Smalltalk. Juga mantra saya tentang refactoring otomatis menjadi tidak mungkin di langs yang diketik secara dinamis. Saya sepenuhnya setuju dengan bagian "pribadi" haylem .... mengabaikan SmallTalk tentu saja :) Ini adil, sampai batas tertentu, karena SmallTalk, walaupun tidak mati, pasti tidak menikmati popularitas yang dimiliki oleh Python atau Ruby (sekarang pada Oktober 2010 ).
Dan Rosenstark
3
@haylem, secara pribadi saya mengucapkan terima kasih karena membuat saya merasa bahwa saya bukan satu-satunya orang di dunia yang bekerja dalam bahasa yang dinamis tetapi, ketika diberi pilihan, berkali-kali MEMILIH bahasa yang diketik secara statis (kasus yang sama, Java vs. JRuby atau Groovy).
Dan Rosenstark
4
Ini menarik karena preferensi saya sendiri untuk pengetikan dinamis adalah untuk alasan yang agak berbeda. Maksud saya kompilasi cepat dan interpreter interaktif berguna tetapi mereka tidak mengapa saya suka mengetik dinamis. Saya suka mengetik dinamis karena saya menemukan banyak situasi di mana bahasa pengetikan statis hanya membuat sulit untuk menggambarkan konsep tertentu.
Winston Ewert
19

Baru kemarin saya menemukan studi ini: Pengujian unit tidak cukup. Anda juga perlu mengetik statis.

Pada dasarnya penulis menggunakan alat yang dapat mengkonversi secara otomatis proyek dari bahasa pengetikan non-statis menjadi pengetikan statis (python ke haskell)

Kemudian ia memilih sejumlah proyek Python open source yang juga termasuk sejumlah unit uji yang masuk akal, dan secara otomatis mengubahnya menjadi haskell.

Terjemahan ke Haskell mengungkapkan serangkaian kesalahan terkait dengan jenis variabel: kesalahan tidak ditemukan oleh unit uji.

PBrando
sumber
4
Kebenaran mengetik dinamis yang tidak nyaman.
Den
6
"Terjemahan ke Haskell mengungkapkan serangkaian kesalahan yang terkait dengan jenis variabel: kesalahan tidak ditemukan oleh unit tes.": Dengan bahasa yang diketik secara dinamis Anda harus menguji properti kode Anda secara manual yang secara statis Bahasa -typed secara otomatis diperiksa oleh kompiler. Ini lebih memakan waktu dan rawan kesalahan. +1
Giorgio
4
Saya merespons posting di tautan ini di Reddit. Saya tidak berpikir kesimpulan yang diambil dari kertas masuk akal.
Veedrac
Kedua sistem pengetikan memiliki pro / kontra dan penggunaannya. Ini seperti membahas tentang membawa senapan mesin ke pertarungan tangan kosong. Itu perang agama yang jauh dari akhir. Yang mengatakan, saya setuju dengan Veedrac. Bahasa non-statis membutuhkan lebih banyak kasus uji untuk menangkap kesalahan yang disebabkan oleh jenis. Itu sifat dan tipuan mereka. Tapi, seorang programmer perlu menulis tes yang menangkap kesalahan dalam kode yang disebabkan oleh keadaan input yang tidak terduga, belum tentu pengujian lengkap untuk tipe input.
Andre Figueiredo
10
  • Tautan ke diskusi makalah ACM " Eksperimen Tentang Static dan Dynamic Type Systems " (2010) oleh artikel Stephan Hanenberg (dirujuk oleh Lorin Hochstein dalam posting sebelumnya).
  • Kesimpulan: Produktivitas untuk kualitas serupa lebih tinggi dalam bahasa yang dinamis.
  • Potensi bias / masalah validitas: Subjek percobaan adalah semua siswa. Juga, variasi tugas pemrograman yang terbatas (subjek diminta untuk mengimplementasikan pemindai dan pengurai).
  • Kertas ACM " Apakah Bahasa Pemrograman Mempengaruhi Produktivitas? " (2007) oleh Delorey, Knudson, dan Chun.
  • Kesimpulan: JavaScript, Tcl, Perl lebih produktif daripada C # C ++ dan Java. Python dan PHP berada di tengah.
  • Potensi bias / masalah validitas: Tidak ada ukuran kualitas (seperti bug ditemukan pasca-rilis). Tidak ada ukuran keandalan (apakah perangkat lunak yang ditulis dalam bahasa yang diketik secara statis lebih dapat diandalkan?). Bias sampel - semua proyek terbuka diambil dari sumber CVS open source. Juga, tidak ada perbedaan antara bahasa yang diketik dengan lemah dan sangat kuat (mis. Pointer).
  • Tesis " Studi Empiris Produktivitas dan Kualitas Perangkat Lunak " (2008) oleh Michael F. Siok
  • Kesimpulan: Pilihan bahasa pemrograman tidak secara signifikan mempengaruhi produktivitas atau kualitas. Namun, itu mempengaruhi biaya tenaga kerja dan "kualitas dalam portofolio proyek perangkat lunak keseluruhan".
  • Masalah bias / validitas potensial: Terbatas pada domain avionik. Bahasa pemrograman semuanya bisa diketik secara statis. Saya tidak membaca tesis, jadi saya tidak bisa mengevaluasi kekakuannya.
    Pendapat saya. Meskipun ada bukti lemah bahwa bahasa yang diketik secara dinamis lebih produktif, itu tidak konklusif. (1) Ada banyak faktor yang tidak terkontrol, (2) ada terlalu sedikit penelitian, (3) ada sedikit atau tidak ada diskusi tentang apa yang merupakan metode pengujian yang tepat.
tawaran
sumber
6

Inilah titik awalnya:

Makalah ini menantang kebijaksanaan yang diterima umum bahwa, semua yang lain sama, programmer menulis jumlah baris kode yang sama per waktu terlepas dari bahasa. Dengan kata lain, makalah ini harus berfungsi sebagai bukti empiris pendukung bahwa produktivitas mekanik (garis kode tertulis) bukan ukuran yang baik dari produktivitas fungsional, dan setidaknya harus dinormalisasi oleh bahasa.

Piet Delport
sumber
5
Untuk orang-orang non-IEEE, apa ringkasan dasarnya?
Frank Shearar
1
@ Frank Shearar, kesimpulan yang mereka tarik adalah bahwa bahasa pemrograman memang memengaruhi produktivitas. Mereka mengukur garis kode per programmer per bahasa per tahun, saya tidak yakin itu ukuran produktivitas yang baik.
Winston Ewert
3
@ Winston: Itu pasti metrik yang cacat. Anda akan menemukan COBOL sebagai bahasa yang sangat produktif: COBOL membutuhkan banyak baris untuk melakukan sesuatu yang bermanfaat, tetapi mereka cukup mudah untuk ditulis.
David Thornley
Winston, David: Saya cukup yakin para penulis tidak menyarankan bahwa lini-kode-produktivitas adalah ukuran produktivitas fungsional . Sebaliknya, makalah ini menantang kebijaksanaan yang diterima umum bahwa, semua yang lain sama, programmer menulis jumlah baris kode yang sama per waktu terlepas dari bahasa. Dengan kata lain, makalah ini harus berfungsi sebagai bukti empiris pendukung bahwa produktivitas mekanik (garis kode tertulis) bukan ukuran yang baik dari produktivitas fungsional, dan setidaknya harus dinormalisasi oleh bahasa.
Pi Delport
Saya setuju dengan itu. Tapi itu tidak berfungsi untuk menjawab pertanyaan awal saya.
Winston Ewert
1

Saya telah menemukan bahasa Static vs. dynamic: review literatur , yang berisi daftar beberapa studi tentang subjek dan memberikan ringkasan yang bagus pada setiap studi.

Inilah ringkasan eksekutif:

Dari percobaan terkontrol, hanya tiga yang menunjukkan efek yang cukup besar untuk memiliki signifikansi praktis. Studi Prechelt membandingkan C, C ++, Java, Perl, Python, Rexx, dan Tcl; studi Endrikat membandingkan Jawa dan Dart; dan percobaan Cooley dengan VHDL dan Verilog. Sayangnya, mereka semua memiliki masalah yang membuat sulit untuk menarik kesimpulan yang sangat kuat.

Dalam studi Prechelt, populasi berbeda antara bahasa yang dinamis dan diketik, dan kondisi untuk tugas-tugas juga berbeda. Ada penelitian lanjutan yang menggambarkan masalah ini dengan mengundang Lispers untuk datang dengan solusi mereka sendiri untuk masalah ini, yang melibatkan membandingkan orang-orang seperti Darius Bacon dengan undergrads acak. Tindak lanjut dari tindak lanjut secara harfiah melibatkan membandingkan kode dari Peter Norvig dengan kode dari mahasiswa acak.

Dalam studi Endrikat, mereka secara khusus memilih tugas yang menurut mereka pengetikan statis akan membuat perbedaan, dan mereka menarik subjek dari populasi di mana setiap orang mengikuti kelas menggunakan bahasa yang diketik secara statis. Mereka tidak berkomentar apakah siswa memiliki pengalaman dalam bahasa yang diketik secara dinamis atau tidak, tetapi tampaknya aman untuk berasumsi bahwa sebagian besar atau semua memiliki lebih sedikit pengalaman dalam bahasa yang diketik secara dinamis.

Eksperimen Cooley adalah salah satu dari sedikit yang menarik orang dari populasi non-siswa, yang bagus. Tapi, seperti semua eksperimen lainnya, tugas itu adalah tugas mainan yang sepele. Meskipun tampaknya memberatkan bahwa tidak satu pun dari peserta VHDL (bahasa statis) mampu menyelesaikan tugas tepat waktu, itu sangat tidak biasa untuk ingin menyelesaikan desain perangkat keras dalam 1,5 jam di mana saja di luar proyek sekolah. Anda mungkin berpendapat bahwa tugas besar dapat dipecah menjadi banyak tugas yang lebih kecil, tetapi argumen yang masuk akal adalah bahwa ada biaya tetap menggunakan VHDL yang dapat diamortisasi di banyak tugas.

Adapun sisa percobaan, takeaway utama yang saya miliki dari mereka adalah bahwa, di bawah seperangkat keadaan khusus yang dijelaskan dalam penelitian, efek apa pun, jika ada sama sekali, kecil.

Pindah ke studi kasus, dua studi kasus penemuan bug membuat untuk membaca yang menarik, tetapi mereka tidak benar-benar membuat kasus untuk atau melawan jenis. Satu menunjukkan bahwa menyalin program Python ke Haskell akan menemukan jumlah bug yang tidak diketahui dengan tingkat keparahan yang tidak diketahui yang mungkin tidak ditemukan melalui pengujian unit yang berorientasi pada cakupan garis. Sepasang makalah Erlang menunjukkan bahwa Anda dapat menemukan beberapa bug yang akan sulit ditemukan melalui segala jenis pengujian, beberapa di antaranya parah, menggunakan analisis statis.

Sebagai pengguna, saya merasa nyaman ketika kompiler saya memberi saya kesalahan sebelum saya menjalankan alat analisis statis terpisah, tapi itu kecil, mungkin bahkan lebih kecil dari ukuran efek dari studi terkontrol yang tercantum di atas.

Saya menemukan studi kasus 0install (yang membandingkan berbagai bahasa dengan Python dan akhirnya menetap di Ocaml) menjadi salah satu hal yang lebih menarik yang saya temui, tapi itu adalah jenis subjektif yang akan ditafsirkan oleh setiap orang secara berbeda, yang dapat Anda lihat dengan melihat .

Ini sesuai dengan kesan yang saya miliki (di sudut kecil dunia saya, ACL2, Isabelle / HOL, dan PVS adalah prover yang paling umum digunakan, dan masuk akal bahwa orang akan lebih suka otomatisasi ketika menyelesaikan masalah dalam industri), tapi itu juga subyektif.

Dan kemudian ada studi yang menambang data dari proyek yang ada. Sayangnya, saya tidak dapat menemukan orang yang melakukan apa pun untuk menentukan sebab-akibat (misalnya, menemukan variabel instrumen yang sesuai), sehingga mereka hanya mengukur korelasi. Beberapa korelasi tidak terduga, tetapi tidak ada informasi yang cukup untuk menentukan mengapa.

Satu-satunya studi penambangan data yang menyajikan data yang berpotensi menarik tanpa eksplorasi lebih lanjut adalah ulasan Smallshire tentang bug Python, tetapi tidak ada informasi yang cukup tentang metodologi untuk mencari tahu apa sebenarnya arti penelitiannya, dan tidak jelas mengapa ia mengisyaratkan untuk melihat data untuk bahasa lain tanpa menyajikan data3.

Beberapa kelalaian penting dari studi ini adalah studi komprehensif menggunakan programmer yang berpengalaman, apalagi studi yang memiliki populasi besar programmer "baik" atau "buruk", melihat apa pun yang mendekati proyek yang signifikan (di tempat saya pernah bekerja, proyek tiga bulan akan dianggap kecil, tapi itu beberapa kali lipat lebih besar daripada proyek apa pun yang digunakan dalam studi terkontrol), menggunakan bahasa "modern" yang diketik secara statis, menggunakan pengetikan bertahap / opsional, menggunakan IDE arus utama modern (seperti VS dan Eclipse), menggunakan IDE radikal modern (seperti LightTable), menggunakan editor sekolah lama (seperti Emacs dan vim), melakukan pemeliharaan pada basis kode non-sepele, melakukan pemeliharaan dengan apa pun yang menyerupai lingkungan yang realistis, melakukan pemeliharaan pada basis kode yang sudah Anda kenal, dll.

Jika Anda melihat komentar internet pada studi ini, kebanyakan dari mereka dibagikan untuk membenarkan satu sudut pandang atau yang lain. Studi Prechelt tentang dinamis vs statis, bersama dengan tindak lanjut pada Lisp adalah favorit abadi advokat bahasa dinamis, dan studi penambangan github baru-baru ini menjadi tren di kalangan programmer fungsional.

Mr.WorshipMe
sumber
0

Sejujurnya saya tidak berpikir bahwa pengetikan Static vs Dynamic adalah pertanyaan sebenarnya.

Saya pikir ada dua parameter yang harus didahulukan:

  • tingkat keahlian dalam bahasa: semakin Anda berpengalaman, semakin Anda tahu tentang "gotcha" dan semakin besar kemungkinan Anda untuk menghindarinya / melacaknya dengan mudah. Ini juga berlaku untuk aplikasi / program tertentu yang sedang Anda kerjakan
  • pengujian: Saya suka mengetik statis (sih saya suka pemrograman di C ++: p) tapi ada begitu banyak sehingga kompiler / analisa statis dapat lakukan untuk Anda. Tidak mungkin untuk percaya diri tentang suatu program tanpa mengujinya. Dan saya semua untuk pengujian fuzzy (bila berlaku), karena Anda tidak bisa memikirkan semua kombinasi input yang mungkin.

Jika Anda nyaman dalam bahasa ini, Anda akan menulis kode dan Anda akan melacak bug dengan mudah.

Jika Anda menulis kode yang dipisahkan, dan menguji setiap fungsi secara luas, maka Anda akan menghasilkan kode yang terasah dengan baik, dan dengan demikian Anda akan menjadi produktif (karena Anda tidak dapat memenuhi syarat sebagai produktif jika Anda tidak menilai kualitas produk, bukan? )

Oleh karena itu saya akan menganggap bahwa debat statis dan dinamis berkaitan dengan produktivitas cukup diperdebatkan, atau setidaknya sangat digantikan oleh pertimbangan lain.

Matthieu M.
sumber
2
Jika ini adalah pertanyaan tandingan, di mana ada pertanyaan di dalamnya? :) Saya setuju bahwa faktor-faktor lain lebih penting daripada pengetikan statis vs dinamis. Namun, pendukung pengetikan dinamis mengklaim produktivitas yang lebih baik dan pendukung pengetikan statis mengklaim kualitas kode lebih baik. Saya bertanya-tanya apakah ada yang punya bukti aktual untuk mendukung klaim mereka.
Winston Ewert
@ Winston: Saya menghapus bit counter: p Seperti yang Anda sebutkan itu sebagian besar klaim. Saya pikir sebagian besar pendukung pengetikan dinamis menggabungkan kemudahan penggunaan dengan pengetikan dinamis, sementara kemudahan penggunaan sebagian besar tentang alat. Saya setuju bahwa kemungkinan untuk menulis prototipe membuang-cepat dan untuk bereksperimen perintah pendek menggunakan juru bahasa adalah dorongan produktivitas, tetapi bahkan Haskell (mungkin bahasa dengan sistem tipe paling mengesankan saat ini) memiliki penerjemah untuk eksperimen cepat: )
Matthieu M.
Tetapi sampai seseorang benar-benar melakukan penelitian yang mempertimbangkan pertanyaan ini - apakah metodologi, alat memiliki dampak yang lebih besar daripada bahasa pada tingkat cacat, produktivitas - kita akhirnya membandingkan anekdot.
Frank Shearar
0

Berikut ini beberapa di antaranya:

  • Stefan Hanenberg. 2010. Eksperimen tentang sistem tipe statis dan dinamis: keraguan tentang dampak positif sistem tipe statis terhadap waktu pengembangan. Dalam Prosiding konferensi internasional ACM tentang bahasa dan aplikasi sistem pemrograman berorientasi objek (OOPSLA '10). ACM, New York, NY, AS, 22-35. DOI = 10.1145 / 1869459.1869462 http://doi.acm.org/10.1145/1869459.1869462

  • Daniel P. Delorey, Charles D. Knutson, Scott Chun, "Apakah Bahasa Pemrograman Mempengaruhi Produktivitas? Sebuah Studi Kasus Menggunakan Data dari Proyek Sumber Terbuka," benang, hlm. '07: Lokakarya ICSE 2007), 2007

  • Daly, M.; Sazawal, V., Foster, J .: Bekerja dalam Kemajuan: Studi Empiris tentang Pengetikan Statis di Ruby, Workshop Evaluasi dan Kegunaan Bahasa dan Alat Pemrograman (PLATEAU) di ON-WARD 2009.

  • Lutz Prechelt dan Walter F. Tichy. 1998. Eksperimen Terkontrol untuk Menilai Manfaat dari Pemeriksaan Tipe Argumen Prosedur. IEEE Trans. Softw. Eng 24, 4 (April 1998), 302-312. DOI = 10.1109 / 32.677186 http://dx.doi.org/10.1109/32.677186

Lorin Hochstein
sumber