Aturan Kesepuluh Greenspun, apakah setiap proyek besar menyertakan juru bahasa Lisp? [Tutup]

Aturan kesepuluh Greenspun (sebenarnya satu-satunya aturan) menyatakan bahwa:

Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.

Ingatan saya adalah bahwa ada beberapa makalah tentang topik ini, mungkin untuk proyek Quattro (spreadsheet) Borland dan mungkin yang lain. Google tidak membantu, mungkin istilah pencarian yang tepat tidak terpikirkan. Saya mencari makalah atau artikel yang mendukung klaim ini, jika ada.

Pernyataan itu hiperbola. Tapi ada tanda-tanda iri Lisp yang jelas dalam bahasa lain. Lihatlah C # dan bagaimana itu menjadi lebih fungsional di alam. Lihatlah berbagai Manajemen Proses Bisnis, alur kerja, dan kerangka kerja EAI yang berupaya agar memungkinkan untuk memprogram sistem tanpa mengubah program.

Ada sebuah buku tentang Bahasa Tertentu Domain oleh Martin Fowler yang berbicara tentang bagaimana melakukan pemrograman meta dalam bahasa yang Berorientasi Objek. Jadi ada beberapa kebenaran pada hiperbola.

Paul Graham menyebut Lisp sebagai bahasa yang paling kuat melihat daftar yang pertama dengan Lisp , mudah untuk melihat mengapa banyak bahasa pucat dibandingkan.

Cara sekitar aturan kesepuluh adalah pemrograman polyglot. Menyadari bahwa satu bahasa / kerangka kerja bukanlah palu emas. Kemudian alih-alih membuat Lisp yang buruk, implementasi ad hoc, Anda bisa menggunakan Lisp.

"Aturan kesepuluh" Greenspun adalah sedikit omong kosong. Ketika direntangkan cukup jauh, jika Anda membuatnya mencakup "skrip apa pun atau sistem konfigurasi," maka jelas jawaban untuk pertanyaan ini harus "ya," karena konfigurasi adalah sesuatu yang diperlukan oleh program non-sepele dalam tingkat tertentu, dan skrip hanya sedikit kurang umum saat Anda naik skala kompleksitas.

Di sisi lain, lihat GOAL , varian Lisp yang diciptakan oleh Naughty Dog untuk pemrograman game. Sama sekali tidak mirip Lisp "klasik". Ini adalah sistem bergaya sangat imperatif, dengan fungsi berorientasi objek, tidak ada juru bahasa, dukungan minimal untuk pengumpulan sampah (sebagai gantinya mengandalkan fasilitas pembersihan tingkat runtime), dan dukungan luas untuk perakitan inline.

Dengan kata lain, ketika mereka mencoba menggunakan Lisp untuk proyek yang cukup kompleks, mereka menemukan bahwa untuk melakukan sesuatu yang bermanfaat mereka harus mengubah bahasa menjadi implementasi ad-hoc, setengah dari C ++ yang diinformasikan secara informal! ;) (Dan mereka akhirnya harus berhenti menggunakannya setelah orang yang mendesain GOAL pergi, karena tidak ada yang bisa memahami kodenya.)

Anehnya, satu jawaban untuk pertanyaan ini sudah ada di Programmer SE .

Mengutip bagian yang relevan:

Poin Greenspun adalah (sebagian) bahwa banyak program kompleks memiliki penafsir bawaan. Daripada membangun penerjemah menjadi bahasa yang ia sarankan, mungkin lebih masuk akal untuk menggunakan bahasa seperti Lisp yang sudah memiliki interpreter (atau kompiler) bawaan.

Pada saat itu saya sedang mengerjakan aplikasi yang agak besar yang melakukan perhitungan yang ditentukan pengguna menggunakan penerjemah khusus untuk bahasa khusus. Saya memutuskan untuk mencoba menulis kembali intinya di Lisp sebagai percobaan skala besar.

Butuh sekitar enam minggu. Kode asli adalah ~ 100.000 baris Delphi (varian Pascal). Di Lisp yang dikurangi menjadi ~ 10.000 baris. Yang lebih mengejutkan adalah fakta bahwa mesin Lisp 3-6 kali lebih cepat. Dan perlu diingat bahwa ini adalah karya orang baru Lisp! Seluruh pengalaman itu cukup membuka mata saya; untuk pertama kalinya saya melihat kemungkinan menggabungkan kinerja dan ekspresif dalam satu bahasa.
- Michael Lenaghan

Untuk lebih memperjelas bagian itu, Michael menanggapi komentar dengan:

Wow, itu pasti kode Delphi yang benar-benar mengerikan jika entah bagaimana berhasil melakukan 3-6x lebih lambat daripada implementasi Lisp! "Benar, saya akan menghitung bahwa sebagai kegagalan saya karena tidak menjelaskannya dengan lebih baik. Implementasi Lisp mampu mengubah ekspresi pengguna ke dalam ekspresi Lisp - proses yang sangat mudah - dan kemudian kompilasi ekspresi Lisp ke kode asli (dengan optimisasi penuh). Itulah arti dari Aturan Kesepuluh Greenspun.
- Michael Lenaghan

Mengingat jawaban ini terdiri dari jawaban orang lain di tempat lain, itu adalah komunitas wiki.

