Saya telah memperhatikan bahwa saya merasa jauh lebih mudah untuk menuliskan bukti matematika tanpa membuat kesalahan, daripada menuliskan program komputer tanpa bug.

Sepertinya ini adalah sesuatu yang lebih luas dari sekedar pengalaman saya. Kebanyakan orang membuat bug perangkat lunak setiap saat dalam pemrograman mereka, dan mereka memiliki kompiler untuk memberi tahu mereka apa kesalahannya sepanjang waktu. Saya belum pernah mendengar seseorang yang menulis program komputer besar tanpa kesalahan dalam sekali jalan, dan memiliki keyakinan penuh bahwa itu akan menjadi bugless. (Sebenarnya, hampir tidak ada program yang bugless, bahkan banyak yang sangat debugged).

Namun orang dapat menulis seluruh makalah atau buku bukti matematika tanpa penyusun apa pun pernah memberi mereka umpan balik bahwa mereka membuat kesalahan, dan kadang-kadang bahkan tanpa mendapatkan umpan balik dari orang lain.

Biarkan saya jelas. ini bukan untuk mengatakan bahwa orang tidak membuat kesalahan dalam bukti matematika, tetapi untuk matematikawan yang bahkan berpengalaman, kesalahan biasanya tidak terlalu bermasalah, dan dapat diselesaikan tanpa bantuan "ramalan eksternal" seperti kompiler yang menunjuk pada Anda kesalahan.

Bahkan, jika ini tidak terjadi, maka matematika akan hampir tidak mungkin bagi saya.

Jadi ini mengarahkan saya untuk mengajukan pertanyaan: Apa yang begitu berbeda tentang penulisan bukti matematis tanpa cacat dan penulisan kode komputer tanpa cacat yang membuatnya sehingga yang pertama jauh lebih mudah ditelusuri daripada yang terakhir?

Orang bisa mengatakan bahwa itu hanyalah fakta bahwa orang memiliki "ramalan eksternal" dari kompiler yang menunjukkan kesalahan mereka yang membuat programmer malas, mencegah mereka dari melakukan apa yang diperlukan untuk menulis kode dengan keras. Pandangan ini akan berarti bahwa jika mereka tidak memiliki kompiler, mereka akan dapat sama sempurnanya dengan ahli matematika.

Anda mungkin menemukan ini persuasif, tetapi berdasarkan pengalaman saya pemrograman dan menulis bukti matematika, tampaknya secara intuitif bagi saya bahwa ini benar-benar bukan penjelasan. Tampaknya ada sesuatu yang secara fundamental berbeda dari kedua upaya tersebut.

Pikiran awal saya adalah, bahwa apa yang mungkin menjadi perbedaan, adalah bahwa untuk seorang ahli matematika, bukti yang benar hanya membutuhkan setiap langkah logis untuk menjadi benar. Jika setiap langkah benar, seluruh bukti benar. Di sisi lain, agar suatu program menjadi bugless, tidak hanya setiap baris kode harus benar, tetapi hubungannya dengan setiap baris kode lain dalam program harus bekerja juga.

Dengan kata lain, jika langkah di bukti benar, maka membuat kesalahan pada langkah tidak akan mengacaukan langkah pernah. Tetapi jika satu baris kode dituliskan dengan benar, maka membuat kesalahan pada baris akan mempengaruhi kerja baris , sehingga setiap kali kita menulis baris kita harus memperhitungkan hubungannya dengan semua baris lainnya. Kita dapat menggunakan enkapsulasi dan semua itu untuk membatasi hal ini, tetapi tidak dapat dihapus sepenuhnya.Y X X Y X $X$$Y$$X$$X$$Y$$X$$X$

Ini berarti bahwa prosedur untuk memeriksa kesalahan dalam bukti matematika pada dasarnya adalah linier dalam jumlah langkah-bukti, tetapi prosedur untuk memeriksa kesalahan dalam kode komputer pada dasarnya eksponensial dalam jumlah baris kode.

Bagaimana menurut anda?

Catatan: Pertanyaan ini memiliki sejumlah besar jawaban yang mengeksplorasi berbagai macam fakta dan sudut pandang. Sebelum Anda menjawab, harap baca semuanya dan jawab hanya jika Anda memiliki sesuatu yang baru untuk ditambahkan. Jawaban yang berlebihan, atau jawaban yang tidak mendukung pendapat dengan fakta, dapat dihapus.

Izinkan saya menawarkan satu alasan dan satu kesalahpahaman sebagai jawaban atas pertanyaan Anda.

The Alasan utama bahwa lebih mudah untuk menulis (tampaknya) bukti matematika yang benar adalah bahwa mereka ditulis pada tingkat yang sangat tinggi. Misalkan Anda dapat menulis program seperti ini:

function MaximumWindow(A, n, w):
    using a sliding window, calculate (in O(n)) the sums of all length-w windows
    return the maximum sum (be smart and use only O(1) memory)

Akan jauh lebih sulit untuk salah ketika memprogram seperti ini, karena spesifikasi program jauh lebih ringkas daripada implementasinya . Memang, setiap programmer yang mencoba mengubah kode pseudocode ke kode, terutama untuk kode yang efisien, menemukan jurang besar antara ide algoritma dan rincian implementasinya . Bukti matematika lebih berkonsentrasi pada ide dan kurang pada detail.

Mitra nyata dari kode untuk bukti matematika adalah bukti yang dibantu komputer . Ini jauh lebih sulit untuk dikembangkan daripada bukti tekstual biasa, dan orang sering menemukan berbagai sudut tersembunyi yang "jelas" bagi pembaca (yang biasanya bahkan tidak memperhatikannya), tetapi tidak begitu jelas bagi komputer. Juga, karena komputer hanya dapat mengisi celah yang relatif kecil saat ini, buktinya harus dijabarkan sedemikian rupa sehingga manusia yang membacanya akan kehilangan hutan untuk pepohonan.

Kesalahpahaman yang penting adalah bahwa bukti matematika seringkali benar. Bahkan, ini mungkin agak optimis. Sangat sulit untuk menulis bukti rumit tanpa kesalahan, dan kertas sering mengandung kesalahan. Mungkin kasus terbaru yang paling terkenal adalah upaya pertama Wiles di (kasus khusus) teorema modularitas (yang menyiratkan teorema terakhir Fermat), dan berbagai kesenjangan dalam klasifikasi kelompok sederhana hingga, termasuk sekitar 1.000 halaman tentang kelompok quasithin yang ditulis 20 tahun setelah klasifikasi seharusnya selesai.

Sebuah kesalahan dalam kertas Voevodsky membuatnya diragukan ditulis bukti sehingga ia mulai mengembangkan teori tipe homotopy , kerangka logis berguna untuk mengembangkan teori homotopy secara resmi, dan selanjutnya menggunakan komputer untuk memverifikasi semua kerja berikutnya (setidaknya menurut sendiri penerimaan). Walaupun ini adalah posisi yang ekstrem (dan saat ini, tidak praktis), tetap saja ketika menggunakan hasil, seseorang harus memeriksa buktinya dan memeriksa apakah itu benar. Di daerah saya ada beberapa makalah yang diketahui salah tetapi tidak pernah ditarik kembali, yang statusnya disampaikan dari mulut ke telinga di antara para ahli.

(Saya mungkin mengambil risiko beberapa downvotes di sini, karena saya tidak punya waktu / minat untuk membuat ini jawaban yang tepat, tetapi saya menemukan teks yang dikutip (dan sisa artikel yang dikutip) di bawah ini cukup mendalam, juga mengingat mereka ditulis oleh ahli matematika terkenal. Mungkin saya bisa meningkatkan jawabannya nanti.)

Idenya, yang saya kira tidak terlalu berbeda dari jawaban yang ada, adalah bahwa "bukti" atau argumen berkomunikasi dengan komunitas matematika, di mana tujuannya adalah untuk meyakinkan mereka bahwa rincian (membosankan) dapat diisi, pada prinsipnya, untuk mendapatkan bukti formal yang sepenuhnya ditentukan - tanpa sering melakukannya sama sekali. Salah satu contoh penting dari ini adalah bahwa Anda dapat menggunakan teorema yang ada hanya dengan menyatakannya, tetapi penggunaan kembali kode jauh lebih menantang secara umum. Juga pertimbangkan minor "bug", yang mungkin benar-benar membuat sepotong kode tidak berguna (misalnya, SEGFAULTs) tetapi mungkin meninggalkan argumen matematis sebagian besar utuh (yaitu, jika kesalahan dapat dikandung tanpa argumen runtuh).

