Lisp neden daha yaygın değil? [kapalı]

SICP videolarından Scheme öğrenmeye başladım ve daha sonra Common Lisp'e geçmek istiyorum.

Dil çok ilginç görünüyor ve birçok insan onun üzerine kitap yazıyor, onun eşsiz ifade gücüne sahip olduğunu savunuyor. CL'nin iyi bir standart kütüphanesi var.

Lisp neden daha yaygın değil? Gerçekten bu kadar güçlüyse, insanlar her şeyi kullanıyor olmalı, ancak bunun yerine Lisp iş ilanlarını bulmak neredeyse imkansız.

Umarım bu sadece parantez değildir, çünkü bir süre sonra büyük bir problem değildir.

Etkileyicilik, kurumsal bir ortamda her zaman olumlu bir dil özelliği değildir . Java kısmen popüler, çünkü öğrenmesi kolay, yazması kolay ve okunması kolay. Vasat programcılar Java kodlarında hala çok tereddütlü ve inelegant olsa bile çok üretken olabilirler.

Ayrıca, ifade edici dilleri kötüye kullanmak kolaydır. Uzman bir java programcısı hızlıca kötü yazılmış kodları yeniden düzenleyebilir. Dil ne kadar etkileyici olursa, korkunç kodlar o kadar anlayışlı ve zorlayıcı hale gelir. LISP makroları iyi bir örnektir. Makrolar doğru ellerde güçlü araçlardır. Yanlış ellerde, kafa karıştırıcı ve zor hata ayıklama koduyla sonuçlanabilir.

LISP üst yönetim için riskli bir seçimdir . İşler ters giderse, hiç kimse Oracle veya Microsoft gibi büyük bir şirket tarafından desteklenen popüler bir nesne yönelimli dil seçmek için yönetimi suçlamayacak. Popüler, öğrenmesi kolay dilde tecrübesi olan programcıları işe almak çok daha kolaydır.

Daha güçlü bir dil kullanmak isteyen ilerici şirketler bile genellikle LISP'yi seçmez. Bunun nedeni, yeni dillerin çoğunun, LISP'den güçlü özellikleri ödünç alırken, kitleler için öğrenmesi kolay kalmaya çalışıp taviz vermesidir. Scala ve Ruby bu modeli takip ediyor. Kötü programcılar onları hızlı bir şekilde alabilir ve Java’da yaptıkları aynı vasat kodu yazmaya devam edebilir. İyi programcılar, güzel kodlar yazmak için daha gelişmiş özelliklerden faydalanabilir.

Parantez sorun değil. Haskell, Python veya Ruby'ye benzeyen bir sözdizimine sahip, inanılmaz derecede güçlü ve etkileyici bir dildir ve LISP ile aynı nedenlerin çoğu için yaygın olarak benimsenmemiştir.

Bütün bunlara rağmen, umuyorum ki ...

Clojure popüler olma şansına sahip. JVM üzerinde çalışır, Java ile mükemmel bir etkileşime sahiptir ve aynı anda programlamayı çok daha basit hale getirir. Bunların hepsi birçok şirket için önemli şeylerdir.

* Bu benim bakış açım, Java, Clojure, JRuby ve Scala'da tecrübeli profesyonel bir JVM programcısı olarak.

Lisp neden daha yaygın değil? Eğer gerçekten o kadar güçlüyse, insanlar her şeyi kullanıyor olmalı.

Dillerin teknik özellikleri için seçildiğini düşünüyorsanız, ruh kırıcı bir hayal kırıklığı yaşarsınız.

Bu kararlar Striptizci ve Biftek'e dayanarak verilir . Microsoft onları karşılayabilir. Oracle yapabilir. Sun Java’yı iflasa uğratmak için çok para harcadı. İki defa. Merkezi olmayan, heterojen, gönüllü bir topluluk bununla rekabet edemez.

ancak bunun yerine Lisp iş ilanlarını bulmak neredeyse imkansız.

