Gerçek dünya uygulaması için LISP (lehçesi) kullanır mıydınız? Nerede ve neden? [kapalı]


31

LISP (ve Scheme, Common LISP ve Clojure gibi lehçeler) oldukça iyi programlama dilleri olsalar bile çok fazla endüstri desteği kazanmamıştır. (Şu anda bazı çekiş kazanıyor gibi görünüyor olsa da).

Şimdi, bu doğrudan bir soru ile ilgili değil, hangi bir LISP lehçesini bir üretim programı için kullanırsınız? Ne tür bir program ve neden? Başka bir koda (örneğin C) dahil olma türünün kullanımları da dahil edilmiştir, ancak cevabınızda ne demek istediğinizi unutmayın. Geniş kavramlar tercih edilir, ancak özel uygulamalar da iyidir.


6
Emacs “gerçek dünya” uygulaması olarak sayılıyor mu? gnu.org/software/emacs/emacs-lisp-intro
S.Lott

1
@ S.Lott: Evet. Eğer Emacs için uzantı oluşturmak üzere elisp kullanıyorsanız, sorun değil ve bir LISP lehçesinin uygulaması
Anto

GNU Guile tam da bu amaç için tasarlanmıştır.

1
İlginç olsa da, bu sorunun artık bu site için uygun olduğunu sanmıyorum. Birden çok sebep: 1- çok geniş, 2- cevapların bir listesini davet eder, 3- hangisinin “doğru” cevabını seçeceğine karar vermenin kesin bir yolu yoktur, 4- zaman içerisinde çok fazla yerelleşir (“çok fazla endüstri desteği kazanmamış”), 5- tartışma ve tartışmaya davet eder.
Andres F.

Yanıtlar:


18

Bir üretim programı için bir LISP lehçesi kullanır mıydınız?

Kesinlikle

Ne tür bir program ve neden?

Lisp genel amaçlı bir dinamik dildir. Bugün, Microsoft tarafından yayımlanmayan diğer genel amaçlı dinamik dillerle aynı temel zorluklara sahip: Yerel konular, GUI entegrasyonu, GC'nin deterministik çalışması ve küçük bellek ayak izleri.

Yerel konu başlıkları LispWorks ve SBCL tarafından sağlandı, inanıyorum. Muhtemelen diğerleri? Tam olarak araştırmadım.

LispWorks ve Franz Common Lisp - ticari ürünler - GUI'ye başarı dereceleriyle bütünleşir. Onları satın almak için $$ sahip değil, ne kadar iyi çalıştığını bilmiyorum. Oldukça iyi çalıştıklarından şüpheleniyorum ...

Bir deterministik GC operasyonu (başarı bazı seviyesine Java bitti) yapılabilir, ancak ben mevcut Lisp sistemleri (devam olanlar) bunu herhangi bir kod varsa bilmiyorum.

Küçük bellek ayak izi bazı Lisps tarafından başarıldığını düşünüyorum.

Temel noktam, Common Lisp teknik olarak üretim sistemleri yapmaya hazır. Ve yapar .

Geliştiricilerin büyük çoğunluğu, dinamik diller, makrolar, parantezler, favori IDE eksikliği, üniversitedeki kötü deneyim, içinde pek fazla iş bulunmadığından korkmazlar.

Şahsen, ortak bir ortamda ortak bir yerden Common Lisp'te tam teşekküllü bir üretim sistemi kurmaya atladım.

düzenleme: Lisp'in neden diğer dillerin aksine olduğunu gerçekten cevaplamadım.

Lisp deneyimlerime göre - anlamlı değil, ancak “merhaba dünyasından” çok daha fazla - dili ilk "Argh yeni dil" sancılarından sonra son derece kullanışlı buldum. Dilin çoğunluğu, benim gibi çalışacak diğer dilleri bulamadığım çok düzenli ve oldukça açık bir şekilde bir araya geliyor. Bunun bir kısmı ifadelerin ve ifadelerin birleştirilmesidir. Bunun bir kısmı çekirdek liste veri tipidir. Bunun bir kısmı tip sistemidir. Bunun bir kısmı makro sistemidir. Beni yanlış anlama, yine de acı noktaları var. Fakat beni diğer dillerin acı noktaları kadar suratına atmıyorlar.

