Bahasa pemrograman apa yang menghasilkan bug paling sulit ditemukan? [Tutup]

54

Menurut Anda, bahasa apa yang memungkinkan programmer rata-rata menampilkan 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 sedikit waktu mencari bug aneh di program Java dan C #, sedangkan kode C ++ memiliki set bug berulang yang berbeda, dan Python / serupa memiliki set bug umum dan konyol yang akan dideteksi 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 yang sepenuhnya fungsional. 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 perbaikan.

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

programming-languages bug problem-solving functional-programming Magnus Wolffelt
sumber
10
Saya ingin melihat beberapa penelitian dilakukan dalam topik ini! Bukan hanya "bukti anekdotal saya menunjukkan bahwa satu-satunya bahasa yang saya tahu adalah raja" tetapi tingkat bug dari proyek-proyek besar, dan sebagainya.
Frank Shearar
@ Terus .. jika Anda punya BANYAK (dan maksud saya BANYAK) waktu, Anda mungkin bisa menambang beberapa statistik dari ohloh, asalkan Anda bisa mengidentifikasi tambalan yang memperbaiki bug dari ribuan repositori kode.
Tim Post
Yang hanya memberi komentar saja. Tidak ada instruksi lain :)
Victor Hurdugaci
4
Saya pikir "sulit ditemukan" perlu diklarifikasi. Pertanyaan Anda dan sebagian besar jawaban tampaknya mendefinisikan "sulit ditemukan" setara dengan "tidak ditangkap oleh kompiler." Anda menyebutkan python memiliki bug konyol yang akan terdeteksi oleh kompiler. Cukup adil. Tapi bug konyol itu biasanya tidak sulit ditemukan. Tentu saja, mereka tidak dalam kategori yang sama dengan bug C ++ yang berasal dari mengatakan membebaskan memori terlalu cepat.
Winston Ewert
@ Winston Setuju.
Magnus Wolffelt

Jawaban:

58

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

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

teks alternatif

* 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 tidak murni karena keluarga * fungsi tidak aman. Jika Anda menonaktifkan tidak aman * kemudian melompat GHC Haskell ke atas.

hilangfaktor
sumber
8
Ini brilian!
7
Saya tidak dapat menemukan Common Lisp dalam grafik: (let ((itbe '())) ... )...
duros
7
Apa? Tidak ada ruang tersisa di sisi kiri untuk PHP?
pestaa
7
C # memungkinkan pointer aman : semua aritmatika pointer diperiksa. Oleh karena itu, saya percaya itu harus ada di sana dengan Java.
Alex ten Brink
11
@missingfaktor: Saya pikir C # tidak diposisikan dengan baik. C # memungkinkan dan mempromosikan gaya pemrograman yang lebih aman. Seharusnya tidak diukur dengan hal terburuk yang dibolehkan.
back2dos
20

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

  • itu 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 dapat misalnya secara tidak sengaja mencampur nilai bool, char, int dan float
  • itu diketik secara statis: banyak kesalahan pemrograman ditangkap pada waktu kompilasi
  • nullbukan bagian dari definisi tipe nilai: dengan ini Anda menghindari kesalahan miliar dolar
  • 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)
LennyProgrammers
sumber
11
Saya tidak akan mengundurkan diri, tetapi saya tergoda karena tidak sesuai dengan kriteria. Seharusnya memungkinkan "programmer rata-rata untuk menampilkan fitur" dengan jumlah bug minimal, tetapi programmer rata-rata, terus terang, tidak dapat membuat kepala atau ekor Haskell di tempat pertama.
Mason Wheeler
5
Banyak poin bagus, tetapi sementara menghapus beberapa kelas kesalahan (efek samping yang tidak diinginkan, konversi tipe yang tidak terduga) Haskell menambahkan kelas kesalahan yang sama sekali baru: kebocoran ruang. (Juga meskipun tidak ada null, ada undefined, yang merupakan anggota dari setiap jenis.)
j_random_hacker
5
@ Alasan: Jika Anda tidak menulis di dalamnya, Anda tidak dapat memiliki bug di dalamnya :)
Michael K
2
Saya kira tidak ada yang namanya makan siang gratis - Anda dapat memiliki bug yang mudah ditemukan, atau kode yang mudah ditulis, tetapi tidak keduanya :)
Benjol
6
@ Alasan apa sebenarnya "programmer rata-rata"? Pertanyaannya dimulai dengan "bahasa pemrograman apa ...", bukan "yang mana di antara C, C ++ dan java ...";)
Agos
18

Secara tradisional, 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 Jawa, Executorsmenangani lebih banyak lagi bagian yang sulit. Anda perlu membuat tugas individu sesuai dengan Callableantarmuka.

