Greenspun'un Onuncu Kuralı, her büyük projede bir Lisp tercümanı var mı? [kapalı]

Greenspun'un onuncu kuralı (aslında tek kural):

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

Hafızam, belki de Borland'ın Quattro (elektronik tablo) projesi ve muhtemelen diğerleri için konuyla ilgili bazı makaleler olduğu. Google yararsızdır, belki de doğru arama terimleri akla gelmez. Varsa, bu iddiayı destekleyen makaleler veya makaleler arıyorum.

İfade abartmadır. Ancak Lisp kıskançlığının diğer dillerde bariz işaretleri var. C # 'a ve doğada nasıl daha işlevsel hale geldiğine bakın. Programı değiştirmeden sistemi programlamayı mümkün kılmak için kendi yolundan çıkan çeşitli İş Süreçleri Yönetimi, iş akışı ve EAI çerçevelerine bakın.

Martin Fowler'ın Etki Alanına Özel Diller hakkında, Nesneye Dayalı dillerde meta programlama yapmayı anlatan bir kitap var. Yani abartı için bazı gerçekler var.

Paul Graham Lisp'i Lisp ile gelen ilkler listesine bakarak en güçlü dil olarak adlandırdı , neden birçok dilin neden soluk olduğunu görmek kolay.

Onuncu kuralın yolu poliglot programlamadır. Bir dilin / çerçevenin altın çekiç olmadığını fark etmek. Ardından, Lisp'in kötü ve geçici bir uygulamasını oluşturmak yerine, Lisp'i kullanabilirsiniz.

Greenspun'un "onuncu kuralı" kelepçeli bir tuzak parçasıydı. Yeterince uzandığında, "herhangi bir komut dosyası veya yapılandırma sistemini" kapsıyorsanız, açıkçası bu sorunun cevabı "evet" olmalıdır, çünkü yapılandırma önemsiz olmayan bir programın bir dereceye kadar gerektirdiği bir şeydir ve komut dosyası karmaşıklık ölçeğini yükselttikçe yalnızca biraz daha az yaygındır.

Öte yandan, bir göz AMAÇ , bir Lisp varyant oyun programlama için Yaramaz Köpek tarafından icat etti. Hiç "klasik" Lisp gibi görünmüyor. Nesneye yönelik işlevsellik, yorumlayıcı yok, çöp toplama için asgari destek (bunun yerine çalışma zamanı düzeyinde temizleme olanaklarına güvenen) ve satır içi montaj için kapsamlı destek ile son derece zorunlu bir sistem.

