it-swarm-id.com

Studi bahasa yang diketik secara dinamis vs statis

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.

71
Winston Ewert

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.

Secara pribadi , saya dengan tegas menganggap 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 Mengetik Dinamis memberi Anda dorongan dalam produktivitas, saya pikir itu sebagian besar disebabkan oleh 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 dibuat prototipe di konsol interaktif, tetapi memberi Anda manfaat pengetikan statis (dan sistem jenis yang lebih kuat daripada banyak bahasa lain, ML - Bahasa selain). 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. Tetap saja, saya biasanya membuat prototipe di JRuby dan akan membuat kode dalam Java nanti sebagian besar hal yang saya lakukan.

PERINGATAN: Beberapa tautan ini tidak dapat diandalkan, dan beberapa melalui portal berbagai masyarakat 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.

43
haylem

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

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 open source Python proyek yang juga termasuk sejumlah unit uji yang masuk akal, dan secara otomatis mengubahnya menjadi haskell.

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

19
PBrando
  • Tautan ke diskusi makalah ACM " Eksperimen Tentang Sistem Tipe Statis dan Dinamis " (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 repositori CVS sumber terbuka. Juga, tidak ada perbedaan antara bahasa yang diketik dengan lemah dan sangat kuat (mis. Petunjuk).
  • 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 dapat 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.
10
ahoffer

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 harus berfungsi sebagai pendukung bukti empiris bahwa produktivitas mekanik (garis kode tertulis) adalah bukan ukuran yang baik dari produktivitas fungsional, dan harus setidaknya dinormalisasi dengan bahasa.

6
Pi Delport

Saya telah menemukan bahasa statis vs dinamis: tinjauan 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 Java dan Dart; dan eksperimen Cooley dengan VHDL dan Verilog. Sayangnya, mereka semua memiliki masalah yang membuatnya sulit untuk menarik kesimpulan yang sangat kuat.

Dalam studi Prechelt, populasi berbeda antara bahasa yang dinamis dan yang diketik, dan kondisi untuk tugas-tugas juga berbeda. Ada penelitian lanjutan yang menggambarkan masalah ini dengan mengundang Lispers untuk menemukan solusi mereka sendiri untuk masalah tersebut, 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 mereka dari populasi di mana setiap orang mengambil 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 spesifik yang dijelaskan dalam penelitian, efek apa pun, jika ada, adalah kecil.

Beralih ke studi kasus, kedua studi kasus penemuan bug ini menghasilkan bacaan yang menarik, tetapi mereka tidak benar-benar membuat kasus untuk atau melawan jenis. Satu menunjukkan bahwa menyalin Python program untuk Haskell akan menemukan sejumlah bug tanpa 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 sulit ditemukan melalui pengujian apa pun, beberapa di antaranya parah, menggunakan analisis statis.

Sebagai pengguna, saya merasa nyaman ketika kompiler saya memberi saya kesalahan sebelum saya menjalankan alat analisis statis yang terpisah, tetapi 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 jumpai, tapi itu adalah jenis hal subjektif yang semua orang akan menafsirkan 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 siapa pun yang melakukan apa pun untuk menentukan sebab-akibat (mis., Menemukan variabel instrumental yang sesuai), sehingga mereka hanya mengukur korelasi. Beberapa korelasi tidak terduga, tetapi tidak ada informasi yang cukup untuk menentukan alasannya.

Satu-satunya studi penambangan data yang menyajikan data yang berpotensi menarik tanpa eksplorasi lebih lanjut adalah ulasan Smallshire untuk bug Python bug, tetapi tidak ada informasi yang cukup tentang metodologi untuk mencari tahu apa arti sebenarnya dari studinya, dan tidak jelas mengapa dia mengisyaratkan 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 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.

1
Mr.WorshipMe

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

0
Lorin Hochstein

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? )

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

0
Matthieu M.