Standar ketelitian dan kelengkapan yang diperlukan untuk membuat program komputer bekerja sama sekali adalah beberapa urutan besarnya lebih tinggi dari standar bukti valid komunitas matematika. Meskipun demikian, program komputer besar, bahkan ketika mereka telah ditulis dengan sangat hati-hati dan sangat hati-hati diuji, selalu tampaknya memiliki bug. [...] Matematika seperti yang kita praktikkan jauh lebih lengkap dan tepat secara formal daripada sains lain, tetapi secara formal kurang lengkap dan tepat untuk isinya daripada program komputer. Perbedaannya tidak hanya dengan jumlah usaha: jenis usaha berbeda secara kualitatif. Dalam program komputer besar, sebagian besar upaya harus dihabiskan untuk berbagai masalah kompatibilitas: memastikan bahwa semua definisi konsisten, mengembangkan "baik" struktur data yang memiliki generalisasi yang berguna tetapi tidak rumit, memutuskan generalisasi "benar" untuk fungsi, dll. Proporsi energi yang dihabiskan pada bagian kerja dari program besar, yang dibedakan dari bagian pembukuan, sangat kecil. Karena masalah kompatibilitas yang hampir tidak terelakkan meningkat karena definisi "benar" berubah ketika generalitas dan fungsionalitas ditambahkan, program komputer biasanya perlu sering ditulis ulang, sering dari awal.

TENTANG BUKTI DAN KEMAJUAN DALAM MATEMATIKA (hlm. 9-10), oleh WILLIAM P. THURSTON https://arxiv.org/pdf/math/9404236.pdf

Izinkan saya memulai dengan mengutip EW Dijkstra:

"Pemrograman adalah salah satu cabang matematika terapan yang paling sulit; matematikawan yang lebih miskin lebih baik tetap menjadi ahli matematika murni." (dari EWD498)