Yeterince komik, Lisp şirketleri tam tersi diyorlar: sürekli iş ilanları var ama onları dolduracak kadar insan bulamıyorlar. (Aynısı Haskell, ML, O'Caml, Forth, Smalltalk, ... için de geçerlidir)

Gerçek bir şirkette çalışma konusunda hiçbir tecrübem yok, ancak LISP'nin neden benim için kullanımı zor olduğunu biliyorum.

Her şeyden önce, bu bana bu blog yazısını hatırlatıyor: http://steve-yegge.blogspot.com/2006/04/lisp-is-not-acceptable-lisp.html

Lisp ile olan temel sorun "hangi Lisp" sorusudur. Genellikle Linux üzerinde ana platformum olarak çalışırım, ancak yaptığım şeylerin Windows ile uyumlu olması gerekiyor. Bu, kullanacağım bir teknolojiyi değerlendirdiğimde, iki farklı işletim sistemi üzerinde çalışırken hayatımı kolaylaştırmam gerektiği anlamına geliyor. Bu şarttan hoşlanmıyorum, ancak şart olan gerçek bir projede kullanmak. Şimdi kendi kişisel yan projelerim için Windows'ta çok iyi bir desteği olmayan dilleri kullanacağım, ancak bunlara büyük bir yazılım projesi yazma şansım olmadığından, gerekli deneyime sahip değilim.

Şimdi işlevsel bir dil öğrenmeye çalışırken, gerçekten Common Lisp'i öğrenmek istedim. Yapılacak doğru şey gibi görünüyordu. Dahili Common Lisp'i bir başlangıç ​​noktası olarak okumaya başladım, çünkü yerleşik fonksiyonları gerçekten bilmiyordum ve üzerinde çalışmak için bir projeye ihtiyacım vardı. S ifadeleri güzel ve kolaydı. Bütün bu parantez, benim için inanılmaz derecede güzeldi, çünkü kodda olanların tam olarak ne olduğu gündü.

Bu yüzden ilk programımı Lisp'te kitabın dışına yazmaya çalışıyorum. Kod satırından sayılan ve önemsiz satırları kod sayısından kaldıran bir komut satırı aracı istedim. En kullanışlı araç değil, ama eğlenceli. Dosya erişimi, biraz ayrıştırma ve sayma içerir. Aynı aracı Python'da yaklaşık bir hafta önce uygulamıştım.

Komut satırı argümanlarına erişmem gerekiyor. Sonra komut satırı argümanlarını almanın standart bir yolu olmadığını öğrendim. Hepsi standart olmayan özelliklerdir. Hiç platformlar arası değil. Dilin içinde çok fazla kütüphane bulunmadığı için oradan daha da kötüye gidiyor. Haskell'e geçtim ve Common Lisp'e fazla yaklaşmadım (bu yüzden şikayetlerim geçerli olmayabilir).

Bu tür standart dışı bir şey geçmişte benim için her zaman bir acı olmuştur. C ++ da aynı sorunu yaşıyor, ancak Boost gibi kütüphanelerle bu zayıf yönlerin üstesinden gelebilirsiniz.

Ayrıca, Lisp sözdiziminin S ifadeleri dışındaki her şey için biraz çirkin olmasına yardımcı olmuyor.

IMO, bunun nedeni çoğunlukla:

• Zavallı kütüphane desteği. Tabii ki, artık Quicklisp var, bu da kütüphanelerin kurulmasını kolaylaştırıyor, fakat onların hala oldukça az olmalarını telafi etmiyor ve bunların bir kaçı yeterince belgelenmemiş veya iyi bakılmıyor. Python'a kıyasla, önemsiz olmayan Lisp başvurusu yazmanın (belirli lehçeye bakılmaksızın) muhtemelen en azından bir veya iki tekerleğin bir kısmını yeniden icat etmeyi içerme olasılığı yüksektir.
• Geliştirme araçları tarafından benimsenen model ile aşinalık eksikliği. Tanıdığım insanların çoğu, Eclipse ve Visual Studio'da kullanılan insanlar için anlaşılabilir olan SLIME ve Emacs'ı kullanmak zorunda kaldıklarından oldukça korkuyorlar. İki Eclipse eklentisi var sanırım, onlardan sadece birkaç yıl önce denedim ve oldukça hatalıydı. Lisp ekosisteminin tamamı, tam teşekküllü Lisp çalışan bir sistemin bir parçası olduğu günler arasında sıkışıp kalmış gibi duruyor ve oh-it-başka bir dilin modern standardı. Lisp öğrenmek, yeni bir dil öğrenmekle sınırlı değildir - aynı zamanda tamamen farklı bir çalışma ve düşünme yöntemi de öğrenmeniz gerekir ve eğer bir hobi olarak yapıyorsanız, tamam mı? iş.

İşler biraz daha iyi görünmeye başlıyor, özellikle Clojure etraftayken.

Bir milyar yıl önce üniversitede LISP'i öğrendim.

LİSP, FORTH gibi, mantık için mükemmeldir. Ancak çoğu programlama mantıkla ilgili değildir, verileri sıkıcı mekanik yollarla değiştirmekle ilgilidir. Örneğin, o zamanlar sayısal çıktıyı doğrulamak için hiçbir yol yoktur.

LISP iç içe geçmiş işlevsellik ile ilgilidir ve insanlar böyle düşünmüyorlar. DO A, B, C, D, sonra E terimleriyle düşünürler. B ve C'yi, D ve E'yi de içeren A yapmayın. Bu, kafa karıştırıcı bir eşzamanlılık içerir. “Gelir vergisi beyannamesi” gibi önceden tanımlanmış görevler dışında insanlar aynı anda düşünmezler, sıralı düşünürler. Bu nedenle prosedürel diller bugün baskındır.

Sonuç olarak, produral kod, Java ve C'nin kolayca İngilizce'ye çevrilebileceğini sever. LISP kodu olamaz; hiçbir insan dili bu şekilde yapılandırılmamıştır.

Bu yüzden problem çözme için harika, fakat problem çözme programlamada çok önemli değil. Veri girişi, doğrulama, çıktı formatlama, hepsi LISP de oldukça zayıftı.

Lisp ile henüz bahsetmediğim bir problem, vasat veya acemi bir programcı için (kendim gibi serbestçe kabul ediyorum), Lisp kodunu nasıl büyük bir programa dönüştürdüğünüzü görmek zor olabilir. Yazması kolay ama mimarlığı zor. Kavramların hiçbirinin özellikle zor olduğunu sanmıyorum, ancak DIY zihniyeti o kadar güçlü ki çoğu zaman nereden başlayacağımı bile kaybettiğimi hissediyorum.

Java veya C # gibi bir OOP dili ile, yazı tipini kullanarak kendinizi çalışan bir modele yükseltmek için kullanabilirsiniz. Lisp ile (veya Lua veya Javascript, bu konuda), dışarı çıkıp istediğiniz şekilde yapabileceğiniz gibi bir fikir var. OOP istiyorsanız, sadece kendi OOP sisteminizi oluşturun! Kendi OOP'unuzu yapmak veya bir başkasını öğrenmek dışında, kullanılabilir programları almadan önce dilin tepesinde yeni bir engeldir. Artı Lisp'teki OOP ya da Lua'daki gerçekten orada olmadığımı hissediyorum, eğer gerçekten istersem görmezden gelebileceğim gibi, peki nokta ne?

Kısacası, Lisp’te programlamanın çok fazla disiplin gerektirdiğini düşünüyorum. Kesin olarak yazılmış diller ve OOP dillerinin her ikisi de, bir tür yerleşik disipline sahiptir; bu nedenle programcı, sınırlı rezervlerini, dili değiştirmek yerine bitirme projelerine odaklayabilir.

EDIT: Bana daha çok çarpan bir benzetme olarak, biraz tahta işi yapmanız gerekiyor ve iki kişi size alet kutularını sunuyor gibi. Bir kişinin araçları ufak tefek şeylerdir, ancak temelde işi biraz çaba sarf ederek hallederdi. Diğer kişi büyük bir parça bölmesine sahiptir, ancak bu parçaları, şimdiye kadar kullanacağınız en iyi araçları, tutuşunuza ve en iyi kaliteye mükemmel şekilde uyması için bir araya getirebileceğiniz konusunda umut vericidir. Önce onları inşa etmelisin.

Uzun zamandır aynı şeyi merak ediyordum ve hatta bu Lisp'in "karanlık taraf" ın ne olduğunu herkesin evlat edinmesini engellemek için Lisp konferanslarına bile gittim.

Tam olarak düzgün bir cevap bulamadım.

Cehalet eksik popülaritenin nedeni olabilir, ama beni daha çok şaşırtan şey, Lisp'i (hatta Google - Peter Norvig'in kendileri için çalıştığını biliyorlardı) kimin kullandığını bile bilmemesi.