user1249
sumber
5
++ Kondisi lomba. Kamu bisa mengatakannya lagi.
Mike Dunlavey
Ya. Ingatlah bahwa komputasi paralel pada umumnya sulit, bahkan dengan bantuan bahasa. (Common Lisp macro sulit, meskipun banyak dukungan bahasa, karena apa yang mereka lakukan sangat kuat. Prinsipal yang sama.)
David Thornley
Bagaimana dengan Erlang?
Malfist
@Malfist, saya tidak cukup tahu tentang Erlang untuk menjawab itu. Mungkin Anda harus membuka pertanyaan jika Anda benar-benar ingin tahu?
2
Erlang adalah pemrograman fungsional yang dirancang untuk membuat multithreading sederhana dan aman. Anda tidak membagikan variabel, Anda meneruskan pesan. Baca halaman wikipedia ini.
Malfist
13

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 di Jawa katakan, tetapi ketika itu mengkompilasi Anda bisa jauh lebih yakin bahwa seluruh kelas bug tidak akan memanifestasikan diri ketika program itu Lari.

Mark Pim
sumber
7
+1 karena memperhatikan, dengan benar, bahwa Ada menangkap hal-hal di kompiler yang diabaikan oleh bahasa lain. -1 untuk pernyataan bahwa ini berarti dibutuhkan 10x lebih lama untuk mendapatkan program Ada untuk dikompilasi. Ada memberikan penghargaan kepada programmer yang mendesain !!! kodenya, siapa yang BERPIKIR !!! tentang apa yang dia lakukan sebelum mulai mengetik dengan gila-gilaan. Pengalaman pribadi saya, melakukan pemrograman produksi di Ada untuk pekerjaan pertahanan, adalah tidak butuh waktu lebih lama secara signifikan untuk mendapatkan kode Ada untuk dikompilasi daripada yang dibutuhkan C / C ++ atau FORTRAN, tetapi kode Ada secara signifikan lebih sedikit kesulitan nanti. Pratt & Whitney memperhatikan sesuatu yang serupa.
John R. Strohm
1
@ john r strohm, dari apa yang saya mengerti, dia tidak berbicara tentang waktu yang diperlukan untuk kompiler untuk mengkompilasi kode, bukan waktu untuk membuat kode dapat dikompilasi.
Malfist
oh setuju tentang mendapatkan kode yang dapat dikompilasi. Saya dapat mengingat banyak komentar seksis yang dibuat oleh para programmer yang mempelajari bahasa tentang pemetikan nit. Biasanya sepanjang baris Well, jika Anda menyebutkan nama bahasa setelah seorang wanita ...
Michael Shaw
@ Poltemy, jika kapal dapat dinamai sesuai nama wanita (kecuali tampaknya untuk operator AS) maka bahasa pemrograman juga bisa. Alih-alih memilikinya bernama "Ada" daripada "USS Ronald Reagan" :)
1
Setelah saya menyelesaikan kurva belajar, saya sebenarnya cukup cepat dalam menulis kode Ada - setelah saya menghabiskan banyak waktu memikirkan desain. Ada jelas BUKAN bahasa peretas. Saya bekerja di Jawa saat ini, dan beberapa hal yang saya lihat di proyek saya saat ini sebenarnya membuat saya merindukan Ada sedikit (tidak pernah berpikir saya akan mengatakan itu).
James Adam
7

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 sempit , yaitu seberapa jauh bug dapat lolos, seberapa besar cakupan bug yang berpotensi memengaruhi. Dalam bahasa seperti C, bug, misalnya indeks array negatif atau pointer tidak diinisialisasi, dapat memengaruhi semua hal di seluruh program, sehingga 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. "Segala sesuatu 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.

