Apa maksud Alan Perlis mengenai cara-cara menulis program yang bebas kesalahan? [Tutup]


29

Ada kutipan oleh Alan J. Perlis yang mengatakan:

Ada dua cara untuk menulis program bebas kesalahan; hanya yang ketiga yang berfungsi.

Baru-baru ini saya mendengar kutipan ini dari teman saya, dan tidak dapat memahami makna yang lebih dalam di baliknya.

Apa yang Perlis bicarakan di sini?


1
Anda menyadari kesalahan dalam parodi ini juga, karena dimungkinkan untuk menulis program non-sepele yang bebas dari kesalahan, itu hanya membutuhkan disiplin.

1
Jenis pertanyaan ini sekarang sedang dibahas di situs meta-diskusi kami .

1
direkomendasikan membaca: Diskusikan $ {blog} ini
nyamuk

Jawaban:


41

Ini berarti tidak ada program yang bebas dari kesalahan. Kutipan mendalam tentang cara untuk menghindari kesalahan dengan kesalahan itu sendiri adalah parodi.


3
Alan Perlis jelas memiliki cara dengan kata-kata.
Frank Shearar

2
Ini adalah "parodi" yang penting dalam arti kutipan ini.
Adam Harte

60

Tidak ada cara ketiga.

Tidak ada cara untuk menulis program bebas kesalahan



14

Seperti yang telah ditunjukkan oleh banyak jawaban lain, tidak ada cara untuk menulis program bebas kesalahan .

Tapi yang ingin saya tunjukkan adalah potensi meta nature kutipan. Ini pada dasarnya kesalahan di luar batas. Dalam pernyataan pertama, ia mendefinisikan alam semesta atau "daftar" yang hanya memiliki dua kemungkinan atau elemen. Namun dalam pernyataan kedua, ia membuat referensi ke yang ketiga. Yang tidak masuk akal! Bahkan ilegal! Elemen ketiga yang diberi batas dua elemen itu sendiri merupakan kesalahan.

Benar-benar mendalam karena kutipan tersebut mampu menunjukkan esensi yang dimaksud.


Ada cara untuk membuktikan bahwa suatu program berperilaku seperti yang ditentukan. Itu digunakan misalnya untuk fasilitas nuklir ...

1
@ Thorbjørn Ravn Andersen, seperti yang ditentukan bukan berarti bebas dari kesalahan.
CaffGeek

5

Ini berarti bahwa semua program non-sepele akan memiliki bug. Itu hanya cara lucu untuk mengatakan bahwa tidak ada cara untuk menulis program bebas kesalahan.


5

Dimungkinkan untuk menulis program bebas kesalahan, bahkan yang non-sepele dan bahkan membuktikannya benar. Misalnya, pertimbangkan bahasa seperti Coq, Epigram atau Agda di mana ini dilakukan.

Masalah penghentian menyatakan bahwa tidak mungkin melakukan ini untuk program umum .


Kembalilah lebih jauh, ke tim Don Good di UT Austin, dan pekerjaan mereka di tahun 1970-an dan awal 1980-an dengan Lingkungan Verifikasi Gipsi. Mereka menunjukkan bahwa kode bebas kesalahan dimungkinkan, dengan mengirimkan Message Flow Modulator yang terbukti bebas kesalahan kepada Angkatan Laut. Paket tes penerimaan dikembangkan oleh kelompok yang sama sekali berbeda. Ketika MFM melihat paket uji penerimaan, untuk pertama kalinya, pada Tes Penerimaan, ia lulus, tanpa penyimpangan, keringanan, atau "yeah but" s.
John R. Strohm

3

Ini mengingatkan saya pada kemeja nerd yang saya lihat: Ada 10 jenis orang di dunia. Mereka yang tahu biner dan mereka yang tidak.

Itu juga bisa menjadi permainan pada fakta bahwa kadang-kadang daftar diindeks. $ var = array ('Pertama', 'Kedua', 'Ketiga'); Dan Anda dapat mengakses daftar ini sebagai berikut: $ var [0] = 'Pertama' $ var [1] = 'Kedua' $ var [2] = 'Ketiga'

Jadi indeks array literal menunjuk ke indeks "Ketiga".


... dan mereka yang mulai mengindeks pada nol

2

