it-swarm-id.com

Bahasa pemrograman apa yang menghasilkan bug paling sulit ditemukan?

Menurut Anda, bahasa apa yang memungkinkan programmer rata-rata menghasilkan fitur dengan jumlah bug yang paling sulit ditemukan? Ini tentu saja, pertanyaan yang sangat luas, dan saya tertarik pada jawaban dan kebijaksanaan yang sangat luas dan umum.

Secara pribadi saya menemukan bahwa saya menghabiskan sangat sedikit waktu mencari bug aneh di program Java dan C #, sedangkan kode C++ memiliki serangkaian bug berulang yang berbeda, dan Python/serupa memiliki seperangkat kesamaan umum dan bug konyol yang akan terdeteksi oleh kompiler dalam bahasa lain.

Juga saya merasa sulit untuk mempertimbangkan bahasa fungsional dalam hal ini, karena saya belum pernah melihat program besar dan kompleks yang ditulis dalam kode fungsional sepenuhnya. Masukan Anda.

Sunting: Klarifikasi yang sepenuhnya arbitrer terhadap bug yang sulit ditemukan: Membutuhkan lebih dari 15 menit untuk mereproduksi, atau lebih dari 1 jam untuk menemukan penyebab dan memperbaikinya.

Maafkan saya jika ini adalah duplikat, tetapi saya tidak menemukan apa pun pada topik khusus ini.

54
Magnus Wolffelt

Semakin kuat jenis sistem bahasa, semakin banyak bug akan ditangkap pada waktu kompilasi itu sendiri.

Gambar berikut membandingkan beberapa bahasa pemrograman terkenal dalam hal kekuatan, kesederhanaan, dan keamanan sistem tipenya. [ Sumber ]

alt text

* Anjak kemampuan untuk menggunakan konstruksi yang tidak aman.

C # dimasukkan ke dalam baris yang tidak aman karena kata kunci "tidak aman" dan mesin penunjuk yang terkait. Tetapi jika Anda ingin menganggap ini sebagai semacam mekanisme fungsi asing inline jangan ragu untuk menabrak C # ke atas.

Saya telah menandai Haskell '98 sebagai murni tetapi GHC Haskell sebagai tidak murni karena keluarga * fungsi tidak aman. Jika Anda menonaktifkan tidak aman * kemudian melompat GHC Haskell ke atas.

58
missingfaktor

Menurut pendapat saya, Haskell membantu Anda menghindari beberapa sumber kesalahan:

  • ini murni fungsional: fungsi tidak dapat memiliki efek samping (tidak disengaja) dan ini membuat pemrograman multicore lebih mudah dan lebih sedikit rawan kesalahan
  • itu sangat diketik: Anda tidak bisa mis. secara tidak sengaja mencampur nilai bool, char, int dan float
  • itu diketik secara statis: banyak kesalahan pemrograman ditangkap pada waktu kompilasi
  • null bukan bagian dari definisi tipe nilai: dengan ini Anda menghindari miliar dolar kesalahan
  • ada banyak fungsi tingkat tinggi siap pakai yang dapat Anda gunakan kembali alih-alih menulis implementasi Anda sendiri, mungkin salah,
  • ia memiliki pengumpul sampah: kesalahan memori hampir dihilangkan (kecuali untuk "kebocoran ruang" karena strategi evaluasi yang malas)
20

Biasanya bug yang paling sulit ditemukan adalah kondisi ras dalam aplikasi multi-utas sebagaimana adanya

  • hampir mustahil untuk bereproduksi
  • bisa sangat halus

Karenanya, Anda membutuhkan bahasa yang mengatur parallisme untuk Anda sebanyak dan sesederhana mungkin. Ini belum umum. Java melakukan beberapa, tetapi meninggalkan Anda dengan bagian yang sulit.

Untuk pemahaman saya, Anda memerlukan bahasa fungsional karena "tidak ada efek samping" adalah hal yang pada awalnya membuat dua poin peluru hilang. Saya telah melihat bahwa pekerjaan sedang berlangsung secara transparan menjadikan Haskell bahasa multi-utas yang efisien, dan saya percaya Fortress dirancang dari bawah ke atas untuk menjadi bahasa paralel yang efisien.


Sunting: Di Java Executors menangani lebih banyak bagian yang sulit. Anda harus membuat tugas-tugas individu sesuai dengan antarmuka Callable.

18
user1249

Ada dirancang sedemikian rupa sehingga sebanyak mungkin ditangkap pada waktu kompilasi daripada pada saat dijalankan. Apa artinya ini adalah bahwa sering dibutuhkan sekitar 10x lebih lama untuk mendapatkan program di Ada untuk dikompilasi daripada yang setara akan di Java katakan, tapi ketika itu mengkompilasi Anda dapat jauh lebih percaya diri bahwa seluruh kelas bug tidak akan menampakkan diri ketika program dijalankan.

13
Mark Pim

Pertama definisi: bug yang sulit ditemukan, seperti yang saya mengerti, adalah bug yang dapat direproduksi tetapi penyebabnya sulit ditemukan.