Karşılaştığım tek kısmi açıklama Lisp harika fikirlerinin çoğunun artık yaygın olduğu, gerçekten önemli olan tek eksikliğin (çok önemli bir IMO) metaprogramlama kolaylığı olduğudur.

Ne yazık ki, bu kavramı diğer diller için adsorbe etmenin kolay bir yolunu göremiyorum çünkü metaprogramlamanın güzel olması homoikonik ve düzenli bir dil gerektiriyor (yalnızca aptalca kullanılan şablon değil, genel metaprogramlama hakkında konuşuyorum). Başka bir deyişle, temel olarak Lisp'in sözdizimine yaklaşımını gerektirir: kod veridir ve veri koddur. AST'yi yönlendiren sözdizimi açısından zengin bir dilde kod yazmak daha zordur, çünkü iki dili bilmeniz gerekir: kodu nasıl yazacağınızı ve AST'yi nasıl yazacağınızı. Bu, özellikle AST'niz sabit ve aynı zamanda birçok farklı düğüm tipine sahip karmaşık ve düzensizse zordur. Lisp bunun yerine oldukça düzenli (ve genişletilebilir!) Bir AST'ye sahiptir ve siz zaten normalde AST'yi doğrudan yazarak kodlarsınız.

Metaprogramlama da doğal olarak daha zordur (ve daha fazlası ve meta-metaprogramlama) ve çoğu programcı ve yönetici görünüşte sadece "hiç kimsenin buna ihtiyacı olmaz" cevabını tercih eder.