Ini sudah dijelaskan dengan kata lain, tetapi tidak sejelas yang saya kira seharusnya. Ini berarti Anda akan mencoba kedua cara, mereka akan memiliki kesalahan, dan akhirnya Anda akan memperbaiki bug Anda dan memiliki program bebas kesalahan. Bandingkan dengan penawaran lain:

Satu-satunya cara untuk kesalahan terjadi dalam suatu program adalah dengan ditempatkan di sana oleh penulis. Tidak ada mekanisme lain yang diketahui. Program tidak dapat memperoleh bug dengan duduk-duduk dengan program kereta lainnya. - Harlan Mills

(Atau, Anda bisa membaca ini seperti kata Pierre (yang saya pikir merupakan peregangan). (Cara ketiga, yang tidak ada dalam domain, berfungsi.) Seperti yang saya katakan, ini peregangan, tetapi benar.


1

Ini adalah kutipan yang sama yang digunakan ayah saya untuk memberi tahu saya ketika saya membuat alasan. Perkataannya cenderung seperti: "Ada 3 sisi dalam sebuah cerita. Sisi mereka, sisi Anda, dan sisi kanan / benar / benar".

Menempatkan ini ke dalam konteks dengan pengembangan (dan menjadi tester perangkat lunak oleh prof.), Saya akan mengatakan karena ada begitu banyak cara untuk kode sesuatu itu masuk akal untuk pergi dengan "Ada 3 sisi untuk pengkodean. Kode Anda, kode mereka, dan kode Refactored. "

Saya pikir ini karena programmer / pengembang cenderung untuk melakukan refactor setelah produk menjadi stabil yang sebagian besar sudah terlambat, tetapi sebagian besar waktu refactor dilakukan untuk meningkatkan sesuatu yang Anda dan teman Anda tidak melakukannya dengan baik di tempat pertama.

Semoga ini membantu.


1

Saya pikir, secara teknis, Anda dapat menulis program bebas-kesalahan sepele, tetapi karena Masalah Pemutusan tidak mungkin membuktikan bahwa itu bebas kesalahan. Jadi, seseorang harus bekerja dengan asumsi bahwa semua program memiliki bug karena tidak mungkin untuk membuktikan sebaliknya.

http://en.wikipedia.org/wiki/Halting_problem

Pembaruan: Anda dapat membuktikan algoritma tertentu akan mengembalikan jawaban yang benar, tetapi itu tidak sama dengan membuktikan bahwa itu sepenuhnya benar. http://en.wikipedia.org/wiki/Correctness_(computer_science )

Namun, maksud saya adalah bahwa kutipan mengacu pada fakta bahwa seseorang harus berasumsi bahwa program selalu memiliki bug dan mencoba menjelaskan mengapa itu terjadi. http://en.wikipedia.org/wiki/Software_bug#Bug_management


1
seperti yang dikatakan Tony Morris, adalah mungkin untuk membuktikan bahwa suatu program tertentu benar. Tidak mungkin menulis program yang secara umum dapat membuktikan bahwa program apa pun yang benar, adalah benar.
Max Strini

-1

Sebagai wawasan tambahan, "dua cara" mungkin menjadi referensi untuk kutipan ini oleh Tony Hoare :

Ada dua cara membangun desain perangkat lunak: Salah satu caranya adalah membuatnya begitu sederhana sehingga jelas tidak ada kekurangan, dan cara lainnya adalah membuatnya sangat rumit sehingga tidak ada kekurangan yang jelas. Metode pertama jauh lebih sulit. Ini menuntut keterampilan yang sama, pengabdian, wawasan, dan bahkan inspirasi sebagai penemuan hukum-hukum fisika sederhana yang mendasari fenomena alam yang kompleks.

Renungkan itu sedikit dan Anda akan melihat dia mengatakan hal yang sama: jika perangkat lunak Anda non-sepele, ia memiliki bug (tetapi cukup rumit dan itu tidak akan menjadi bug yang jelas ).


ini tidak menjawab pertanyaan yang diajukan
nyamuk

@gnat Saya tidak melihat bagaimana tidak - itu tepat di paragraf kedua. Mungkin kata-katanya tidak jelas, tetapi ketika saya mengatakan "mengatakan hal yang sama", maksud saya "mengatakan hal yang sama dengan Alan Perlis". Artinya, kutipan Perlis kemungkinan merupakan parodi lucu Hoare.
Doval
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.