Mungkin aspek yang paling penting adalah apa yang saya sebut sempitnya, yaitu seberapa jauh bug dapat lolos, seberapa besar cakupan bug yang berpotensi memengaruhi. Dalam bahasa seperti C, bug, mis. indeks array negatif atau pointer yang tidak diinisialisasi, dapat memengaruhi semua yang ada di seluruh program secara harfiah, jadi dalam kasus terburuk, Anda harus memeriksa semuanya di mana saja untuk menemukan sumber masalah Anda.

Bahasa yang baik dalam hal itu mendukung pengubah akses dan menegakkannya dengan cara yang membuatnya sulit atau tidak mungkin untuk melewati mereka. Bahasa yang baik mendorong Anda untuk membatasi ruang lingkup variabel Anda, alih-alih membuatnya terlalu mudah untuk memiliki variabel global (mis. "Semua yang tidak dinyatakan secara eksplisit adalah variabel global dengan jenis dan nilai default").

Aspek penting kedua adalah konkurensi. Kondisi ras umumnya sulit direproduksi dan karenanya sulit ditemukan. Bahasa yang baik menawarkan mekanisme sinkronisasi yang mudah digunakan, dan lib standar mereka aman jika diperlukan.

Ini sudah melengkapi daftar saya; hal-hal lain seperti pengetikan yang kuat membantu menangkap bug pada waktu kompilasi, tetapi bug itu mungkin tidak akan sulit ditemukan nanti.

Mempertimbangkan semua itu, saya akan mengatakan bahwa Java dan C #, dan banyak bahasa lain di dunia JVM dan .net, cocok untuk menghindari bug yang sulit ditemukan.

7
user281377

Karena Excel adalah DSL yang paling banyak digunakan, saya akan menggunakan Excel. (tidak termasuk VBA tentu saja)

Ini sesuai dengan tagihan:

  • Itu selalu mudah direproduksi (ini spreadsheet - tidak berfungsi)
  • Sangat mudah untuk menemukan bug, karena ini benar-benar "fungsional" - mulai dengan sel yang salah dan telusuri kembali semua dependensinya.
7
Scott Whitlock

Ini adalah pertanyaan yang sulit karena sebagian besar bug bukan kesalahan bahasa itu sendiri - melainkan kesalahan pengembang yang membuat kesalahan dalam cara mereka menggunakan bahasa itu.

Saya percaya ada beberapa aspek fitur bahasa yang memengaruhi kemungkinan bug:

  • Interaktivitas - bahasa dinamis dengan REPL mendorong interaksi/eksperimen dengan menjalankan program dan siklus kode/tes yang jauh lebih kecil. Jika Anda percaya bahwa iterasi adalah cara yang baik untuk menemukan solusi sederhana yang bersih dan mendeteksi/menghilangkan bug maka ini akan cenderung mendukung bahasa interaktif.

  • Ekspresifif - jika kode lebih pendek dan memiliki kompleksitas boilerplate/insidental lebih sedikit maka lebih mudah untuk melihat bug/kesalahan logika.

  • Ketik keamanan - semakin banyak waktu kompilasi memeriksa, semakin banyak bug akan ditangkap oleh kompiler sehingga pada umumnya keamanan jenis adalah hal yang baik. Namun ini biasanya bukan sulit ditemukan bug - bahkan dalam bahasa yang sepenuhnya dinamis jenis yang salah dalam struktur data biasanya akan menyebabkan kesalahan runtime yang sangat jelas, dan TDD hampir selalu mengambil jenis ini bug.

  • Ketidaksuburan - banyak bug keras disebabkan oleh interaksi kompleks dari keadaan yang bisa berubah. Bahasa yang menekankan kekekalan (Haskell, Clojure, Erlang) memiliki keuntungan yang sangat besar dengan menghindari mutabilitas

  • Pemrograman fungsional - pendekatan fungsional untuk menulis kode cenderung lebih "terbukti benar" daripada kode berorientasi objek dengan urutan efek/interaksi yang kompleks. Pengalaman saya adalah bahwa FP membantu menghindari bug yang rumit - Saya percaya ada beberapa penelitian akademik di suatu tempat yang saat ini saya tidak dapat menemukan yang mendukung hal ini.

  • Dukungan konkurensi - masalah konkurensi sangat sulit untuk dideteksi dan didebug yang merupakan alasan mengapa hal ini sangat penting. Apa pun yang membutuhkan penguncian manual pada akhirnya akan gagal (dan ini termasuk cukup banyak setiap pendekatan berorientasi objek ke konkurensi). Bahasa terbaik yang saya tahu dalam hal ini adalah Clojure - ia memiliki pendekatan unik untuk mengelola konkurensi yang menggabungkan memori transaksional perangkat lunak dengan struktur data yang tidak berubah untuk mendapatkan kerangka kerja konkurensi yang baru, andal, dan dapat disusun. Lihat http://www.infoq.com/presentations/Value-Identity-State-Rich-Hickey untuk wawasan lebih lanjut