goİhtiyaç duyulduğunda metin tabanlı metaprogramlama kullanarak (örneğin, metin dosyaları yazan harici kod üreteçleri) ve "sihir" (yani derleyici programcıların yapamadıklarını yapabileceği gibi) gibi "yeni" dillerin bittiğine üzüldüm .

Karmaşıklık sorununun çözümünün güçlü araçlar ve eğitim olduğunu düşünüyorum. Trend görünüşte bunun yerine araçların künt olması ve problemin var olmadığını iddia etmek gibi.

CL'nin bile kütüphane desteğinin çok iyi olmadığı görülüyor. En azından Lisp'ten Python'a geçiş yapan kişilere göre:

http://www.redmountainsw.com/wordpress/archives/reddit-switches-from-lisp-to-python

Şahsen, bazı Şemaları biliyorum ve onunla oynamaktan zevk alıyorum, ancak bu dilde önemsiz bir proje yapmayı düşünemiyorum.

Güçlü olmak mutlaka yaygın kullanım anlamına gelmez. 'Genel dava için optimize et' terimini duydunuz mu? Ne yazık ki, pek çoğu sıradanlıktan önce de söylendiği gibi, aralarında pek çok başarısızlık olan büyük isabetlerden çok, insanlar için daha iyidir.

Bu sadece lisp ile değil, birçok teknolojiyle de geçerli. Unix metin işleme araçları üzerinde iyi bir dokunuş, awk, sed, perl size programlama günlerini kurtarabilir. Ne yazık ki, insanların bu tür görevleri birkaç dakika içinde daha verimli bir şekilde bu araçlarla yapabileceklerini diğer araçlarda yaptıklarını gördüm. Fakat eğer bir kişi bütün hayatını güneş tutulması içinde geçirirse, bu şeylerin değerini asla takdir edemez. Okunabilirlik ve bakım kolaylığı ile büyük bir program yazabilirsiniz, hepsi bu, ancak böyle bir program yazmanın amacı ne yazarken işini kolayca yapamazdı.

Araçları tasarlarken bugünlerde başka bir yönü kutudan ne kadar yararlı olduklarını bir sorunu çözmek için doğrudan kullanmak zorunda kalıyorlar. Çok genel bir şey yapamazsınız ve sonra bunların hepsini kütüphanelerden ve çerçevelerden koruyacağınızı söylersiniz. İşleri bu şekilde halletmesi biraz zor. İyi bir araç, çevre ve etrafındaki sorunlara iyi gelir. Bu yüzden php, perl ve awk gibi araçlar sonsuz trolling ve bodur olmama rağmen alakalı kalmaya devam ediyor, çünkü onları atmak için çok kullanışlıdırlar ve birçok kütüphane ve çerçeveye sahip genel bir dilden çok fazla iş yaparlar.

Benzer şekilde Java / Python gibi dillerin çok iyi olduğunu göreceksiniz ve bazı görevler için en iyisini söyleyeceğim. Python özellikle öğrenmesi ve yazması çok iyi ve kolaydır. Ayrıca, eğer veri uç noktalarınız standart ise, bu diller gerçekten başarılıdır. Bir çeşit veritabanı veya XML veya bu tür bir veri. Temel olarak yapılandırılmış veri.

Lisp uzun süre boyunca orada olacak, ama mutlaka yaygın değil. Göreceğiniz gibi her aracın nişi vardır. Ve bazı problemleri kutudan çok iyi çözüyorlar. Bence lisp'in iyi çözülmek üzere tasarlandığı alanlarda ve problemlerde iyi iş çıkardığından eminim.

Lisp lehçeleriyle web geliştirme için, bir miktar tavuk ve yumurta problemi olabilir - çünkü az sayıda kişi Lisp kullanıyor, ana bilgisayarlar izin vermiyor veya kolaylaştırmıyor ve kolay değil, az kişi kullan. Fakat aslında, Lisp'i bir ana bilgisayarda çalıştırma, hazır oldukları PHP hizmetlerinden biraz daha fazla çalışma gerektirse de, düşündüğünüzden daha kolay olabilir. Kısa süre önce burada çalışan küçük bir çaba ile guile Scheme uygulamaları kullandım .

IMO, çoğunlukla kötü zamanlama meselesidir: Lisp, çoğu insan veya kullanım için pratik hale gelmeden çok önce eskiydi (ve neredeyse tanım olarak artık heyecan verici değildi). Clojure (bir örnek için) çok daha iyi bir şans anlamına gelir. Başarısı, Java ile (ve JVM'de çalışan her şey) birlikte çalışılan kadar her şeyden daha yeni, şık ve havalı olarak algılanmasına bağlı olacaktır.