Aturannya adalah sebuah lelucon, tetapi ada sedikit kebenaran di dalamnya. Setiap sistem yang kompleks akan berisi sejumlah bagian yang ditafsirkan (lihat, bagaimana "pola Interpreter" populer di antara mereka yang percaya pada semua pola yang mumbo-jumbo). Setiap sistem yang kompleks harus menyediakan beberapa cara konfigurasi, sering terstruktur, sering ditafsirkan.

Setiap sistem yang kompleks sangat mungkin memiliki beberapa pass generasi pembuatan kode dan berbagai preprosesor yang disesuaikan dalam proses pembuatannya (pikirkan hal-hal seperti mocdi Qt atau tablegendi LLVM).

Banyak sistem menyulap struktur data seperti pohon yang kompleks menggunakan seperangkat alat berjalan pohon yang hampir tidak dirancang dengan baik dan mentransformasikannya sangat mirip dengan fungsi perpustakaan dari Common Lisp.

Semua hal ini datang secara gratis dengan Lisp, dan dalam kebanyakan kasus semua itu ad hoc, tidak terencana, tidak dipikirkan secara menyeluruh implementasi yang cukup akan jauh lebih rendah.

Setiap sistem yang cukup kompleks akan memiliki konsep dan persyaratan khusus domain yang sangat sulit untuk diekspresikan dengan abstraksi bahasa tempat Anda bekerja. Ini secara tidak sengaja memaksa programmer untuk membuat abstraksi spesifik domain untuk memudahkan beban menjembatani kesenjangan semantik antara bahasa pemrograman dan domain spesifik. Setelah ada cukup banyak abstraksi ini, pada dasarnya Anda memiliki juru bahasa dari bahasa tertentu. Ini adalah bagian yang tidak dapat dihindari dari pengembangan perangkat lunak.

Aturannya mungkin bisa lebih akurat (dan tidak terlalu lucu) karena "setiap sistem berbasis perangkat lunak besar akan diperlukan untuk menerapkan perilaku dinamis".

Ini dapat dilakukan dengan dua cara-

1. File konfigurasi kompleks yang besar dengan puluhan parameter dan ratusan definisi.

2. Bahasa skrip AD-HOC.

"sendmail" mungkin adalah contoh kanonik dari tipe "1". Saya tidak bisa memikirkan contoh bagus dari tipe "2" yang tidak melibatkan embedding bahasa scripting "nyata" ala Warcraft / LUA atau bahkan Netscape / Javascript.

Masalahnya adalah untuk beberapa parameter yang cepat dan sederhana untuk melakukannya dengan file konfigurasi, tetapi, solusi ini tidak benar-benar berskala. Namun tidak akan ekonomis untuk membuang file config yang mendukung pendekatan skrip ketika menambahkan satu atau dua opsi ke file config. Jadi kode yang menginterpretasikan file konfigurasi akhirnya menjadi penerjemah yang benar-benar buruk.

Itu mungkin benar, seperti yang lain, banyak program memerlukan konfigurasi dan juga mengandung berbagai penerjemah mirip-lisp.

Namun pernyataan itu juga menyiratkan dengan menyeringai bahwa semua yang Anda butuhkan untuk membuat sebuah program adalah Lisp, dan bahwa semua bahasa lain lebih rendah daripada itu.

Tapi itu salah, Lisp mungkin ekspresif, tetapi juga terlalu abstrak, ia mencoba untuk menyembunyikan detail platform dan berpura-pura tidak ada tetapi daftar ada di dunia komputer.

Kenyataan pemrograman kinerja tinggi, adalah bahwa kadang-kadang kita perlu berbaur dengan bit dan byte, dan melakukan hal-hal spesifik OS, sehingga tidak mungkin untuk melakukan segalanya hanya dengan Lisp seperti yang diimplikasikan oleh pernyataan.

Ini agak sebaliknya, tidak peduli seberapa rumit, pintar atau canggih dari bahasa yang Anda ciptakan, semua itu akhirnya hanyalah cara lain untuk menulis majelis.

Apakah itu dianggap serius atau tidak, itu benar untuk proyek C dan C ++ terbesar yang pernah saya kerjakan.

Apa yang tidak benar adalah bahwa bahasa skrip kustom menyerupai Common Lisp. Contoh-contoh positif menyerupai Skema (karena desainer yang lebih cerdas mengintegrasikan Guile, SpiderMonkey dan Lua alih-alih menciptakan bahasa mereka sendiri.) Contoh yang paling layak DailyWTF adalah bahasa seperti Forth dan bahasa mirip MUMPS.

Contoh lain (tidak yakin apakah itu dianggap sebagai Greenspunning, tapi tentu saja WTF) adalah juru bahasa XSLT yang digunakan untuk skrip tujuan umum. Ini lebih mirip Lisp karena mereka menambahkan loop umpan balik di mana output akan diubah-XSLT untuk kedua kalinya - jadi sekarang Anda secara efektif memiliki makro.
Motif di sini adalah bukan untuk mendapatkan akses ke fitur lispy tetapi untuk menghindari prosedur QA kode perusahaan (yang menambahkan 3 minggu latensi untuk setiap perbaikan bug. XML dianggap sebagai "data" dan dibebaskan dari proses.)

Sayangnya tidak!

Sementara yang terbaik hanya menanamkan penerjemah nyata (y) lisp (javascript atau lua alos melakukan pekerjaan yang baik), menambahkan 4gl homebrew ke proyek mengurangi ukuran keseluruhan sambil meningkatkan fleksibilitas.

Proyek yang "kode semuanya" memiliki jumlah modul yang jauh lebih besar dan menjadi sulit dan tidak fleksibel.