7
mikera

Bahasa yang kurang kuat adalah, semakin sedikit pilihan yang diberikan untuk menembak kaki Anda sendiri.

Bahasa tingkat tinggi seperti Java dan C # akan menghasilkan lebih sedikit bug daripada bahasa tingkat rendah seperti C++.

Karena itu saya percaya Java lebih aman daripada C #. Java secara artifisial terbatas sehingga rata-rata programmer tanpa pengetahuan maju dapat menguasainya dan menghasilkan program yang stabil).

5
user8685

Menurut Anda, bahasa apa yang memungkinkan programmer rata-rata menghasilkan fitur dengan jumlah bug yang paling sulit ditemukan?

Menurut saya, Delphi. Berbasis pada Pascal, bahasanya sederhana dan intuitif untuk programmer rata-rata (atau bahkan coders yang tidak berpengalaman) untuk mengambil dengan mudah, dan alat yang kaya dan dukungan perpustakaan membuat sebagian besar bug mudah ditemukan.

  • Pengetikan yang kuat dan kompiler ketat yang menangkap banyak kesalahan umum.
  • Sintaks intuitif yang tidak mendorong kesalahan umum. ("Bug Terakhir Dunia," if (alert = RED) {LaunchNukes;}, tidak akan dikompilasi, misalnya.)
  • Model objek yang dirancang dengan baik yang menghilangkan banyak kesalahan umum C++ OOP.
  • Pengecekan batas dan pengecekan jangkauan bawaan pada bahasa, secara drastis mengurangi kemungkinan masalah keamanan.
  • Mungkin kompiler tercepat yang dikenal manusia, yang meningkatkan produktivitas Anda dan membuat Anda lebih sulit untuk kehilangan pemikiran saat menunggu build.
  • Debugger Visual Studio ingin menjadi seperti ketika dewasa.
  • Pelacakan yang bocor dibangun langsung ke manajer memori, membuat mencari dan memperbaiki kebocoran memori sepele.
  • Sebuah pustaka standar besar dan matang yang menyediakan cara-cara prebuilt dan pra-uji untuk menyelesaikan tugas-tugas umum tanpa harus membangun implementasi Anda sendiri, mungkin bermasalah.
  • Kapal dengan alat yang bermanfaat, seperti sistem logging yang kuat dan profiler, untuk mempermudah pelacakan masalah.
  • Dukungan komunitas yang kuat untuk masalah umum yang tidak ada di perpustakaan standar, termasuk perpustakaan pihak ketiga yang kuat .
3
Mason Wheeler

Satu hal yang harus diperhatikan adalah pergantian waktu.

Selama lima tahun terakhir, saya terutama mengembangkan aplikasi web dalam Java (JSF, Seam, dll.). Baru-baru ini saya mendapat pekerjaan baru, dan kami menggunakan Perl (dengan Catalyst dan Moose).

Saya jauh lebih produktif di Perl, daripada di Jawa.

Tidak perlu mengkompilasi dan menyebarkan (panas), adalah salah satu alasannya. Saya juga menemukan bahwa penulisan use case lebih mudah, karena dapat dilakukan dengan cara yang lebih iteratif. Dan kerangka kerja dalam Java tampaknya tidak perlu rumit, setidaknya untuk proyek yang saya ikuti.

Saya kira jumlah bug dalam kode Perl saya kurang lebih sama dengan jumlah bug dalam kode Java saya, bahkan mungkin lebih tinggi. Tapi, saya menemukan lebih mudah dan lebih cepat untuk menemukan dan memperbaiki bug ini.

2
slu

Mungkin mensurvei jumlah alat yang tersedia untuk analisis kode statis dan dinamis untuk setiap bahasa pemrograman dapat memberikan ide. Semakin banyak alat untuk bahasa, semakin besar kemungkinan bahasa tersebut sangat populer di kalangan pengguna atau sangat populer dalam menghasilkan bug yang sulit ditemukan. Tapi saya tidak bisa mengarahkan Google ke studi apa pun tentang hal ini. Perlu juga dicatat bahwa beberapa bahasa seperti C dapat digunakan untuk mengatasi bug perangkat keras yang mendasarinya serta mengatasi masalah keausan perangkat keras seiring bertambahnya usia.

1
vpit3833

Alih-alih berbicara tentang bahasa, bagaimana dengan berbicara tentang fitur-fitur bahasa

  • Java memaksa Anda untuk memikirkan pengecualian (melempar ...) dan Anda harus publisch atau menangani pengecualian ini. Apakah itu benar-benar mencegah saya melupakan kesalahan atau saya menggunakan lebih banyak pengecualian yang berasal dari SystemException yang tidak memerlukan penanganan ini?
  • bagaimana dengan "desain berdasarkan kontrak" (http://en.wikipedia.org/wiki/Design_by_contract) yang memaksa saya untuk memikirkan pra dan kondisi akhir. Saya telah membaca yang sekarang mungkin dengan c # -4.0.
1
k3b