pengguna281377
sumber
Penguncian manual mungkin terlihat sebagai "mekanisme sinkronisasi yang mudah digunakan" tetapi sebenarnya hanya "sederhana untuk digunakan tetapi Anda berada di saat-saat yang menyenangkan saat Anda mengejar kebuntuan itu". Dan, Anda dapat melakukan konkurensi berbasis Aktor dalam beberapa bahasa.
Frank Shearar
Frank: setidaknya penguncian cukup sederhana sehingga semua orang dapat melakukannya tanpa menghabiskan berhari-hari, mencari tahu API mana yang akan digunakan dll.
user281377
Lalu ada sudut pandang bahwa solusi konkurensi yang "cukup sederhana sehingga semua orang bisa melakukannya" adalah seperti memberikan gergaji meja kepada anak-anak pra-sekolah.
David Thornley
@ David: Saya mengerti maksud Anda, tetapi dalam banyak kasus, hanya solusi sederhana yang diperlukan. Misalnya, pertimbangkan servlet yang hanya digunakan oleh segelintir pengguna, yang harus menggunakan sumber daya bersama (misalnya koneksi basis data). Tanpa sinkronisasi, kondisi balapan terjadi sesekali; tapi bukan ilmu roket untuk menempatkan semua operasi akses basis data ke dalam blok (koneksi) yang disinkronkan {}.
user281377
+1 Untuk definisi ini "seberapa besar cakupan bug yang berpotensi memengaruhi". Saya memiliki beberapa bug yang sangat jahat dengan bahasa dinamis di mana objek dari tipe data yang salah masuk sangat jauh dalam kode (terima kasih untuk mengetik bebek) sebelum memanifestasikan dirinya sebagai bug.
Giorgio
7

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.
Scott Whitlock
sumber
Ini mungkin benar selama Anda tidak menambahkan bug yang mudah ditemukan.
mouviciel
+1 Agak nakal karena Excel adalah data, bukan bahasa. Beri aku tawa yang baik :)
recursion.ninja
2
@awashburn - oh, saya tidak tahu. Saya pikir itu memenuhi syarat sebagai bahasa. Setiap sel adalah "variabel". Setiap variabel secara deklaratif ditetapkan sebagai literal (seperti 123atau ABC) atau fungsi ( =SUM(A2:A5)). Excel kemudian mengevaluasi semua variabel, mencari tahu urutan apa untuk menyelesaikan dependensi, dll. Ini tentu saja bukan hanya data.
Scott Whitlock
2
Saya menarik kembali pernyataan saya, ternyata Excel Turing Lengkap ... Saya belajar sesuatu yang benar-benar meresahkan ...
recursion.ninja
1
"... master [Lisp] yang sebenarnya menyadari bahwa semua data adalah kode." Mungkin ini berlaku untuk Excel juga, cukup aneh. blogs.msdn.com/b/sriram/archive/2006/01/15/lisp-is-sin.aspx
James Mishra
7

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 program yang sedang berjalan 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.

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

  • Jenis keamanan - semakin banyak kompilasi memeriksa waktu, semakin banyak bug akan ditangkap oleh kompiler sehingga pada umumnya keamanan jenis adalah hal yang baik. Namun ini biasanya tidak sulit untuk menemukan 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 bug semacam ini.

  • Kekekalan - banyak bug keras disebabkan oleh interaksi kompleks dari keadaan yang bisa berubah. Bahasa-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 dideteksi dan didebug yang merupakan alasan mengapa hal ini sangat penting. Apa pun yang membutuhkan penguncian manual pada akhirnya akan gagal (dan ini mencakup hampir semua pendekatan berorientasi objek untuk 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 dikomposisikan. Lihat http://www.infoq.com/presentations/Value-Identity-State-Rich-Hickey untuk wawasan lebih lanjut

mikera
sumber
Orang-orang seperti saya yang merupakan pendukung pemrograman fungsional yang bersemangat menghargai jawaban ini. Ekspresif adalah teman Anda.
Sridhar Sarnobat
1
Jawaban terbaik sejauh ini! Saya pikir ini didukung oleh dua analisis frekuensi bug berikut: disengaja-software.com/safety-rank-part-2 dan macbeth.cs.ucdavis.edu/lang_study.pdf . Keduanya menunjukkan bahwa semakin murni, semakin fungsional, semakin ekspresif dan semakin aman bahasa semakin sedikit bug yang dimilikinya. Demikian pula, keduanya menunjukkan bahwa Clojure dan Ruby lolos dari aturan Keselamatan, mungkin menunjukkan bahwa Interaktivitas memiliki dampak yang sama seperti yang Anda tunjukkan.
Didier A.
@Dierka. sayangnya tautan ucdavis rusak (tanpa arsip wbm) - Saya pikir Anda mendapatkannya dari halaman Prem Devanbu yang sekarang menunjuk ke tautan yang diperbarui: Studi Skala Besar Bahasa Pemrograman dan Kualitas Kode di Github
icc97
5

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 programmer rata-rata tanpa pengetahuan lanjutan dapat menguasainya dan menghasilkan program yang stabil.

user8685
sumber
4
+1 untuk "Semakin sedikit bahasa yang digunakan, semakin sedikit pilihan yang bisa Anda gunakan untuk menembak kaki Anda sendiri."
Michael K
Grafik dari missingfaktor tampaknya mengatakan bahwa C # dan C ++ berada pada "pijakan" yang sama sejauh dapat menembak diri sendiri di sana berjalan dan mengangkat Java di atas itu. Namun, saya tidak setuju dengan bagian grafik itu. Anda dipaksa melalui lingkaran untuk melakukan pemotretan C #.
Jesse C. Slicer
6
Keamanan dan kekuatan tidak berbanding terbalik (yang sepertinya Anda pikirkan ;-) Haskell, misalnya, sangat kuat dan memiliki sedikit cara untuk menembak diri sendiri dengan berjalan kaki.
missingfaktor
3
Jika bahasanya lemah, Anda hanya perlu kaki yang lebih besar.
7
@missingfaktor, itu karena itu adalah efek samping untuk menembak diri sendiri di kaki.
3

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

Menurut saya, Delphi. Berbasiskan pada Pascal, bahasanya sederhana dan intuitif bagi programmer rata-rata (atau bahkan coders yang tidak berpengalaman) untuk mengambilnya 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.
  • 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 konkurensi pihak ketiga yang kuat .
Mason Wheeler
sumber
Saya seorang joki Delphi dari jalan kembali, tapi itu hilang dari akar Pascal ketika memungkinkan saya untuk mengetik apa pun untuk yang lain, ala C / C ++:var I: Integer; Pointer(I)^ := $00;
Jesse C. Slicer
1
@Jesse: Mungkin, tapi saya melihat itu sebagai konsesi yang diperlukan untuk pragmatisme. Kernighan membuat banyak poin bagus ketika dia menulis Why Pascal bukan bahasa pemrograman favorit saya. Typecast diperlukan untuk menyelesaikan banyak hal penting tingkat rendah. Tetapi salah satu kekuatan dari Delphi adalah cara perpustakaannya merangkum detail tingkat rendah dan membuat sebagian besar pointer yang tidak aman dan hal-hal typecast tidak diperlukan.
Mason Wheeler
Saya tidak setuju bahwa itu mungkin perlu - tetapi mengklaim Pengetikan Kuat agak dinegasikan oleh ini. Pascal asli tidak mengizinkan shenanigans semacam itu dan karenanya sangat diketik. Tapi saya tidak akan pergi sejauh ini untuk memanggil Delphi yang diketik dengan lemah - ini semacam 'diketik dengan baik'.
Jesse C. Slicer
1
@Jesse: Bukankah versi Pascal versi Wirth yang asli memungkinkan catatan varian? IIRC mereka akhirnya menjadi begitu umum untuk menumbangkan pengetikan yang kuat sehingga Borland dan yang lainnya memutuskan untuk hanya memasukkan typecast untuk membuatnya lebih sederhana karena semua orang tetap melakukannya.
Mason Wheeler
en.wikipedia.org/wiki/Pascal_(programming_language)#Divisi dan en.wikipedia.org/wiki/Pascal_(programming_language)#Kritik serta pascal-central.com/ppl/chapter3.html tampaknya mengindikasikan itu adalah bagian dari standar pertama pada tahun 1983. Saya memang melihat beberapa referensi oleh Wirth yang tampaknya berasal dari 1974, jadi saya akan mengatakan ya. Saya pikir bagian yang bermasalah memungkinkannya untuk ditumbangkan seperti itu (yaitu bidang varian mengambil memori yang sama, seperti serikat pekerja di C). Jika mereka hanya digunakan sebagai mekanisme pelingkupan dan tata letak memori untuk superset, itu akan diketik lebih kuat.
Jesse C. Slicer
2

Satu hal yang harus diperhatikan adalah pergantian waktu.

Selama lima tahun terakhir, saya terutama mengembangkan aplikasi web di 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 di Jawa tampaknya tidak perlu rumit, setidaknya untuk proyek-proyek yang pernah 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.

Slu
sumber
1

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 bahasanya sangat populer di kalangan pengguna atau sangat populer dalam menghasilkan bug yang sulit ditemukan. Tapi saya tidak bisa mengarahkan Google ke studi apa pun yang dibuat 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.

vpit3833
sumber
1
"mengatasi masalah keausan perangkat keras seiring bertambahnya usia" ...?
j_random_hacker
Saya telah membaca bahwa beberapa OS Unix yang berjalan pada mesin misi kritis memeriksa kesehatan CPU, RAM dan perangkat keras lainnya. serverfault.com/questions/56192/… membahas hal ini secara mendalam. Jika beberapa baris dalam modul RAM menjadi rusak dari waktu ke waktu, modul-modul yang rusak tidak akan digunakan oleh OS dan tidak akan melaporkannya dalam total memori fisik yang tersedia. Hal-hal seperti itu dapat dilakukan pada perangkat keras lain juga.
vpit3833
Itu berita gembira yang menarik, tapi saya tidak melihat bagaimana itu relevan di sini. Juga tidak ada dalam tautan Anda yang menyebutkan perbaikan Unix OS ini - hanya berbicara tentang cara untuk menguji-stres perangkat keras PC.
j_random_hacker
1
Saya sebutkan itu berarti bahwa program saja mungkin bukan sumber bug, bisa jadi perangkat keras atau faktor eksternal lainnya juga.
vpit3833
1

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 bahwa sekarang dimungkinkan dengan c # -4.0.
k3b
sumber