Başka bir deyişle, Lisp'i yeterince karmaşık bir proje için kullanmaya çalıştıklarında, yararlı bir şey yapmak için dili C ++ 'ın yarısının ad-hoc, gayri resmi olarak belirtilen bir uygulamasına dönüştürmek zorunda olduklarını keşfettiler! ;) (Ve sonunda GOAL'i tasarlayan adamdan sonra kullanmayı bırakmak zorunda kaldılar, çünkü kimse kodunu anlayamadı.)

İlginçtir ki, bu sorunun bir cevabı zaten Programcılar SE'de .

İlgili kısmı belirtmek için:

Greenspun'un amacı (kısmen) birçok karmaşık programın dahili tercümanlara sahip olmasıdır. Bir tercümanı bir dile inşa etmek yerine, zaten bir tercüman (veya derleyici) bulunan Lisp gibi bir dil kullanmanın daha anlamlı olabileceğini önerdi.

O zamanlar, özel bir dil için özel bir yorumlayıcı kullanarak kullanıcı tanımlı hesaplamalar yapan oldukça büyük bir uygulama üzerinde çalışıyordum. Lisp'teki çekirdeğini büyük ölçekli bir deney olarak yeniden yazmaya karar verdim.

Yaklaşık altı hafta sürdü. Orijinal kod yaklaşık 100.000 satırlık Delphi (Pascal varyantı) idi. Lisp'te bu ~ 10.000 satıra indirildi. Yine de daha şaşırtıcı olanı, Lisp motorunun 3-6 kat daha hızlı olmasıydı. Ve bunun bir Lisp neofitinin işi olduğunu unutmayın! Tüm bu deneyim benim için göz açıcıydı; ilk kez performans ve ifadeyi tek bir dilde birleştirme olanağını gördüm.
- Michael Lenaghan

Bu bölümü daha da netleştirmek için Michael bir yoruma şu yanıtı verdi:

Vay be, bir şekilde bir Lisp uygulamasından 3-6 kat daha yavaş çalışmayı başarırsa, bu gerçekten korkunç bir Delphi kodu olmalı! "Doğru, bunu daha iyi açıklayamadığım için başarısızlığım olarak sayacağım. Kullanıcı ifadelerini son derece kolay bir süreç olan Lisp ifadelerine dönüştürün ve ardından Lisp ifadelerini yerel koda derleyin (tam optimizasyon ile) Bu Greenspun'un Onuncu Kuralının
anlamıdır . - Michael Lenaghan

Bu cevabın başka bir kişinin cevabından oluştuğu düşünüldüğünde, topluluk wiki'sidir.

Kural bir şaka, ama içinde biraz gerçek var. Herhangi bir karmaşık sistem bir dizi yorumlanmış kısım içerecektir (bakınız, "Tercüman paterni" tüm bu mumbo-jumbo paternlerine inananlar arasında nasıl popülerdir). Herhangi bir karmaşık sistem, genellikle yapılandırılmış, sıklıkla yorumlanmış bazı yapılandırma araçları sağlamalıdır.

Herhangi bir karmaşık sistemin, oluşturma sürecinde birkaç kod oluşturma geçişine ve çeşitli özelleştirilmiş ön işlemcilere sahip olması muhtemeldir ( mocQt veya tablegenLLVM'deki şeyleri düşünün ).

Birçok sistem, karmaşık ağaç benzeri veri yapılarını, (neredeyse her zaman) kötü tasarlanmış ağaç yürüyüş ve dönüştürme araçlarını kullanarak Common Lisp'in kütüphane işlevselliğine yakından benzeyen hokkabazlık yapıyor.

Tüm bunlar Lisp ile ücretsiz olarak gelir ve çoğu durumda, yeterince kapsamlı uygulamalarla düşünülmeyen geçici, plansız, tamamen düşük olacaktır.

Yeterince karmaşık olan herhangi bir sistem, içinde çalıştığınız dilin soyutlamaları ile ifade edilmesi son derece zor olan alana özgü kavramlara ve gereksinimlere sahip olacaktır. Bu, programcıları, programlama dili arasındaki anlamsal boşluğu köprüleme yükünü hafifletmek için yanlışlıkla alan adına özgü soyutlamalar yaratmaya zorlar. ve belirli bir alan adı. Bu soyutlamalar yeterli olduğunda, temel olarak alana özgü bir dil için bir tercümanınız olur. Bu, yazılım geliştirmenin kaçınılmaz bir parçasıdır.

"Dinamik davranışı uygulamak için her büyük yazılım tabanlı sistem gerekeceği" için kural muhtemelen daha doğru (ve daha az eğlenceli) olabilir.

Bu iki şekilde yapılabilir-

1. Düzinelerce parametre ve yüzlerce tanım içeren büyük ve karmaşık bir yapılandırma dosyası.

2. AD-HOC komut dosyası dili.

"sendmail" muhtemelen "1" türünün standart örneğidir. Ben bir "gerçek" komut dosyası dili la la Warcraft / LUA veya hatta Netscape / Javascript gömme içermeyen iyi bir "2" örnekleri düşünemiyorum.

Sorun birkaç parametre için hızlı ve basit bir yapılandırma dosyası ile yapmaktır, ancak bu çözüm gerçekten ölçeklendirilmez. Bununla birlikte, yapılandırma dosyasına bir veya iki seçenek eklerken yapılandırma dosyasını bir komut dosyası yaklaşımı lehine dökmek ekonomik olmayacaktır. Böylece yapılandırma dosyasını yorumlayan kod gerçekten kötü yazılmış bir yorumlayıcı olur.

Bu, diğerlerinin de belirttiği gibi, birçok program yapılandırılabilirlik gerektirir ve bu nedenle çeşitli lisp benzeri tercümanlar içerir.

Ancak ifade, bir program yapmak için ihtiyacınız olan her şeyin Lisp olduğunu ve diğer tüm dillerin bu programlardan daha düşük olduğunu ifade eder.

Ama yanlış, Lisp etkileyici olabilir, ama aynı zamanda çok soyut, bir platformun ayrıntılarını gizlemeye ve bilgisayar dünyasında listeler dışında hiçbir şey taklit etmeye çalışmaz.

Yüksek performanslı programlamanın gerçekliği, bazen bitler ve baytlarla karışmamız ve işletim sistemine özgü şeyler yapmamız gerektiğidir, bu nedenle ifadenin ima ettiği gibi her şeyi sadece Lisp ile yapmak mümkün değildir.

Oldukça farklı bir yöntemdir, icat ettiğiniz bir dilin ne kadar karmaşık, zeki veya sofistike olursa olsun, sonuçta sadece montaj yazmanın başka bir yoludur.

Ciddiye alınması gerekip gerekmediği, üzerinde çalıştığım en büyük C ve C ++ projeleri için geçerlidir.

Doğru olmayan, özel komut dosyası dillerinin Ortak Lisp'e benzemesi. Olumlu örnekler Scheme'e benziyor (çünkü daha akıllı tasarımcılar kendi dillerini icat etmek yerine Guile, SpiderMonkey ve Lua'yı entegre ettiler.) DailyWTF'ye en uygun örnekler, Forth benzeri bir dil ve MUMPS benzeri bir dildi.

Başka bir örnek (Greenspunning, ancak kesinlikle bir WTF olarak sayıldığından emin değilim), genel amaçlı komut dosyası oluşturma için kullanılan bir XSLT yorumlayıcıydı. Çıktının ikinci kez XSLT tarafından dönüştürüleceği bir geri bildirim döngüsü eklediklerinden, bu Lisp gibiydi - şimdi makrolarınız etkili bir şekilde var.
Buradaki neden, lispy özelliklerine erişmek değil, şirketin kod KG prosedürlerini ortadan kaldırmaktı (her hata düzeltmesine 3 hafta gecikme ekledi. XML "veri" olarak kabul edildi ve işlemden muaf tutuldu).

Ne yazık ki değil!

Sadece gerçek bir lisp (y) tercümanı (javascript veya lua alos) gömmek en iyisi olsa da, bir projeye homebrew 4gl eklemek esnekliği arttırırken genel boyutu azaltır.

"Her şeyi kodlayan" projeler çok daha büyük modül sayısına sahiptir ve hantal ve esnek değildir.