Günümüzde ortak lisp eleştirilerinden hangisi hala geçerli?

In Common Lisp A Eleştirisi 1984 yılında Rodney A. Brooks ve Stanford Richard P. Gabriel tarafından yazılan, Common Lisp normallestirici komitesi tarafından tutulan bazı tasarım kararları tartışılmaktadır. Tartışmanın çoğu geçerli olmakla birlikte, şu anda mevcut olan teknolojiye atıfta bulunan ve bugün yanlış olan iki ifade vardır.

Bu iki ifade:

Herhangi bir iyi derleyicinin kendileriyle ilgilenebileceği iddiasıyla dilin çok fazla maliyeti giderildi. Henüz hiç kimse yazmadı - muazzam bir çaba göstermeden büyük olasılıkla - ondan beklenen hilelerin bir kısmını yapan bir derleyici.

Common Lisp acemi veya çırak olduğum için, yazarlardan daha spesifik olamıyorum. İyi bir derleyici yazmayı oldukça zorlaştıran, dilin çeşitli yönlerine büyük bir genellik ve esneklik getirildiğini söylüyorlar.

ORTAK LİSP'te kayan nokta aritmetiği üzerinde çok fazla kontrol yapıldı. Ve kesinlikle, kayan nokta yoğun bir programın doğru davranışı elde edilebilse de, performans çılgınca değişebilir.

Anladığım kadarıyla Common Lisp'te verimli bir sayısal kod yazmanın mümkün, ancak olması gerekenden daha zorlu olduğu görülüyor.

Bu otuz yıl önceydi. Yaygın ücretsiz yazılım uygulamalarından biri için Ortak Lisp programları yazmaya istekliysem, bugün bu ifadeyi nasıl dikkate almalıyım (CLISP, SBCL ve ark.)?

Kağıt birçok yönden ilginç.

En ilginç kısım şudur: yazarlar makaleyi 1984'ten 1986'da iki yıl sonra kendileri tahrif etmişlerdir. Brooks ve Gabriel son derece optimize bir Lisp derleyicisi geliştirdi ve birkaç yıl boyunca ticari olarak çok başarılı sattı: Lucid Common Lisp (PDF).

Bu Lisp derleyicisinin bakımı LispWorks'te hala mevcuttur : şimdi Sıvı Ortak Lisp olarak adlandırılmaktadır .

Liquid CL'nin derleyici optimizasyonları, Gelişmiş Kullanım Kılavuzunun 3. Bölümünde belgelenmiştir : Lisp Programlarını Optimize Etme .

Lucid CL’de çeşitli ticari uygulamalar yazıldı ve konuşlandırıldı. Örneğin memleketimde HVV (Hamburger Verkehrsverbund) için ilk toplu taşıma bilgi sistemi, SUN SPARCstation'da Lucid CL kullanılarak konuşlandırıldı. Halk için geniş bir dokunmatik ekran kullanan ve çağrı merkezindeki tren istasyonlarında mevcuttu.

Lucid CL başarılıydı çünkü üretim modu derleyicisi, çoğunlukla Unix / RISC platformları için hızlı Common Lisp uygulamaları yarattı.

Brooks ve Gabriel 1986'da Lucid Common Lisp hakkında yazıyor:

Dinamik olarak geciktirilebilir derleyicinin, çeşitli Lisp uygulamaları için derleme kolaylığının gerçekleştirilebileceği bir araç olduğu gösterilmiştir; Lisp sistemlerinin çeşitli bilgisayarlara taşınması için bir araç; ve ortak bir kaynaktan çeşitli bilgisayarlar için yüksek kaliteli, yüksek performanslı kod üretmek için bir araç.

Böylece , Common Lisp A Eleştirisi'nin zor veya imkansız olduğunu iddia ettiği şeyi yeni uyguladılar .

Günümüzde daha gelişmiş uygulamalar çok fazla optimizasyon yapıyor, ancak donanım 1984'tekinden 1000 + kat daha hızlı. Bir VAX 11/780'de bir MIPS (saniyede milyon talimat) vardı ve bir Lisp Makinesi de bu aralık. Bir Motorola 68000'de 8 MHz saat hızı vardı.

Kayan nokta performansı ve genel olarak değişen performans eleştirisi hala geçerlidir, ancak bu uygulayıcıların seçimini yansıtmaktadır. Bazı uygulamalar yüksek performanslı derleyiciler olarak geliştirilmemiştir. Ana odağı taşınabilirlik, kompaktlık veya başka bir şey olabilir ve bu nedenle farklı uygulama hedefleri olabilir.

Bir kullanıcı / geliştirici olarak taşınabilir kod yazmak ve şu anda desteklenen on + Common Common ortak sistemlerin tümünü kullanmak zorunda değildir . Uygulama problemine en uygun uygulamayı kullanın.

Bu yazı 1984 yılında yazıldığında, masanızda oturabilen 1 megabayt RAM ve 20 megabayt sabit disk içeren bir bilgisayar çok önemliydi. Doğal olarak, anlaşmazlıklar Lisp'in spartan olduğu donanım konusunda olduğu gibi bir dilin pratikliği konusunda ortaya çıkacaktır. O zamandan beri gerçekleşen hem donanım hem de derleyici teknolojisindeki gelişmeler Lisp programlarının, dilde olabilecek sayısal yetersizliklere bakmaksızın yazmayı ve yürütmeyi çok daha kolaylaştırmıştır.

Programcılar genellikle programlama verimliliği için hesaplamalı verimlilik sağlarlar. Lisp, yavaş bir dil olabilir (bazı uygulamalarda, ancak diğer dillerde de olabilir), ancak hızlı gelişim için haklı bir üne sahiptir ve birçok program yeterli performans göstermesi için yüksek düzeyde optimize edilmiş bir altyapı gerektirmez.

Lisp uygulamasının seçimi, programlarınızın performans profilini büyük ölçüde etkileyebilir. Örneğin, CLISP, "Kodunuz çok sayısalsa, CMUCL'yi tercih edebilirsiniz." Bazı modern Lisp (ve Scheme) uygulamaları, sayısal performansı artıracak sayısal tip ipuçlarını belirlemenizi sağlar.

Kısacası, durum bugün olduğundan daha iyi.