Basit bir örnek Python'un liste uzunluğu yordamıdır. Python yaklaşımı çağırmaktır len(mysequence). Fakat eğer düşünürsek, uzunluk bir dizinin özelliğidir. Yani, mysequence.len()daha uygun bir fikir. Lisp, esasen bu sözdizimsel ayrımı ortadan kaldırır. (length thing)hem işlev çağrısı sözdizimi hem de yöntem sözdizimidir. Elbette, bazı insanlar bunu sinir bozucu buluyor ve sözdizimsel farkı istiyor. Düzenli olmayı tercih ederim.

edit2: Masaüstünde çalışan MS tezimin bir bölümünü Common Lisp'e dönüştürdüm ve şimdiye kadar çalışmak bir zevkti.


2
Duyduğuma göre, LISP tam teşekküllü üretim sistemlerinde kullanılıyor, ancak yalnızca LISP'de kodlanması diğer dillerden daha kolay olan belirli mantık işlemlerinde kullanılıyor. Video oyunu AI ve istatistiksel verilerin ön işlenmesi bir zamanlar bana alıntı yapılan örneklerdir. Bir zamanlar "Yeterince karmaşık bir sistemde yerleşik yarı zamanlı LISP uygulaması var" diyen bir yöneticim vardı. Benzer bir deyim "Yeterince şişirilmiş bir sistemde yerleşik bir e-posta okuyucusu var" idi.
SinirliFormsDesigner ile

4
@ Ünlü: Evet, bunlar Greenspun Kanunu, ve jwz'in kanunu.
Paul Nathan

2
Bunların çoğu Clojure tarafından çözülüyor, sadece uyumlu olması için tasarlandı ve Java'nın yerini aldı. Ancak elbette, JVM için de Şema ve CL uygulamaları vardır (örneğin, Kawa, ABCL).
Jörg W Mittag

4
Clojure belli belirsiz bana sinir bozucu çünkü başka bir parçalanma.
Paul Nathan

parçalanma kötü bir şey değil. Clojure'da gerçekten sinir bozucu olan şey, noktalı çiftlerin olmaması. Bu kadar temel bir şey olmadan Lisp benzeri bir dil olarak sayılabilir mi?
SK-mantık

11

Londra’da birkaç yatırım bankası ve yeni girişimde Lisp’i Clojure biçiminde kullanan insanları şahsen tanıyorum. Ayrıca Clojure'u kendi başlangıcım için birincil geliştirme dili olarak seçtim, bu yüzden paramı ağzımın olduğu yere koymak için istekliyim :-)