Meskipun apa yang dimaksud oleh Dijkstra dengan `pemrograman 'sedikit berbeda dari penggunaan saat ini, masih ada beberapa kelebihan dalam kutipan ini. Jawaban lain telah menyebutkan bahwa tingkat abstraksi dalam matematika diperbolehkan jauh lebih tinggi daripada dalam pemrograman, artinya kita dapat mengabaikan beberapa bagian yang rumit jika kita ingin melakukannya.

Namun, saya percaya bahwa ini hanyalah konsekuensi dari perbedaan yang lebih mendasar antara pembuktian dan program komputer, yang merupakan tujuan mereka .

Tujuan utama dari bukti matematika adalah, antara lain, untuk meyakinkan diri sendiri bahwa klaim matematika itu benar dan, bahkan mungkin lebih penting, untuk mencapai pemahaman . Oleh karena itu, Anda dapat memilih untuk hanya bekerja di dunia matematika, di mana segala sesuatu dibuat sedemikian rupa sehingga pemahaman dapat dicapai dengan desain (meskipun beberapa siswa memohon berbeda ...) Inilah yang dimaksudkan Dijkstra dengan "ahli matematika murni", mereka yang (Hampir) hanya memusatkan perhatian pada fakta-fakta matematika dan memahami sifat-sifatnya.

Jadi, Anda tidak perlu terkejut menghasilkan bukti yang benar relatif tahan terhadap kesalahan: itu adalah inti dari seluruh "latihan". (Tetap saja, ini tidak berarti kesalahan tidak atau hampir tidak ada, untuk berbuat kesalahan hanya manusia, kata mereka)

Sekarang, jika kita mempertimbangkan pemrograman, apa tujuan kita? Kami tidak benar-benar mencari pengertian, kami menginginkan sesuatu yang berhasil . Tetapi kapan sesuatu "bekerja"? Sesuatu berfungsi ketika kita berhasil membuat sesuatu yang memungkinkan beberapa mesin aneh untuk menyelesaikan tugas yang kita inginkan dan lebih disukai juga cukup cepat.

Saya percaya, ini adalah perbedaan mendasar, karena itu berarti bahwa tujuan kami tidak dapat dengan mudah dinyatakan sebagai beberapa teorema yang "dibuktikan" oleh program kami, kami menginginkan sesuatu di dunia nyata (apa pun itu), bukan beberapa artefak matematika. Ini berarti bahwa kita tidak dapat secara murni mencapai tujuan kita (walaupun Dijkstra ingin Anda mencobanya tanpa mempedulikan) karena kita harus menenangkan mesin, berharap bahwa kita benar-benar tahu tugas mana yang ingin kita lakukan dan juga menyadari hal-hal yang tidak dipertimbangkan, belum terjadi entah bagaimana.

Jadi, pada akhirnya, tidak ada jalan lain selain hanya mencobanya dan mungkin gagal, perbaiki, gagal dan coba lagi sampai kita agak puas dengan hasilnya.

Perhatikan bahwa hipotesis Anda menulis bukti kesalahan-kurang lebih sederhana daripada program kesalahan-kurang (yang sebenarnya pernyataan berbeda seperti yang ditunjukkan @ririel ) mungkin sebenarnya salah, karena bukti seringkali dibangun melalui coba-coba pada tingkat tertentu. Namun, saya berharap bahwa ini memberi titik terang pada pertanyaan yang tersirat: "Apa sebenarnya perbedaan antara membuktikan beberapa teorema dan menulis sebuah program?" (Untuk yang pengamat ceroboh koresponden Curry-Howard mungkin mengatakan: "Tidak ada sama sekali!")

Seperti @wvxvw disebutkan dalam komentar, paragraf berikut dari 'catatan tentang Pemrograman Terstruktur' (EWD249, halaman 21) sangat relevan:

(...) Program tidak pernah merupakan tujuan itu sendiri; tujuan suatu program adalah untuk membangkitkan perhitungan dan tujuan perhitungan adalah untuk membangun efek yang diinginkan. Meskipun program adalah produk akhir yang dibuat oleh programmer, perhitungan yang mungkin ditimbulkan olehnya - "pembuatan" yang diserahkan kepada mesin! - Adalah subjek sebenarnya dari perdagangannya. Misalnya, setiap kali seorang programmer menyatakan bahwa programnya benar, ia benar-benar membuat pernyataan tentang perhitungan yang mungkin ditimbulkannya.

(...) Dalam arti pembuatan program karena itu lebih sulit daripada pembuatan teori matematika: baik program dan teori terstruktur, objek abadi. Tetapi sementara teori matematika masuk akal seperti apa adanya, program hanya masuk akal melalui pelaksanaannya.

Lamport memberikan beberapa dasar untuk ketidaksepakatan tentang prevalensi kesalahan dalam bukti dalam Cara menulis bukti (halaman 8-9) :

Sekitar dua puluh tahun yang lalu, saya memutuskan untuk menulis bukti teorema Schroeder-Bernstein untuk kelas matematika pengantar. Bukti paling sederhana yang bisa saya temukan adalah dalam teks topologi umum klasik Kelley. Karena Kelley menulis untuk audiens yang lebih canggih, saya harus menambahkan banyak penjelasan pada bukti setengah halamannya. Saya telah menulis lima halaman ketika saya menyadari bahwa bukti Kelley salah. Baru-baru ini, saya ingin mengilustrasikan ceramah tentang gaya pembuktian saya dengan bukti salah yang meyakinkan, jadi saya menoleh ke Kelley. Saya tidak dapat menemukan apa pun yang salah dengan buktinya; tampaknya benar! Membaca dan membaca ulang bukti meyakinkan saya bahwa ingatan saya telah gagal, atau saya sangat bodoh dua puluh tahun yang lalu. Namun, bukti Kelley pendek dan akan menjadi contoh yang bagus, jadi saya mulai menulis ulang sebagai bukti terstruktur.

... Gaya ini pertama kali diterapkan pada bukti teorema biasa dalam makalah yang saya tulis bersama Martin Abadi. Dia sudah menulis bukti konvensional — bukti yang cukup baik untuk meyakinkan kami dan, mungkin, wasit. Menulis ulang bukti dalam gaya terstruktur, kami menemukan bahwa hampir setiap orang memiliki kesalahan serius, meskipun teorema itu benar. Setiap harapan bahwa bukti yang salah mungkin tidak mengarah pada teorema yang salah dihancurkan dalam kolaborasi kami berikutnya. Berkali-kali, kami akan membuat dugaan dan menulis sketsa bukti di papan tulis — sketsa yang bisa dengan mudah diubah menjadi bukti konvensional yang meyakinkan — hanya untuk menemukan, dengan mencoba menulis bukti terstruktur, bahwa dugaan itu salah. Sejak itu, saya tidak pernah percaya hasil tanpa bukti, terstruktur bukti.

Satu perbedaan besar adalah bahwa program biasanya ditulis untuk beroperasi pada input, sedangkan bukti matematis umumnya dimulai dari serangkaian aksioma dan teorema yang diketahui sebelumnya. Kadang-kadang Anda harus membahas beberapa kasus sudut untuk mendapatkan bukti yang cukup umum, tetapi kasus dan resolusi mereka secara eksplisit disebutkan dan cakupan hasilnya secara implisit dibatasi pada kasus-kasus yang dicakup.

Bandingkan ini dengan program komputer, yang harus menyediakan output 'benar' untuk berbagai input yang mungkin. Jarang mungkin untuk menyebutkan semua input dan mencoba semuanya. Lebih buruk lagi, seandainya program berinteraksi dengan manusia dan memungkinkan input mereka untuk memodifikasi fungsi? Manusia terkenal tidak dapat diprediksi dan jumlah input yang mungkin untuk program yang cukup besar dengan interaksi manusia tumbuh pada tingkat yang luar biasa. Anda perlu mencoba untuk meramalkan semua cara yang berbeda suatu program dapat digunakan dan mencoba untuk membuat semua kasus penggunaan itu berfungsi atau setidaknya gagal dengan cara yang masuk akal, ketika kegagalan adalah satu-satunya pilihan. Dan itu dengan asumsi Anda bahkan tahu bagaimana itu seharusnya bekerja dalam semua kasus sudut yang tidak jelas.

Akhirnya, sebuah program besar tidak dapat benar-benar dibandingkan dengan satu bukti, bahkan yang kompleks. Sebuah program besar mungkin lebih mirip dengan mengumpulkan dan meninjau perpustakaan literatur kecil, beberapa di antaranya mungkin memiliki kesalahan yang perlu Anda selesaikan. Untuk program yang lebih pada skala bukti tunggal, yang mungkin merupakan implementasi algoritma kecil, katakanlah, insinyur perangkat lunak yang berpengalaman dapat / menyelesaikannya tanpa membuat kesalahan, terutama ketika menggunakan alat modern yang mencegah / menyelesaikan kesalahan sepele yang umum (seperti kesalahan ejaan ) yang setara dengan masalah awal yang akan Anda selesaikan dalam proofreading.

Mereka mengatakan masalah dengan komputer adalah mereka melakukan persis seperti yang Anda katakan.

Saya pikir ini mungkin salah satu dari banyak alasan.

Perhatikan bahwa, dengan program komputer, penulis (Anda) cerdas tetapi pembaca (CPU) bodoh.
Tetapi dengan bukti matematis, penulis (Anda) pintar dan pembaca (peninjau) juga pintar.

Ini berarti Anda tidak akan pernah mampu masuk ke situasi "baik, Anda tahu apa yang saya maksud " dengan komputer. Itu melakukan persis apa yang Anda katakan, tanpa mengetahui niat Anda.

Sebagai contoh, katakanlah ini adalah langkah dalam beberapa bukti:

$x^2+4x+3$$x+3$$x = -3$

Satu masalah yang saya pikir tidak dibahas dalam jawaban Yuval, adalah sepertinya Anda membandingkan hewan yang berbeda.

$n$$n!$

Memverifikasi sifat semantik program tidak dapat diputuskan (teorema Rice), dan secara analog, memeriksa apakah pernyataan dalam logika predikat urutan pertama benar juga tidak dapat diputuskan. Intinya adalah bahwa tidak ada perbedaan nyata dalam kekerasan dari cara Anda melihat masalah. Di sisi lain, kita dapat beralasan tentang sifat sintaksis program (kompiler), dan ini analog dengan fakta bahwa kita dapat memverifikasi bukti. Bug (kode tidak melakukan apa yang saya inginkan) semantik, jadi Anda harus membandingkannya dengan rekanan yang benar.

Saya akan memperkuat Yuval dan mengatakan bahwa seluruh bidang tumbuh dengan motivasi penulisan bukti matematis yang dapat ditulis dan diverifikasi dalam beberapa sistem formal, sehingga bahkan proses verifikasi sama sekali tidak sepele.

Apa yang begitu berbeda tentang penulisan bukti matematis tanpa cacat dan penulisan kode komputer tanpa cacat yang membuatnya sedemikian rupa sehingga yang pertama jauh lebih mudah ditelusuri daripada yang terakhir?

Saya percaya bahwa alasan utama adalah idempotensi (memberikan hasil yang sama untuk input yang sama) dan kekekalan (tidak berubah).

Bagaimana jika bukti matematis dapat memberikan hasil yang berbeda jika dibaca pada hari Selasa atau ketika tahun naik menjadi 2000 dari tahun 1999? Bagaimana jika bagian dari bukti matematika adalah untuk kembali beberapa halaman, menulis ulang beberapa baris, dan kemudian mulai lagi dari titik itu?

Saya yakin bahwa bukti seperti itu akan hampir sama rentan terhadap bug seperti segmen normal kode komputer.

Saya melihat faktor sekunder lainnya juga:

1. Matematikawan biasanya jauh lebih berpendidikan sebelum mencoba menulis bukti yang signifikan / dapat diterbitkan. 1/4 pengembang profesional self-titled mulai mengkode kurang dari 6 tahun yang lalu (lihat survei SO 2017 ), tetapi saya berasumsi sebagian besar matematikawan memiliki lebih dari satu dekade pendidikan matematika formal.
2. Bukti matematis jarang dimiliki pada tingkat pengawasan yang sama dengan kode komputer. Satu kesalahan ketik dapat / akan merusak program, tetapi lusinan kesalahan ketik mungkin tidak cukup untuk menghancurkan nilai bukti (hanya keterbacaannya).
3. Iblis ada di dalam perincian, dan kode komputer tidak dapat melewatkan perincian. Bukti bebas untuk melewati langkah-langkah yang dianggap sederhana / rutin. Ada beberapa gula sintaksis yang bagus tersedia dalam bahasa modern, tetapi ini adalah hard-coded dan perbandingannya sangat terbatas.
4. Matematika lebih tua dan memiliki fondasi / inti yang lebih solid. Tentu saja ada banyak subbidang baru dan mengkilap dalam matematika, tetapi sebagian besar prinsip inti telah digunakan selama beberapa dekade. Ini mengarah pada stabilitas. Di sisi lain, programmer masih tidak setuju pada metodologi pengkodean dasar (hanya bertanya tentang pengembangan Agile dan tingkat adopsi).

Saya setuju dengan apa yang ditulis Yuval. Tetapi juga memiliki jawaban yang jauh lebih sederhana: Dalam praktiknya, perangkat lunak insinyur biasanya bahkan tidak mencoba memeriksa kebenaran program mereka, mereka tidak, mereka biasanya bahkan tidak menuliskan kondisi yang menentukan kapan program itu benar.

Ada berbagai alasan untuk itu. Salah satunya adalah bahwa sebagian besar insinyur perangkat lunak tidak memiliki keterampilan untuk merumuskan masalah dengan jelas secara matematis atau mereka tidak tahu bagaimana menulis bukti kebenaran.

Yang lain adalah bahwa mendefinisikan kondisi kebenaran untuk sistem perangkat lunak yang kompleks (khususnya yang didistribusikan) adalah tugas yang sangat sulit dan memakan waktu. Mereka diharapkan memiliki sesuatu yang tampaknya berfungsi dalam hitungan minggu.

Alasan lain adalah bahwa kebenaran suatu program tergantung pada banyak sistem lain yang ditulis oleh orang lain yang lagi-lagi tidak memiliki semantik yang jelas. Ada hukum Hyrum yang pada dasarnya mengatakan jika perpustakaan / layanan Anda memiliki perilaku yang dapat diamati (bukan bagian dari kontraknya) seseorang pada akhirnya akan bergantung padanya. Itu pada dasarnya berarti gagasan mengembangkan perangkat lunak dalam bentuk modular dengan kontrak yang jelas seperti lemmas dalam matematika tidak berfungsi dalam praktiknya. Semakin buruk dalam bahasa di mana refleksi digunakan. Bahkan jika suatu program benar hari ini, ia mungkin rusak besok ketika seseorang melakukan beberapa refactoring sepele di salah satu dependensinya.

Dalam praktiknya apa yang biasanya terjadi adalah mereka menjalani tes. Tes bertindak seperti apa yang diharapkan dari program. Setiap kali bug baru ditemukan, mereka menambahkan tes untuk menangkapnya. Ia bekerja sampai batas tertentu, tetapi itu bukan bukti kebenaran.

Ketika orang tidak memiliki keterampilan untuk mendefinisikan kebenaran atau menulis program yang benar atau diharapkan untuk melakukannya dan itu agak sulit, tidak mengherankan bahwa perangkat lunak tidak benar.

Tetapi perhatikan juga bahwa pada akhirnya di tempat yang lebih baik, rekayasa perangkat lunak dilakukan dengan tinjauan kode. Itu adalah penulis suatu program harus meyakinkan setidaknya satu orang lain bahwa program tersebut bekerja dengan benar. Itulah poin beberapa argumen informal tingkat tinggi dibuat. Tetapi sekali lagi biasanya tidak ada yang dekat dengan definisi yang benar tentang kebenaran atau bukti kebenaran yang terjadi.

Dalam matematika orang berfokus pada kebenaran. Dalam pengembangan perangkat lunak ada banyak hal yang perlu diperhatikan oleh seorang programmer dan ada trade-off di antara mereka. Memiliki perangkat lunak bebas bug atau bahkan definisi yang benar tentang kebenaran (dengan persyaratan berubah dari waktu ke waktu) adalah ideal, tetapi itu harus ditukar dengan faktor-faktor lain dan salah satu yang paling penting di antara mereka adalah waktu yang dihabiskan untuk mengembangkannya dengan yang sudah ada pengembang. Jadi dalam praktiknya di tempat yang lebih baik tujuan dan proses mengurangi risiko bug sebanyak mungkin daripada membuat perangkat lunak bebas bug.

Sudah ada banyak jawaban bagus tetapi masih ada banyak alasan mengapa matematika dan pemrograman tidak sama.

1 Bukti matematika cenderung jauh lebih sederhana daripada program komputer. Pertimbangkan langkah-langkah pertama dari bukti hipotetis:

Biarkan a menjadi bilangan bulat

Biarkan b menjadi bilangan bulat

Misalkan c = a + b

Sejauh ini buktinya baik-baik saja. Mari kita ubah itu menjadi langkah pertama dari program serupa:

Biarkan a = input ();

Biarkan b = input ();

Misalkan c = a + b;

Kami sudah memiliki segudang masalah. Dengan asumsi bahwa pengguna benar-benar memasukkan bilangan bulat, kita harus memeriksa batasannya. Adalah suatu yang lebih besar dari -32.768 (atau apa pun min int pada sistem Anda)? Adalah sebuah kurang dari 32.767? Sekarang kita harus memeriksa hal yang sama untuk b . Dan karena kami telah menambahkan a dan b programnya tidak benar kecuali a + blebih besar dari -32768 dan kurang dari 32767. Itu 5 kondisi terpisah yang harus dikhawatirkan oleh seorang programmer yang bisa diabaikan oleh seorang ahli matematika. Tidak hanya programmer harus khawatir tentang mereka, dia harus mencari tahu apa yang harus dilakukan ketika salah satu dari kondisi tersebut tidak terpenuhi dan menulis kode untuk dilakukan kapan pun dia telah memutuskan adalah cara untuk menangani kondisi tersebut. Matematika itu sederhana. Pemrogramannya sulit.

2 Penanya tidak mengatakan apakah dia merujuk pada kesalahan waktu kompilasi atau kesalahan waktu berjalan, tetapi para programmer umumnya tidak peduli dengan kesalahan waktu kompilasi. Compiler menemukannya dan mudah diperbaiki. Mereka seperti kesalahan ketik. Seberapa sering orang mengetik beberapa paragraf tanpa kesalahan pertama kali?

3 Pelatihan.Sejak usia sangat muda kita diajarkan untuk berhitung, dan kita menghadapi konsekuensi kesalahan kecil berulang-ulang. Seorang ahli matematika yang terlatih harus mulai memecahkan masalah aljabar multi-langkah biasanya di sekolah menengah dan harus melakukan lusinan (atau lebih) masalah seperti itu setiap minggu selama satu tahun. Satu tanda negatif yang hilang menyebabkan seluruh masalah salah. Setelah aljabar masalah menjadi lebih lama dan lebih sulit. Programmer, di sisi lain, biasanya memiliki pelatihan yang jauh lebih formal. Banyak yang belajar sendiri (setidaknya pada awalnya) dan tidak mendapatkan pelatihan formal sampai universitas. Bahkan di tingkat universitas, para programmer harus mengambil beberapa kelas matematika sementara para matematikawan mungkin mengambil satu atau dua kelas pemrograman.

Saya suka jawaban Yuval, tapi saya ingin mengatasinya sebentar. Salah satu alasan Anda mungkin menemukan lebih mudah untuk menulis bukti Matematika mungkin bermuara pada bagaimana ontologi Matematika platonis. Untuk melihat apa yang saya maksud, pertimbangkan hal berikut:

• Fungsi dalam Matematika murni (seluruh hasil pemanggilan fungsi benar-benar dienkapsulasi dalam nilai pengembalian, yang bersifat deterministik dan dihitung sepenuhnya dari nilai input).
• Matematika tidak memiliki mutasi atau penugasan kembali (ketika Anda perlu memodelkan hal-hal seperti itu, fungsi dan urutan digunakan).
• Matematika secara referensial transparan (misalnya tidak ada pointer, tidak ada gagasan tentang panggilan dengan nama vs panggilan dengan nilai) dan objek matematika memiliki semantik kesetaraan ekstensional (jika "dua" benda itu sama dalam setiap cara yang dapat diamati, maka mereka sebenarnya hal yang sama).

Meskipun dapat diperdebatkan apakah pembatasan di atas membuat penulisan suatu program lebih mudah, saya pikir ada kesepakatan luas bahwa pembatasan di atas membuat penalaran tentang suatu program lebih mudah. Hal utama yang Anda lakukan ketika menulis bukti Matematika adalah alasan tentang bukti yang Anda tulis saat ini (karena, tidak seperti dalam pemrograman, Anda tidak perlu menduplikasi upaya dalam Matematika karena abstraksi gratis), jadi umumnya layak untuk bersikeras pada pembatasan di atas.

Bukti matematika mendasar tidak sama dengan aplikasi dunia nyata, yang dirancang untuk memenuhi kebutuhan manusia hidup.

Manusia akan mengubah keinginan, kebutuhan, dan persyaratan mereka pada apa yang mungkin menjadi basis harian dalam bidang program komputer.

Apa yang begitu berbeda tentang penulisan bukti matematis tanpa cacat dan penulisan kode komputer tanpa cacat yang membuatnya sedemikian rupa sehingga yang pertama jauh lebih mudah ditelusuri daripada yang terakhir?

Dengan persyaratan sejelas masalah matematika, program yang sempurna dapat ditulis. Membuktikan bahwa algoritma Dijkstra dapat menemukan jalur terpendek antara dua titik pada grafik tidak sama dengan mengimplementasikan program yang menerima input sewenang-wenang dan menemukan titik terpendek antara dua titik di dalamnya.

Ada masalah memori, kinerja, dan perangkat keras yang harus dikelola. Saya berharap kita tidak dapat berpikir tentang itu ketika menulis algoritma, bahwa kita dapat menggunakan konstruksi murni dan fungsional untuk mengelola ini, tetapi program komputer hidup di dunia "nyata" perangkat keras sedangkan bukti matematis berada di ... "teori".

Atau, untuk lebih ringkas :

Melihatnya dari sudut lain, dalam lingkungan non-akademis sering kali menjadi masalah uang.

Seperti yang dinyatakan oleh tulisan lain dengan baik, Matematika adalah spesifikasi abstrak tunggal, oleh karena itu bukti perlu bekerja secara konsisten hanya dalam spesifikasi yang harus dibuktikan. Sebuah program komputer dapat beroperasi pada banyak implementasi spesifikasi abstrak matematika - yaitu cara satu bahasa, atau produsen perangkat keras menerapkan matematika floating point mungkin sedikit berbeda dari yang lain yang dapat menyebabkan sedikit fluktuasi hasil.

Dengan demikian, 'membuktikan' program komputer sebelum menulis itu akan melibatkan pembuktian logika pada tingkat perangkat keras, tingkat sistem operasi, tingkat driver, bahasa pemrograman, kompiler, mungkin juru bahasa dan sebagainya, untuk setiap kemungkinan kombinasi perangkat keras yang dimiliki program tersebut. bisa dijalankan dan mungkin data apa pun yang diminumnya. Anda mungkin akan menemukan tingkat persiapan dan pemahaman ini tentang misi ruang angkasa, sistem senjata atau sistem kontrol tenaga nuklir, di mana kegagalan berarti puluhan miliar dolar yang hilang dan berpotensi banyak nyawa yang hilang, tetapi tidak banyak yang lain.

Untuk programmer dan / atau bisnis 'sehari-hari' Anda, jauh, jauh lebih hemat biaya untuk menerima tingkat akurasi tertentu dalam sebagian besar kode yang benar dan menjual produk yang dapat digunakan, dan pengembang dapat memperbaiki bug secara retroaktif saat mereka ditemukan selama prosesnya. pemakaian.

Saya pikir alasan Anda valid, tetapi input Anda tidak. Bukti matematika sama sekali tidak lebih toleran terhadap kesalahan daripada program, jika keduanya ditulis oleh manusia. Dijkstra sudah dikutip di sini, tetapi saya akan menawarkan penawaran tambahan.

Namun kita harus mengatur perhitungan sedemikian rupa sehingga kekuatan kita yang terbatas cukup untuk menjamin bahwa perhitungan akan menghasilkan efek yang diinginkan. Pengorganisasian ini mencakup komposisi program dan di sana kita dihadapkan dengan masalah ukuran berikutnya, yaitu. panjang teks program, dan kita harus memberikan masalah ini juga pengakuan eksplisit. Kita harus tetap menyadari fakta bahwa sejauh mana kita dapat membaca atau menulis teks sangat tergantung pada ukurannya. [...]

Dalam suasana yang sama saya ingin menarik perhatian pembaca pada fakta bahwa "kejelasan" telah menyatakan aspek-aspek kuantitatif, fakta yang oleh banyak matematikawan, cukup aneh, tampaknya tidak menyadarinya. Teorema yang menyatakan validitas kesimpulan ketika sepuluh halaman penuh dengan kondisi terpenuhi bukanlah alat yang mudah, karena semua kondisi harus diverifikasi setiap kali teorema tersebut diajukan. Dalam geometri Euclidean, Teorema Pythagoras berlaku untuk setiap tiga titik A, B dan C sedemikian sehingga melalui A dan C garis lurus dapat ditarik ortogonal ke garis lurus melalui B dan C. Berapa banyak matematikawan yang menghargai bahwa teorema tetap berlaku ketika beberapa atau semua poin A, B, dan C bertepatan? namun ini tampaknya sebagian besar bertanggung jawab atas kenyamanan yang dengannya Teorema Pythagoras dapat digunakan.

Meringkas: sebagai manusia yang berakal, saya memiliki kepala yang sangat kecil dan saya lebih baik belajar untuk hidup dengannya dan untuk menghormati keterbatasan saya dan memberi mereka kredit penuh, daripada mencoba untuk mengabaikannya, karena upaya sia-sia yang terakhir akan menjadi dihukum karena kegagalan.

Ini sedikit diedit tiga paragraf terakhir dari bab pertama Pemrograman Terstruktur Dijkstra.

Untuk mungkin mengulangi ini, untuk menerapkan lebih baik untuk pertanyaan Anda: kebenaran sebagian besar adalah fungsi ukuran bukti Anda. Ketepatan bukti matematis yang panjang sangat sulit untuk dibangun (banyak "bukti" yang diterbitkan hidup dalam ketidakpastian karena tidak ada yang benar-benar memverifikasi mereka). Tetapi, jika Anda membandingkan kebenaran program sepele dengan bukti sepele, kemungkinan tidak ada perbedaan nyata. Namun, asisten bukti otomatis (dalam arti yang lebih luas, kompiler Java Anda juga merupakan asisten bukti), biarkan program menang dengan mengotomatiskan banyak pekerjaan dasar.

Seperti jawaban lain telah menyentuh dalam jawaban mereka (saya ingin menguraikan), tetapi sebagian besar masalah adalah penggunaan perpustakaan. Bahkan dengan dokumentasi yang sempurna (seperti kode bugless), tidak mungkin untuk mentransfer pengetahuan lengkap perpustakaan ke setiap pemrogram yang menggunakan perpustakaan. Jika pemrogram tidak sepenuhnya memahami perpustakaan mereka, mereka dapat membuat kesalahan saat menggunakannya. Kadang-kadang ini dapat mengakibatkan bug kritis yang ditemukan ketika kode tidak berfungsi. Tetapi untuk bug minor, ini mungkin tidak diperhatikan.

Situasi serupa akan terjadi jika ahli matematika menggunakan bukti dan lemma yang ada tanpa sepenuhnya memahaminya; bukti mereka sendiri kemungkinan besar akan cacat. Meskipun ini mungkin menyarankan solusi adalah dengan sempurna mempelajari setiap perpustakaan yang digunakan; ini praktis sangat memakan waktu dan mungkin membutuhkan pengetahuan domain yang tidak dimiliki oleh programmer. (Saya tahu sedikit tentang sekuensing DNA / sintesis protein; namun dapat bekerja dengan konsep-konsep ini menggunakan perpustakaan).

Secara lebih ringkas, rekayasa perangkat lunak (rekayasa secara umum benar-benar) didasarkan pada merangkum berbagai tingkat abstraksi untuk memungkinkan orang untuk fokus pada area yang lebih kecil dari masalah yang menjadi spesialisasi mereka. Hal ini memungkinkan orang untuk mengembangkan keahlian di bidang mereka, tetapi juga membutuhkan komunikasi yang sangat baik antara setiap lapisan. Ketika komunikasi itu tidak sempurna, itu menyebabkan masalah.

Saya akan mencoba menjadi orisinil setelah semua jawaban bagus itu.

Program adalah bukti

The Curry-Howard isomorphism memberitahu kita, jenis dalam program Anda adalah teorema dan kode aktual adalah bukti mereka.

Memang, ini adalah pandangan yang sangat abstrak dan tingkat tinggi. Masalah yang Anda, mungkin, maksudkan, adalah bahwa menulis kode khusus lebih sulit karena terlalu rendah. Dalam kebanyakan kasus, Anda "perlu memberi tahu mesin apa yang harus dilakukan". Atau, untuk melihat ini dari sudut lain: matematikawan sangat pandai abstraksi.

Sebagai catatan: "Musik aliran" adalah salah satu jembatan terindah di antara keduanya. Pada dasarnya set up hal yang bisa mengatakan "Saya ingin ini di bahwa cara" dan mesin ajaib melakukan ini persis seperti yang diinginkan.

Tidak satu pun dari banyak jawaban lain yang menunjukkan hal berikut. Bukti matematika beroperasi pada sistem komputasi imajiner yang memiliki memori tak terbatas dan daya komputasi tak terbatas. Oleh karena itu mereka dapat menyimpan angka yang besar secara arbitrer hingga presisi tak terbatas, dan tidak kehilangan presisi dalam perhitungan apa pun.

$\pi$

Ini bukan. Bukti matematika pada dasarnya sama persis seperti kereta, hanya saja pembaca mereka lebih permisif daripada seorang penyusun. Demikian pula, para pembaca program komputer mudah tertipu untuk percaya itu benar, setidaknya sampai mereka mencoba menjalankannya.

Misalnya, jika kami mencoba menerjemahkan bukti matematika ke dalam bahasa formal seperti ZFC, itu juga akan mengandung bug. Itu karena bukti-bukti ini bisa sangat lama sehingga kami terpaksa menulis sebuah program untuk menghasilkan bukti. Hanya sedikit orang yang menghadapi masalah, dalam bahaya, meskipun ada penelitian aktif dalam memformalkan bukti-bukti dasar.

Dan memang, matematika bisa mendapatkan BSOD! Ini bukan pertama kalinya!

Gagasan ortodoks ini bahwa semua bukti matematika yang telah cukup diverifikasi pada dasarnya benar atau dapat dibuat benar adalah yang sama memotivasi proyek perangkat lunak Anda di tempat kerja: selama kita tetap pada roadmap, kita akan mengeluarkan semua bug dan fitur lengkap - ini merupakan proses berulang yang mengarah ke produk akhir yang pasti.

Inilah sisi sebaliknya. Lihat, kami sudah mendapatkan dana, memvalidasi konsep bisnis, semua dokumen ada di sini untuk Anda baca. Kami hanya ingin Anda mengeksekusi dan itu pasti!

Jangan merasa kasihan pada Hilbert juga, dia tahu apa yang sedang dia hadapi. Itu hanya bisnis.

Jika Anda ingin benar-benar yakin, ambil semuanya berdasarkan kasus per kasus dan buat kesimpulan Anda sendiri!

Saya melihat dua alasan penting mengapa program lebih rentan kesalahan daripada bukti matematika:

1: Program berisi variabel atau objek dinamis yang berubah seiring waktu, sedangkan objek matematika dalam pembuktian biasanya statis. Dengan demikian, notasi dalam matematika dapat digunakan sebagai dukungan langsung dari penalaran, (dan jika a = b, ini tetap terjadi) di mana ini tidak berfungsi dalam program. Juga, masalah ini menjadi jauh lebih buruk di mana program paralel atau memiliki banyak utas.

2: Matematika sering mengasumsikan objek yang didefinisikan dengan relatif rapi (grafik, manifold, cincin, grup, dll.) Sedangkan pemrograman berkaitan dengan objek yang sangat berantakan dan agak tidak beraturan: aritmatika presisi terbatas, tumpukan terbatas, konversi bilangan bulat karakter, pointer, sampah yang memerlukan pengumpulan , dll. Oleh karena itu, kumpulan kondisi yang relevan dengan kebenaran sangat sulit untuk diingat.

Anda harus membedakan dua "kategori" yang berbeda:

• pseudo-proofs (atau pseudo-code) - itulah yang Anda lihat di buku. Itu ditulis dalam bahasa alami (misalnya dalam bahasa Inggris). Itulah yang harus Anda gunakan untuk belajar Matematika (atau Algoritma).
• bukti formal (atau kode formal) - Anda menulisnya saat Anda membutuhkan bukti (atau kode) Anda untuk diverifikasi secara mekanis (atau dapat dieksekusi). Representasi semacam itu tidak memerlukan "kecerdasan manusia". Itu dapat diverifikasi (atau dieksekusi) secara mekanis, dengan mengikuti beberapa langkah yang telah ditentukan (biasanya dilakukan oleh komputer saat ini).

Kami telah menggunakan pseudo-code selama ribuan tahun (misalnya algoritma Euclids). Menulis kode formal (dalam bahasa formal seperti C atau Java) menjadi sangat populer dan berguna setelah ditemukannya komputer. Tetapi, sayangnya, bukti formal (dalam bahasa formal seperti Principia Mathematica atau Metamath) tidak terlalu populer. Dan karena semua orang menulis bukti palsu hari ini, orang sering berdebat tentang bukti baru. Kesalahan di dalamnya dapat ditemukan bertahun-tahun, dekade atau bahkan berabad-abad setelah "pembuktian" yang sebenarnya.

Saya tidak dapat menemukan referensi, tetapi saya pikir Tony Hoare pernah mengatakan sesuatu di sepanjang baris berikut: Perbedaan antara memeriksa program dan memeriksa bukti adalah bahwa bukti dapat diperiksa dua baris sekaligus.

Dalam satu kata: lokalitas.

Bukti ditulis sehingga mereka dapat dengan mudah diperiksa. Program ditulis sehingga mereka dapat dieksekusi. Untuk alasan ini, pemrogram biasanya meninggalkan informasi yang akan berguna bagi seseorang yang memeriksa program.

Pertimbangkan program ini, di mana x hanya-baca

    assume x >= 0
    p := 0 ;
    var pp := 0 ;
    while( x >= pp + 2*p + 1 ) 
    {
        var q := 1 ;
        var qq := q ;
        var pq := p ;
        while(  pp + 4*pq + 4*qq <= x )
        {
            q, pq, qq := 2*q, 2*pq, 4*qq ;
        }
        p, pp := p + q, pp + 2*pq + qq ;
    }
    assert  p*p <= x < (p+1)*(p+1)

Mudah dieksekusi, tetapi sulit untuk diperiksa.

Tetapi jika saya menambahkan kembali dalam pernyataan yang hilang, Anda dapat memeriksa program secara lokal dengan hanya memeriksa bahwa setiap urutan penugasan sudah benar dengan memperhatikan pra-dan postkondisinya dan bahwa, untuk setiap loop, postkondisi dari loop diimplikasikan oleh invarian dan negasi dari guard loop.

    assume x >= 0
    p := 0 ;
    var pp := 0 ; 
    while( x >= pp + 2*p + 1 ) 
        invariant p*p <= x 
        invariant pp == p*p
        decreases x-p*p 
    {
        var q := 1 ;
        var qq := q ; 
        var pq := p ; 
        while(  pp + 4*pq + 4*qq <= x )
            invariant (p+q)*(p+q) <= x
            invariant q > 0 
            invariant qq == q*q 
            invariant pq == p*q 
            decreases x-(p+q)*(p+q)
        {
            q, pq, qq := 2*q, 2*pq, 4*qq ;
        }
        assert (p+q)*(p+q) <= x and pp==p*p and pq==p*q and qq==q*q and q>0
        p, pp := p + q, pp + 2*pq + qq ;
    }
    assert  p*p <= x < (p+1)*(p+1)

Kembali ke pertanyaan awal: Mengapa menuliskan bukti matematis lebih membuktikan kesalahan daripada menulis kode komputer? Karena bukti dirancang agar mudah diperiksa oleh pembaca mereka, mereka mudah diperiksa oleh penulisnya dan karenanya penulis yang waspada cenderung tidak membuat (atau setidaknya menyimpan) kesalahan logis dalam bukti mereka. Ketika kita memprogram, kita sering gagal menuliskan alasan bahwa kode kita benar; akibatnya adalah sulit bagi pembaca dan pembuat program untuk memeriksa kode; hasilnya adalah penulis membuat (dan kemudian menyimpan) kesalahan.

Tapi ada harapan. Jika, ketika kita menulis suatu program, kita juga menuliskan alasan kita menganggap program itu benar, kita kemudian dapat memeriksa kodenya ketika kita menuliskannya dan dengan demikian menulis lebih sedikit kode buggy. Ini juga bermanfaat bagi orang lain untuk membaca kode kami dan memeriksanya sendiri.

Kita dapat bertanya apakah lebih sulit dalam praktiknya , atau pada prinsipnya , untuk menulis bukti atau menulis kode.

Dalam praktiknya, membuktikan jauh lebih sulit daripada pengkodean. Sangat sedikit orang yang telah mengambil dua tahun matematika tingkat perguruan tinggi dapat menulis bukti, bahkan yang sepele. Di antara orang-orang yang telah mengambil dua tahun CS tingkat perguruan tinggi, mungkin setidaknya 30% dapat menyelesaikan FizzBuzz .

Namun pada prinsipnya , ada alasan mendasar mengapa sebaliknya. Bukti dapat, setidaknya secara prinsip, diperiksa kebenarannya melalui proses yang tidak memerlukan penilaian atau pemahaman apa pun. Program tidak bisa - kita bahkan tidak bisa mengatakan, melalui proses yang ditentukan, apakah suatu program akan berhenti.

Hanya sebagian kecil dari pernyataan matematika yang benar yang dapat dibuktikan secara praktis. Lebih penting lagi, tidak mungkin untuk membangun set aksioma matematis non-sepele (*) yang akan memungkinkan semua pernyataan benar untuk dibuktikan. Jika seseorang hanya perlu menulis program untuk melakukan sebagian kecil dari hal-hal yang dapat dilakukan dengan komputer, akan mungkin untuk menulis perangkat lunak yang benar-benar terbukti, tetapi komputer sering diminta untuk melakukan hal-hal di luar jangkauan apa yang terbukti benar benar perangkat lunak dapat mencapai.

(*) Adalah mungkin untuk mendefinisikan seperangkat aksioma yang akan memungkinkan semua pernyataan benar untuk disebutkan, dan dengan demikian terbukti, tetapi itu umumnya tidak terlalu menarik. Meskipun dimungkinkan untuk secara resmi mengkategorikan serangkaian aksioma ke dalam aksioma yang atau tidak, secara relatif, non-sepele, poin kuncinya adalah bahwa keberadaan pernyataan yang dapat dibuktikan yang benar tetapi tidak dapat dibuktikan bukanlah cacat dalam suatu set. aksioma. Menambahkan aksioma untuk membuat pernyataan yang benar tetapi tidak dapat dibuktikan yang dapat dibuktikan akan menyebabkan pernyataan lain menjadi benar tetapi tanpa dapat dibuktikan.

1. Program komputer diuji di dunia nyata. Kesalahan teknis yang rumit dalam bukti matematis yang panjang, yang hanya dapat dipahami oleh sejumlah kecil orang, memiliki peluang bagus untuk tetap tidak terdeteksi. Jenis kesalahan yang sama dalam produk perangkat lunak cenderung menghasilkan perilaku aneh yang diperhatikan pengguna biasa. Jadi premisnya mungkin tidak benar.

2. Program komputer melakukan fungsi dunia nyata yang bermanfaat. Mereka tidak harus 100% benar untuk melakukan ini, dan standar kebenaran yang tinggi cukup mahal. Bukti hanya berguna jika mereka benar-benar membuktikan sesuatu, sehingga melewatkan bagian '100% benar' bukanlah pilihan bagi matematikawan.

3. Bukti matematika didefinisikan dengan jelas. Jika bukti cacat, penulis telah melakukan kesalahan. Banyak bug dalam program komputer terjadi karena persyaratan tidak dikomunikasikan dengan benar, atau ada masalah kompatibilitas dengan sesuatu yang belum pernah didengar oleh programmer.

4. Banyak program komputer tidak dapat dibuktikan benar. Mereka mungkin memecahkan masalah yang didefinisikan secara informal seperti mengenali wajah. Atau mereka mungkin seperti perangkat lunak prediksi pasar saham dan memiliki tujuan yang ditentukan secara formal tetapi melibatkan terlalu banyak variabel dunia nyata.

Sebagian besar matematika sebagai aktivitas manusia adalah pengembangan bahasa khusus domain di mana verifikasi bukti mudah dilakukan manusia.

Kualitas bukti berbanding terbalik dengan panjang dan kompleksitasnya. Panjang dan kompleksitasnya sering dikurangi dengan mengembangkan notasi yang baik untuk menggambarkan situasi yang sedang kita buat tentang pernyataan, bersama dengan konsep tambahan yang berinteraksi dalam bukti khusus yang sedang dipertimbangkan.

Ini bukan proses yang mudah, dan sebagian besar bukti yang disaksikan oleh orang-orang yang dihapus dari garis depan penelitian kebetulan berada di bidang matematika (seperti aljabar dan analisis) yang telah memiliki ratusan, jika tidak ribuan, tahun di mana notasi bidang itu telah telah disempurnakan ke titik di mana tindakan benar-benar menuliskan bukti terasa seperti angin.

Namun, di garis depan penelitian, terutama jika Anda bekerja pada masalah yang tidak di bidang dengan notasi yang mapan atau berkembang dengan baik, saya akan bertaruh kesulitan bahkan menulis bukti yang benar mendekati kesulitan menulis program yang benar. Ini karena Anda juga harus menulis analog dari desain bahasa pemrograman, melatih jaringan saraf Anda untuk mengompilasinya dengan benar, coba tulis buktinya, kehabisan memori, coba optimalkan bahasa, iterate otak Anda belajar bahasa, menulis buktinya lagi, dll.

Untuk mengulangi, saya pikir bahwa menulis bukti yang benar dapat mendekati kesulitan menulis program yang benar di bidang matematika tertentu, tetapi bidang-bidang itu masih muda dan kurang berkembang karena gagasan kemajuan dalam matematika terkait erat dengan kemudahan pembuktian verifikasi.

Cara lain untuk mengutarakan poin yang ingin saya sampaikan adalah bahwa baik bahasa pemrograman dan matematika pada akhirnya dirancang sedemikian rupa sehingga masing-masing program komputer dan bukti dimungkinkan untuk dikompilasi. Hanya saja menyusun program komputer dilakukan di komputer dan memastikan kebenaran sintaksis yang biasanya tidak ada hubungannya dengan kebenaran program itu sendiri, sementara "menyusun" bukti dilakukan oleh manusia dan memastikan kebenaran sintaksis yang merupakan hal yang sama dengan kebenaran buktinya.

Anda jujur ​​membandingkan apel dan jeruk di sini. Anti-kesalahan dan bebas bug bukanlah hal yang sama.

Jika sebuah program membandingkan angka 2dan 3dan mengatakan itu 2 is greater than 3, maka itu bisa jadi karena implementasi kereta:

# Buggy implementation
function is_a_greater_than_b(a,b):
  return b > a

Program ini masih bebas dari kesalahan. Saat membandingkan dua angka adan b, itu akan selalu dapat memberi tahu Anda jika blebih besar dari a. Hanya saja bukan yang seharusnya Anda (programmer) minta komputer lakukan.

a) Karena program komputer lebih besar dari bukti matematika

a.1) Saya percaya bahwa ada lebih banyak orang yang digunakan selama menulis program komputer yang kompleks daripada saat menulis bukti matematika. Artinya margin kesalahan lebih tinggi.

b) Karena CEO / Pemegang Saham lebih peduli tentang uang daripada memperbaiki bug kecil , sementara itu Anda (sebagai pengembang) harus melakukan tugas Anda untuk memenuhi beberapa persyaratan / tenggat waktu / demo

c) Karena Anda bisa menjadi programmer tanpa pengetahuan "mendalam" dalam comp sci, sementara itu akan sulit dilakukan dalam matematika (saya percaya)

Selain itu:

NASA:

Perangkat lunak ini bebas bug. Itu sempurna, sesempurna yang telah dicapai manusia. Pertimbangkan statistik ini: tiga versi terakhir dari program - masing-masing sepanjang 420.000 baris - masing-masing hanya memiliki satu kesalahan. 11 versi terakhir dari perangkat lunak ini memiliki total 17 kesalahan.

Ambil pemutakhiran perangkat lunak untuk mengizinkan antar-jemput bernavigasi dengan Global Positioning Satellites, perubahan yang hanya melibatkan 1,5% dari program, atau 6.366 baris kode. Spesifikasi untuk satu perubahan itu berjalan 2.500 halaman, volume lebih tebal dari buku telepon. Spesifikasi untuk program saat ini mengisi 30 volume dan menjalankan 40.000 halaman.

https://www.fastcompany.com/28121/they-write-right-stuff

Tingkat Dasar:

Untuk matematika, kami memiliki:
2 + 3 = 5

Saya belajar tentang itu ketika saya masih sangat muda. Saya dapat melihat elemen yang paling mendasar: dua objek, dan tiga objek. Bagus.

Untuk pemrograman komputer, kebanyakan orang cenderung menggunakan bahasa tingkat tinggi. Beberapa bahasa tingkat tinggi bahkan dapat "mengkompilasi" menjadi salah satu bahasa tingkat tinggi yang lebih rendah, seperti C. C kemudian dapat diterjemahkan ke dalam bahasa Assembly. Bahasa assembly kemudian dikonversi menjadi kode mesin. Banyak orang berpikir kompleksitas berakhir di sana, tetapi tidak: CPU modern mengambil kode mesin sebagai instruksi, tetapi kemudian jalankan "kode mikro" untuk benar-benar menjalankan instruksi tersebut.

Ini berarti bahwa, pada tingkat paling dasar (berurusan dengan struktur yang paling sederhana), kita sekarang berurusan dengan kode-mikro, yang tertanam dalam perangkat keras dan yang kebanyakan programmer bahkan tidak menggunakan secara langsung, atau memperbarui. Faktanya, tidak hanya sebagian besar programmer tidak menyentuh kode mikro (0 level lebih tinggi dari kode mikro), kebanyakan programmer tidak menyentuh kode mesin (1 level lebih tinggi dari kode mikro), atau bahkan Majelis (2 level lebih tinggi dari kode mikro) ( kecuali, mungkin, untuk sedikit pelatihan formal selama kuliah). Sebagian besar programmer akan menghabiskan waktu hanya 3 level atau lebih tinggi.

Lebih jauh, jika kita melihat Majelis (yang serendah orang biasanya dapatkan), setiap langkah individu biasanya dapat dimengerti oleh orang-orang yang telah dilatih dan memiliki sumber daya untuk menafsirkan langkah itu. Dalam hal ini, Assembly jauh lebih sederhana daripada bahasa tingkat yang lebih tinggi. Namun, Majelis sangat sederhana sehingga melakukan tugas-tugas kompleks, atau bahkan tugas-tugas biasa-biasa saja, sangat membosankan. Bahasa tingkat atas membebaskan kita dari hal itu.

Dalam undang-undang tentang "rekayasa terbalik", hakim menyatakan bahwa meskipun kode secara teoritis dapat ditangani satu byte pada satu waktu, program modern melibatkan jutaan byte, sehingga beberapa jenis catatan (seperti salinan kode) harus dibuat hanya untuk upaya untuk menjadi layak. (Oleh karena itu pengembangan internal tidak dianggap sebagai pelanggaran terhadap aturan umum tentang hukum hak cipta "tidak ada salinan).) (Saya mungkin berpikir untuk membuat kartrid Sega Genesis yang tidak sah, tetapi mungkin memikirkan sesuatu yang dikatakan selama kasus Game Genie. )

Modernisasi:

Apakah Anda menjalankan kode yang dimaksudkan untuk 286s? Atau apakah Anda menjalankan kode 64-bit?

Matematika menggunakan dasar-dasar yang membentang selama ribuan tahun. Dengan komputer, orang biasanya menganggap investasi pada sesuatu yang berusia dua dekade sebagai pemborosan sumber daya yang sia-sia. Itu berarti Matematika dapat diuji jauh lebih menyeluruh.

Standar Alat Bekas:

Saya diajari (oleh seorang teman yang memiliki lebih banyak pelatihan pemrograman komputer formal daripada saya sendiri) bahwa tidak ada yang namanya kompiler C bebas bug yang memenuhi spesifikasi C. Ini karena bahasa C pada dasarnya mengasumsikan kemungkinan menggunakan memori tak terbatas untuk tujuan stack. Jelas, persyaratan yang tidak mungkin seperti itu harus disimpang dari ketika orang mencoba untuk membuat kompiler yang dapat digunakan yang bekerja dengan mesin yang sebenarnya yang sedikit lebih terbatas di alam.

Dalam prakteknya, saya telah menemukan bahwa dengan JScript di Windows Script Host, saya sudah dapat mencapai banyak objek menggunakan baik. (Saya suka lingkungan karena set alat yang diperlukan untuk mencoba kode baru dibangun ke dalam versi modern dari Microsoft Windows.) Ketika menggunakan lingkungan ini, saya menemukan bahwa kadang-kadang tidak ada dokumentasi yang mudah ditemukan tentang bagaimana objek bekerja. Namun, menggunakan objek itu sangat bermanfaat, toh saya tetap melakukannya. Jadi yang akan saya lakukan adalah menulis kode, yang mungkin buggy sebagai sarang lebah, dan melakukannya di lingkungan berpasir yang bagus di mana saya bisa melihat efeknya, dan belajar tentang perilaku objek saat berinteraksi dengannya.

Dalam kasus lain, kadang-kadang hanya setelah saya mengetahui bagaimana suatu objek berperilaku, saya telah menemukan bahwa objek (yang dibundel dengan sistem operasi) adalah buggy, dan itu adalah masalah yang diketahui yang sengaja diputuskan oleh Microsoft tidak akan diperbaiki .

Dalam skenario seperti itu, apakah saya mengandalkan OpenBSD, yang dibuat oleh programmer ahli yang membuat rilis baru sesuai jadwal, secara teratur (dua kali setahun), dengan catatan keamanan terkenal "hanya dua lubang jarak jauh" dalam 10+ tahun? (Bahkan mereka memiliki patch errata untuk masalah yang kurang parah.) Tidak, tidak berarti. Saya tidak bergantung pada produk seperti itu dengan kualitas yang lebih tinggi, karena saya bekerja untuk bisnis yang mendukung bisnis yang memasok orang dengan mesin yang menggunakan Microsoft Windows, jadi itulah yang perlu dikerjakan oleh kode saya.

Kepraktisan / kegunaan mengharuskan saya bekerja pada platform yang bermanfaat bagi orang, dan itu adalah platform yang terkenal buruk untuk keamanan (meskipun perbaikan luar biasa telah dilakukan sejak awal milenium di mana produk perusahaan yang sama jauh lebih buruk) .

Ringkasan

Ada banyak alasan mengapa pemrograman komputer lebih rentan kesalahan, dan itu diterima oleh komunitas pengguna komputer. Bahkan, sebagian besar kode ditulis dalam lingkungan yang tidak akan mentolerir upaya bebas kesalahan. (Beberapa pengecualian, seperti mengembangkan protokol keamanan, mungkin menerima upaya sedikit lebih dalam hal ini.) Selain pemikiran umum tentang alasan bisnis tidak ingin menginvestasikan lebih banyak uang, dan kehilangan tenggat waktu buatan untuk membuat pelanggan bahagia, ada dampak dari pawai teknologi yang hanya menyatakan bahwa jika Anda menghabiskan terlalu banyak waktu, Anda akan bekerja pada platform yang usang karena banyak hal berubah secara signifikan dalam satu dekade.

Begitu saja, saya ingat betapa terkejutnya betapa singkatnya beberapa fungsi yang sangat berguna dan populer, ketika saya melihat beberapa kode sumber untuk strlen dan strcpy. Sebagai contoh, strlen mungkin sesuatu seperti "int strlen (char * x) {char y = x; while ( (y ++)); return (yx) -1;}"

Namun, program komputer pada umumnya jauh lebih panjang dari itu. Juga, banyak pemrograman modern akan menggunakan kode lain yang mungkin kurang diuji secara menyeluruh, atau bahkan diketahui buggy. Sistem saat ini jauh lebih rumit daripada apa yang dapat dengan mudah dipikirkan, kecuali dengan tangan melambaikan banyak hal kecil sebagai "perincian yang ditangani oleh tingkat yang lebih rendah".

Kompleksitas wajib ini, dan kepastian bekerja dengan sistem yang kompleks dan bahkan salah, membuat pemrograman komputer banyak perangkat keras untuk diverifikasi daripada banyak matematika di mana hal-hal cenderung mendidih ke tingkat yang jauh lebih sederhana.

Ketika Anda memecah hal-hal dalam matematika, Anda mendapatkan potongan-potongan individual yang anak-anak dapat mengerti. Kebanyakan orang mempercayai matematika; setidaknya aritmatika dasar (atau, setidaknya, penghitungan).

Ketika Anda benar-benar memecah pemrograman komputer untuk melihat apa yang terjadi di bawah tenda, Anda berakhir dengan implementasi yang rusak dari standar dan kode yang rusak yang pada akhirnya dieksekusi secara elektronik, dan bahwa implementasi fisik hanya satu langkah di bawah mikrokode yang kebanyakan ilmuwan komputer yang dilatih universitas tidak tidak berani menyentuh (jika mereka menyadarinya).

Saya sudah bicara dengan beberapa programmer yang masih kuliah atau lulusan baru yang langsung keberatan dengan anggapan bahwa kode bebas bug dapat ditulis. Mereka telah menghapus kemungkinan itu, dan meskipun mereka mengakui bahwa beberapa contoh yang mengesankan (yang saya dapat tunjukkan) adalah beberapa argumen yang meyakinkan, mereka menganggap sampel seperti itu sebagai cacing langka yang tidak representatif, dan masih menolak kemungkinan untuk dapat menghitung memiliki standar yang lebih tinggi. (Sikap yang jauh, jauh berbeda dari fondasi yang jauh lebih dapat dipercaya yang kita lihat dalam matematika.)

Bukti matematika menggambarkan "apa" pengetahuan dan program menggambarkan "bagaimana" pengetahuan ".

Menulis program lebih kompleks karena programmer harus mempertimbangkan semua keadaan berbeda yang dapat muncul, dan bagaimana perilaku program berubah sebagai hasilnya. Bukti menggunakan penalaran formulaik atau kategoris untuk membuktikan hal-hal tentang definisi lain.

Sebagian besar bug disebabkan oleh proses masuk ke negara-negara yang tidak diantisipasi oleh programmer. Dalam sebuah program Anda biasanya memiliki ribuan atau, dalam sistem besar, jutaan variabel yang mungkin bukan data statis, tetapi sebenarnya mengubah cara program dijalankan. Semua interaksi ini menciptakan perilaku yang tidak mungkin diantisipasi, terutama di komputer modern di mana ada lapisan abstraksi yang berubah di bawah Anda.

Dalam buktinya, tidak ada perubahan kondisi. Definisi dan objek diskusi telah diperbaiki. Membuktikan memang membutuhkan pemikiran tentang masalah secara umum dan mempertimbangkan banyak kasus, tetapi kasus-kasus itu diperbaiki oleh definisi.