Geçen yıl Clojure'u öğrenmek için çok aydınlatıcı bir deneyim olduğunu öğrendim (Java ve C # ile ilgili çok fazla deneyimden sonra). Bunun ana nedenleri:

  • İşlevsel programlamaya (diğer Lisps'tan çok daha fazla) oldukça güçlü bir vurgu yaptı . Yazar ve BDFL Rich Hickey sık sık Haskell'i dil tasarımı konusundaki ilhamlarından biri olarak gösterdi; bu da tamamen değişken veri yapıları ve tembel sonsuz diziler vb.
  • Makro metaprogramlama - Lisp "kod veridir" felsefesini gerçekten yaşamadığınız sürece anlamak zordur, ancak Lisps'ın bu kadar etkileyici ve üretken olmasının sebeplerinden biridir. Temel olarak dili sorunlu alanınıza uyacak şekilde genişletme gücünüz var.
  • Çok çekirdekli eşzamanlılık için harika destek - Aslında Clojure'un şu anda eşzamanlı programlama için en iyi dil olduğunu düşünüyorum . Bu konuda aydınlatıcı bir sunum için http://www.infoq.com/presentations/Value-Identity-State-Rich-Hickey e bakınız.
  • REPL'deki etkileşimli gelişim, bina uygulamaları için harika ve verimli bir yoldur. Çalışan uygulama kodunuzu dinamik olarak değiştirmek ve canlı veri yapılarını programlı olarak incelemek için size gerçek bir güç hissi verir.

Ayrıca, aşağıdaki nedenlerden dolayı gerçek üretim kullanımı için pratik bir seçenek gibi görünmektedir:

  • JVM'de çok kolay Java birlikte çalışabilirliği ile çalışmak, Java ekosistemindeki tüm kitaplıklara ve araçlara erişmenizi sağlar
  • Kurumsal uygulamalar için denenmiş ve test edilmiş bir platform olan JVM'de çalışıyorsunuz . Clojure, mükemmel GC ve JIT derlemesi gibi tüm güzel JVM özelliklerinden ücretsiz yararlanır.
  • Bu bir var dinamik dil neredeyse hiç Demirbaş ile geliştirme ve prototip çalışmaları çok uygun kılan varsayılan olarak. Ancak, ihtiyaç duyduğunuz yerde oldukça iyi bir performans elde etmek için statik tip ipuçları ekleyebilirsiniz.
  • Bu bir var pragmatik ve yararlı topluluk - insanlar halletmek kültürünün tür ve odak gerçek sorunları çözmek iyi tasarlanmış çözümler üzerinde olduğunu
  • Birden fazla IDE'de araç desteği var . Ben şahsen Eclipse'i Counterclockwise plugin ile kullanıyorum (çünkü Java entegrasyonuna ihtiyacım var) ancak başka birçok seçenek var.

8

İş için en iyi seçim olsaydı LISP kullanırdım. Sadece "en iyi seçimi" etkileyen şeyler:

  • satıcı desteği. Kullandığımız LISP uygulaması - eğer bir şeyler ters giderse ve gelişimimize ve dolayısıyla son tarihlerimize müdahale ederse, satıcı bizimle bir çözüme doğru çalışacak mı?
  • Kütüphane desteği Hangi kütüphaneler mevcuttur? Dize manipülasyonu, matematik, veri erişimi, web-servletleri (veya LISP-eşdeğerleri), pencereleme araç takımı, vb ... Bu şeyleri sıfırdan yazmak zorunda kalmak istemiyorum.
  • araç desteği - IDE ne kadar iyi? Katı / sağlam mı, lapa lapa mı? İyi editör desteği? Entegre hata ayıklayıcı? LISP'de GUI dev yapmam gerekirse, görsel bir IDE var mı veya GUI düzenini elle kodlamak zorunda mıyım (bunu yapmaktan nefret ediyorum ).
  • geliştirici katılımcısı (Takım arkadaşlarıma tamamen yeni bir dil öğretmek için çok fazla zaman harcamak istemiyorum)

Bu faktörlerin tümü, LISP'in bir proje için uygun olup olmadığına karar verirken dikkate alınmalıdır. İş dünyasında bunu hiç tecrübe etmedim.


Üretkenliğin genellikle dilin kendisinden ziyade mevcut araç ve kütüphanelerden daha fazla etkilendiğini kabul ediyorum (dilin bazı temel işlevler sunması koşuluyla).
Giorgio

6

Kesinlikle. Paul Graham bunu iyi açıklıyor .

... 1995 yılında, rakiplerimizin anlamadığını sanmadığım bir şey biliyorduk ve şimdi bile pek azı anlıyor: Yalnızca kendi sunucularında çalışması gereken bir yazılım yazarken, istediğin dili kullanabilirsin. ..

Lisp'i seçtik. Birincisi, hızlı pazarlamanın bu pazarda önemli olacağı açıktı. Hepimiz sıfırdan başlıyorduk, bu yüzden rakiplerinden önce yeni özellikler alabilecek bir şirket büyük bir avantaja sahip olacaktı. Lisp'in hızlı bir şekilde yazılım yazmak için gerçekten iyi bir dil olduğunu biliyorduk ve sunucu tabanlı uygulamalar hızlı gelişmenin etkisini artırıyor, çünkü yazılımın yapıldığı an yayınlayabilirsiniz.

Diğer şirketler Lisp kullanmak istemedilerse, çok daha iyi. Bize teknolojik bir avantaj sağlayabilir ve alabileceğimiz her türlü yardıma ihtiyacımız vardı ...

Yani Lisp'i kullanmanın bir deney olduğunu söyleyebilirsiniz. Hipotezimiz, eğer yazılımımızı Lisp'e yazarsak, özelliklerimizi rakiplerimizden daha hızlı yapabileceğimizi ve aynı zamanda yazılımımızda yapamadıkları şeyleri yapabileceğimizi gösteriyordu. Lisp çok yüksek olduğu için büyük bir geliştirme ekibine ihtiyacımız olmaz, bu yüzden maliyetlerimiz daha düşük olur. Öyle olsaydı, daha az parayla daha iyi bir ürün önerebiliriz ve yine de kar edebiliriz. Tüm kullanıcıları elde edecektik ve rakiplerimiz hiçbiri alamayacak ve sonunda işsiz kalacaktır. Zaten olmasını umduğumuz şey buydu.

Bu deneyin sonuçları neydi? Biraz şaşırtıcı bir şekilde çalıştı. Sonunda, yirmi ila otuz sırasına göre, birçok rakibimiz vardı, ancak yazılımlarının hiçbiri bizimki ile rekabet edemedi. Sunucuda çalışan ve bir masaüstü uygulaması gibi hisseden bir wysiwyg çevrimiçi mağaza oluşturucumuz vardı. Rakiplerimizin cgi senaryoları vardı. Ve biz her zaman özelliklerin çok ötesindeydik. Bazen, çaresizlik içinde yarışmacılar sahip olmadığımız özellikleri sunmaya çalışırlar. Ancak Lisp ile geliştirme sürecimiz o kadar hızlıydı ki bazen bir ya da iki gün içinde bir basın açıklamasında ilan eden bir yarışmacının içinde yeni bir özelliği çoğaltabilirdik. Basın açıklamasını kapsayan gazeteciler bizi aramaya başladıklarında, yeni özelliğe de sahip olacaktık.

Rakiplerimize, Enigma trafiğini ya da bir şeyini çözdüğümüz bir tür gizli silahımız olduğu görülüyordu. Aslında gizli bir silahımız vardı, ancak fark ettiklerinden daha kolaydı. Kimse bize özelliklerinin haberini sızdırmıyordu. Yazılımı, herkesin düşündüğünden daha hızlı geliştirebildik ...


8
“... Paul Graham aslında bir kahve beklerken peçetenin arkasına lisp'ta reddit yazdı. O kadar güçlüydü ki, sıradan bilgisayarların anlayabilmesi için python ile yeniden yazılması gerekiyordu. Lisp'te yazılmıştı, her şeyi yeniden yazmak neredeyse hiç çaba sarf etmiyordu ve yeniden yazma işlemi iki işlemci döngüsü arasında tamamlandı, Paul Graham'ın kendisi de daha önce lisp dilinde yazılmış, Lisp'te yazılmış Lisp’in önceki sürümü. Lisp, Paul Graham, Lisp, Paul Graham.
John Cartwright

5

Nerede: Emacs, LISP kullanan gerçek dünyaya ait bir uygulamadır.

Neden: Tuş vuruşu ve eylem arasındaki eşleştirmeyi ifade etmenin harika bir yoluydu. Yorumlanır ve hızlıdır ve iyi tanımlanmıştır ve basittir.


Bu cevabı, ketstrokes ve eylemler arasındaki eşleştirmeyi ifade etmenin neden iyi olduğunu söyleyerek uzatabilirim
Anto

@Anto: Tecrübelerime göre, Lisp bir editörde yapabileceğiniz herhangi bir eylemi çok tutarlı bir şekilde şeffaf bir şekilde temsil edebilecek güçlü soyutlamalar yaratmayı gerçekten kolaylaştırıyor - Emacs'ı bir süreliğine kullandıktan sonra, neredeyse her şeyin nasıl yapıldığını tahmin edebilirsiniz. . Bu , editörde yapabileceğiniz her şeyi bir tuş vuruşuyla eşleştirmeyi mümkün kılar ve her bir ciltleme birbirine gerçekten çok benzeyen bir görünüm sağlar, hem yazması hem de bakımı daha kolaydır.
Tikhon Jelvis

4

Hem Macsyma hem de Autocad , Lisp lehçesine dayanır. Onları Emacs'ın yanı sıra 'gerçek dünya' olarak sınıflandırırdım.


Mathematica, Lisp'e dayanmaz.
Rainer Joswig

2
AutoCAD, bir API olarak AutoLISP sunar ancak C ++ ve .NET yönetilen kodunda yazılmıştır.
CAD

1
@RainerJoswig Macsyma muhtemelen Mathematica yerine kullanılıyordu.
user40989

2

Kesinlikle bunu düşünürdüm. Özellikle bazı paralel hesaplama potansiyeli olan yeni geliştirme çalışmaları için. Bu, bu tür işlevsel diller için tatlı bir nokta gibi görünüyor.


2

Lisp, derleyiciler uygulamak için en iyi seçeneklerden biridir. DSL ve eDSL'lerin kullanımı gün geçtikçe artıyor, Lisp daha değerli hale geliyor. DSL ile ilgili tüm görevlerim için bir Lisp lehçesi kullanıyorum.


0

Şu anda, NewLisp'i kişisel web sitemdeki Php yerine Dragonfly çerçevesiyle değiştirmeye çalışıyorum. Apache'nin güzel oynamasını nasıl sağlayabileceğimi öğrenebilirsem, kullanacağım (yerleşik web sunucusu çok iyi çalışıyor ancak Apache üzerinden çalışacağım). Ve bu bir kez olduğunda, Php kullanacağım herhangi bir yerde newLisp kullanacağım, çünkü Php'dan hoşlanmıyorum ve newLisp'ten de hoşlanıyorum.

Şu anda Clojure, Android uygulamaları için iyi bir seçim değil, ama insanların bu konuda çalıştığını biliyorum. Eğer çözülürse, gerçek dünya uygulamaları için Lisp lehçesini kullanacağım başka bir yer olurdu ... ama yine de, çünkü sadece Java'yı sevmiyorum.

Ama dürüst olmak gerekirse, Ruby'yi Lisp'a tercih ederim ... ama bu çoğunlukla bir topluluk ve belgeleme meselesidir.


0

Common Lisp'te Microsoft Windows'da yerel olarak çalıştırılabilir olarak çalışan Tankan adlı tescilli ve ticari bir uygulama yaptım .

Japonca kanji karakterlerini ezberlemek için kendinizi eğitmek için bir program.

Program arka plan HTTP sunucusu olarak çalışır. Bu sunucunun çalıştırılması ve sayfalarına gidilmesi, Visual C ++ kullanarak geliştirdiğim küçük bir sistem bildirim alanı (aka "Tepsi") simge uygulaması tarafından koordine ediliyor.

Minik tepsi simgesi uygulaması, Lisp tabanlı sunucuyu başlatır, izler ve durdurur ve onun standart giriş ve çıkışına bağlı Win32 borularını kullanarak iletişim kurar. Bir boru aracılığıyla Lisp sunucusu, kesin URL'nin tepsi simgesi uygulamasını doğru bağlantı noktası numarasıyla bilgilendirir ve bu tepsi simgesi uygulaması, bu URL'ye göz atmak için tarayıcıyı Shell API üzerinden başlatabilir. Kullanıcı, kullanıcı arayüzünü getirmek için simgeye çift tıklar.

Lisp programı hafızasında, kullanıcının girdi geçmişini ve çeşitli nesneler arasındaki çeşitli ilişkileri içeren oldukça karmaşık bir oturum durumu sürdürmektedir. Lisp'in dairesel nesne gösterimi ( *print-circle*değişken tarafından etkin ) ve özel CLOS print-objectyöntemlerinde nasıl çalıştığı , kalıcılığı uygulamada çok büyük bir yardımcıdır: kullanıcılar, durumu diske kaydedebilir ve kaldıkları yerden devam ettirebilirler. UI'nin durumu dahil her şey kaydedilir. Nesne grafiğinde döngülerin yanı sıra çok sayıda paylaşılan altyapı vardır. Ayrıca, sözlük giriş nesnelerinin içeriği gibi, sürdürülmesi gerekmeyen birçok statik güvenlik sorunu da var. ANSI Common Lisp özel baskı nesnesi yöntemleriyle, yine de makinede okunabilen nesneler için yoğun basılı gösterimler oluşturabilirsiniz,

Web kullanıcı arayüzünde neredeyse hiç JavaScript kullanılmamaktadır. Kullanıcı Arabiriminin bölümlerini gizleme ve gösterme kontrolleri bile form gönderme ve HTML'yi yeniden oluşturma yoluyla yapılır. UI durumunun her detayı bu nedenle sunucudadır ve kullanıcı kaydettiğinde devam eder. HTML’nin yeniden oluşturulması çok hızlı. HTML üreten bir makroyu besleyen dev bir Lisp backquote ifadesiyle yapılır. Clozure Common Lisp (CCL) tarafından derlenen kod, bunu o kadar hızlı yapıyor ki, bir şeyi açmak için UI'deki [+] düğmesine tıkladığınızda, yeni bir sunucuya bir istek gönderdiğinizi bilmiyorsunuz. lanet sayfanın tamamı ve yalnızca yerel bir belge öğesinin görünürlüğünü değiştirmek için bazı yerel JavaScript çalıştırma.

Program başlangıçta CLISP ile geliştirildi. ANSI CL'nin standart bir dil olması sayesinde, dilde sinsi tuzaklara ("tanımsız" veya "uygulama tanımlı" davranışa) uygun olmayan uygulamalar ile CCL'ye kolayca taşınabilir.

CLISP terk edilmedi; Yine aynı ortak kod tabanını kullanarak, lisanslama arka ucuna güç vermek için kullanılır.

Program için orijinal bir lisanslama sistemi geliştirdim, lisans sunucusu tarafından onları onaylamak için lisanslama yapmak için kullanılan IronClad kütüphanesinin sağladığı eliptik eğri kriptosunu kullandım. (Sunucu anahtarı için EC parametreleri oluşturmak üzere OpenSSL'nin komut satırı programını kullandığımı hatırlıyor gibiyim.)

Lisanslar Lisp nesneleri olarak temsil edilir. Clozure Common Lisp tarafından derlenen bir Windows programının S ifadesine dayalı bir lisans üretebileceği, Debian sunucusunda çalışan bir CLISP programının bu nesnedeki eksik dijital imza alanını doldurabileceği ve geri gönderebileceği, Lisp taşınabilirliğine bir hediyedir İmzayı doğrulayabilen Windows programı.

Sunucuda, CGI tabanlı lisans hizmetine ek olarak, lisansları yönetmek için basit komut satırı API'ları da kullanıyorum. Lisansları listeleyebilir, belirlilerini bulabilir ve özniteliklerini düzenleyebilirsiniz: örneğin, bir kullanıcıya istisna vermek için geçici bir lisansın son kullanma tarihini düzenleme gibi. Lisanslama back-end ayrıca e-postalar üretir. Sunucu tarafında CGI kullanımı için herhangi bir kütüphane kullanmadım: Apache ortam değişkenleri ve komut satırı argümanları ile ilgilenmek için sadece elle yuvarlanmış Lisp kodu. (Her ne kadar kütüphane kodu URL kodlama ve HTML oluşturma ile uğraşmak için kullanılsa da.) Depolama için hiçbir veritabanı kullanılmaz; lisanslar adı verilen bir dosyaya dönüştürülür licenses.lispve işte budur.


-1

Biri bana para öderse, elbette.

Muhtemelen dili bilen birine ödeme yapmakla daha çok ilgilenirlerdi. Sadece elisp ve düzeni ile birkaç kez oynadım.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.