Dlaczego Lisp nie jest bardziej rozpowszechniony? [Zamknięte]

50

Zaczynam uczyć się schematu na podstawie filmów SICP i chciałbym przejść do Common Lisp.

Język wydaje się bardzo interesujący, a większość ludzi piszących na nim książki opowiada się za tym, że ma niezrównaną siłę ekspresji. Wydaje się, że CL ma przyzwoitą standardową bibliotekę.

Dlaczego Lisp nie jest bardziej rozpowszechniony? Jeśli naprawdę jest tak potężny, ludzie powinni go używać wszędzie, ale zamiast tego prawie niemożliwe jest znalezienie, powiedzmy, ofert pracy Lisp.

Mam nadzieję, że nie jest to tylko nawias, ponieważ po pewnym czasie nie stanowią wielkiego problemu.

Andrea
źródło
3
xkcd2.heroku.com/297
Michelle Tilley
5
Steel Bank (wspólny) LISP jest tak naprawdę bardziej popularny niż można sobie wyobrazić. Makroprocesory podobne do LISP (np. M4) są również szeroko stosowane. Być może nie widzisz go w wybranej przez siebie domenie, ale wciąż istnieje (na dobre lub na złe).
Tim Post
8
Ostatnie trzęsienie ziemi i tsunami zniszczyły fabrykę nawiasów w Japonii. :-(
oosterwal
1
Jakiej wersji Lisp powinniśmy używać? Pamiętaj, że dialekty Lisp są mniej lub bardziej niezgodne.
2
LISP (lub dialekty) są używane wszędzie, np. AutoLISP to dialekt LISP używany przez Autocad pl.wikipedia.org/wiki/AutoLISP lub EMACS en.wikipedia.org/wiki/Emacs_Lisp
Jaydee

Odpowiedzi:

68

Ekspresyjność nie zawsze jest pozytywną cechą językową w środowisku korporacyjnym. Java jest niezwykle popularna częściowo dlatego, że jest łatwa do nauczenia, łatwa do napisania i łatwa do odczytania. Przeciętni programiści mogą nadal być bardzo wydajni w Javie, nawet jeśli ich kod jest nieporadny i nieelegancki.

Ponadto łatwo jest nadużywać wyrazistych języków. Specjalista z języka Java może szybko refaktoryzować źle napisany kod. Im bardziej wyrazisty język, tym trudniejsze staje się zrozumienie i refaktoryzacja okropnego kodu. Makra LISP są dobrym przykładem. Makra to potężne narzędzia we właściwych rękach. Nieprawidłowe ręce mogą powodować mylące i trudne do debugowania kody.

LISP jest ryzykownym wyborem dla wyższej kadry kierowniczej. Jeśli coś pójdzie nie tak, nikt nie będzie winił zarządzania za wybranie popularnego języka obiektowego wspieranego przez takie wielkie korporacje jak Oracle czy Microsoft. Znacznie łatwiej jest zatrudnić programistów z doświadczeniem w popularnych, łatwych do nauki językach.

Nawet postępowe firmy, które chcą używać mocniejszego języka, zwykle nie wybierają LISP. Wynika to z faktu, że wiele nowszych języków próbuje pójść na kompromis, pożyczając potężne funkcje od LISP, pozostając jednocześnie łatwym do nauczenia się dla mas. Scala i Ruby podążają za tym modelem. Źli programiści mogą je szybko odebrać i nadal pisać ten sam mierny kod, co w Javie. Dobrzy programiści mogą korzystać z bardziej zaawansowanych funkcji, aby pisać piękny kod.

Nawiasy nie stanowią problemu. Haskell jest niezwykle potężnym i ekspresyjnym językiem o składni podobnej do Pythona lub Ruby i nie został powszechnie przyjęty z wielu tych samych powodów, co LISP.

Mimo to mam nadzieję ...

Clojure ma szansę stać się popularnym. Działa na JVM, świetnie współpracuje z Javą i znacznie ułatwia programowanie współbieżne. To są ważne rzeczy dla wielu firm.

* To moja perspektywa jako profesjonalnego programisty JVM z doświadczeniem w Javie, Clojure, JRuby i Scali.

dbyrne
źródło
24
Zarzut dotyczący trudności ze znalezieniem wykwalifikowanych programistów to trochę pies goniący swój ogon. Gdyby Lisp był bardziej rozpowszechniony, łatwiej byłoby znaleźć dobrych programistów.
Andrea,
2
@Andrea To zdecydowanie prawda. Trudniej jednak nauczyć się seplenienia, co również przyczynia się do powstania problemu. Zdaję sobie sprawę, że może to być kontrowersyjna opinia, ponieważ wielu profesorów uczy schematu jako pierwszego języka.
dbyrne
8
Tak, APL jest doskonałym przykładem wyrazistego języka. Dobry przykład tego, dlaczego ekspresja nie jest najważniejsza;)
dbyrne,
9
Nie sądzę, że ta definicja faktycznie oddaje znaczenie ekspresji. Osobiście, zanim nazywam język ekspresyjny, upewnię się, że jestem w stanie przeczytać to, co napisałem. Na przykład użycie nietrywialnej logiki w inicjalizatorze pętli w C może zaoszczędzić ci niektórych linii kodu, ale nie jest łatwo zrozumiałe. Z drugiej strony, zrozumienie listy w Pythonie może zapisać kilka wierszy i być bardziej czytelne. Więc rzeczywiście znalazłeś sposób, aby wyrazić to, co miałeś na myśli bardziej zwięźle. Jeśli nie jest to czytelne, w ogóle nie możesz znaleźć sposobu na wyrażenie tego.
Andrea
3
Myślę, że może wychodzę jako ktoś, kto nie lubi seplenienia. Tak naprawdę to kocham. Clojure to niesamowity język. Myślę, że jest to bardzo opłacalny wybór dla pewnego rodzaju firmy. Po prostu wskazuję, że istnieje wiele firm, w których nie miałoby to sensu, a użycie czegoś takiego jak Scala jest znacznie bardziej praktycznym wyborem.
dbyrne,
17

Dlaczego Lisp nie jest bardziej rozpowszechniony? Jeśli naprawdę jest tak potężny, ludzie powinni go używać wszędzie,

Jeśli uważasz, że języki zostały wybrane ze względu na ich zalety techniczne, czeka Cię miażdżące rozczarowanie.

Takie decyzje są podejmowane na podstawie Strippers And Steaks . Microsoft może sobie na nie pozwolić. Oracle może. Sun wydał tak dużo pieniędzy na przerzucanie Javy, że zbankrutowali. Dwa razy. Zdecentralizowana, heterogeniczna społeczność wolontariuszy nie może z tym konkurować.

ale zamiast tego prawie niemożliwe jest znalezienie, powiedzmy, ofert pracy Lisp.

Co zabawne, firmy Lisp mówią dokładnie odwrotnie: ciągle mają oferty pracy, ale nie mogą znaleźć wystarczającej liczby osób, aby je obsadzić. (To samo dotyczy Haskell, ML, O'Caml, Forth, Smalltalk, ...)

Jörg W Mittag
źródło
3
Gdzie mieszkam (Włochy) Wątpię, żeby istniała choć jedna firma Lisp ...
Andrea,
1
Jakie duże firmy naciskają na Ruby, Python i JavaScript? JS jest wprawdzie wyjątkowym przypadkiem, ale pozostałe dwa wydają się być popularne bez masowego wsparcia ze strony firmy / dostawcy
Ben Hughes
Tak, dotyczy to również innych języków. Większość dobrych koderów COBOL ma już zadania i i tak nie czyta reklam. Po co zawracać sobie głowę reklamą?
Bo Persson
Co naprawdę Będę kodować w dowolnym języku, który nie jest głównym nurtem, chociaż Haskell brzmi mi ponad głową. Niewielka ilość kodu, który w nim zakodowałem, jest niezwykle piękna, ale bez dobrego mentora nie mam pojęcia, kiedy użyć każdej Monady i Funkcji Aplikacyjnych.
aoeu256
9

Nie mam doświadczenia w pracy w prawdziwej firmie, ale wiem, dlaczego korzystanie z LISP było dla mnie trudne.

Przede wszystkim przypomina mi ten post na blogu: http://steve-yegge.blogspot.com/2006/04/lisp-is-not-acceptable-lisp.html

Głównym problemem, który mam z Lispem, jest pytanie „które Lisp”. Zwykle pracuję na Linuksie jako mojej głównej platformie, ale rzeczy, które tworzę, muszą być kompatybilne z Windows. Oznacza to, że kiedy oceniam technologię, która ma być użyta, musi ona ułatwić mi życie, pracując na dwóch radykalnie różnych systemach operacyjnych. Nie podoba mi się to wymaganie, ale jest ono wymagane w prawdziwym projekcie. Teraz będę używać języków, które nie mają bardzo dobrego wsparcia w systemie Windows dla moich osobistych projektów pobocznych, ale ponieważ nigdy nie mam okazji napisać w nich dużego projektu oprogramowania, nie mam niezbędnego doświadczenia.

Teraz, kiedy próbowałem nauczyć się funkcjonalnego języka, naprawdę chciałem nauczyć się Common Lisp. To wydawało się słuszne. Zacząłem czytać Practical Common Lisp jako punkt wyjścia, ponieważ tak naprawdę nie znałem wbudowanych funkcji i potrzebowałem projektu do pracy w Lisp. Wyrażenia S były piękne i łatwe. Wszystkie te nawiasy były dla mnie niesamowicie piękne, ponieważ w dzień było jasne, co dokładnie dzieje się w kodzie.

Próbuję więc napisać swój pierwszy program w Lisp poza książką. Chciałem narzędzia wiersza poleceń, które zliczałoby wiersze kodu i usuwało trywialne wiersze z licznika kodów. Nie jest to najbardziej przydatne narzędzie, ale sprawia przyjemność. Obejmuje dostęp do plików, trochę analizowania i liczenia. Zaimplementowałem to samo narzędzie w Pythonie około tydzień wcześniej.

Potrzebuję uzyskać dostęp do argumentów wiersza poleceń. Potem dowiaduję się, że nie ma standardowego sposobu na uzyskanie argumentów wiersza poleceń. Wszystkie są niestandardowe. To wcale nie jest wieloplatformowe. Od tego momentu staje się coraz gorzej, ponieważ język nie ma wbudowanych zbyt wielu bibliotek. Skończyłem na przejściu na Haskell i nie wdałem się zbytnio w Common Lisp (więc moje skargi mogą nawet nie być ważne).

Tego rodzaju niestandardowe rzeczy zawsze były dla mnie uciążliwe. C ++ ma ten sam problem, ale dzięki bibliotekom takim jak Boost można obejść te słabości.

Nie pomaga również to, że składnia Lisp dla wszystkiego innego niż wyrażenia S jest trochę brzydka.

jsternberg
źródło
1
Rakieta PLT (wcześniej PLT Scheme) działa dobrze zarówno w systemie Linux, jak i Windows.
Larry Coleman
Co ciekawe, spodziewałbym się, że Common Lisp będzie o wiele bardziej standardowy i użyteczny do rzeczywistych aplikacji niż Scheme. (Czytam teraz Practical Common Lisp.)
Giorgio
Pochwalam za wybranie Haskell (który moim zdaniem jest lepszym językiem), ale co z Clojure? Działa na JVM, więc powinien być przenośny i mieć dostęp do wszystkich potrzebnych bibliotek.
Andres F.,
Argumenty wiersza poleceń są trudne do użycia w C ++? Naprawdę?
Nick Keighley,
Czy nie jest trywialne zbudowanie kompromisu, który zmieni Lisp na Scheme na Clojure? Dlaczego ludzie ich nie używają?
aoeu256
8

IMO wynika głównie z:

  • Słaba obsługa bibliotek. Jasne, teraz jest Quicklisp, który ułatwia instalowanie bibliotek, ale nie rekompensuje to, że wciąż jest ich dość mało, a całkiem sporo jest źle udokumentowanych lub niezbyt dobrze utrzymanych. W porównaniu do Pythona istnieje duża szansa, że ​​napisanie nietrywialnej aplikacji Lisp (niezależnie od konkretnego dialektu) prawdopodobnie nadal będzie wymagało wynalezienia przynajmniej części koła lub dwóch.
  • Brak znajomości modelu przyjętego przez narzędzia programistyczne. Większość osób, które znam, są dość zastraszone przez konieczność używania SLIME i Emacsa, co jest zrozumiałe dla osób przyzwyczajonych do Eclipse i Visual Studio. Myślę, że są dwie wtyczki Eclipse, próbowałem tylko jedną z nich kilka lat temu i było dość wadliwe. Cały ekosystem Lisp wygląda, jakby utknął w połowie drogi między dniami, kiedy był częścią pełnowartościowego systemu Lisp i nowoczesnego standardu och-to-inny-język. Nauka Lisp nie ogranicza się do nauki nowego języka - musisz także nauczyć się zupełnie innego sposobu pracy i myślenia, i chociaż jest to w porządku, jeśli robisz to jako hobby, wątpliwe jest, czy warto to robić w biznes.

Sprawy zaczynają jednak wyglądać nieco lepiej, zwłaszcza w obecności Clojure.

donkey_lz
źródło
1
„Większość osób, które znam, są dość zastraszone przez konieczność używania SLIME i Emacsa, co jest zrozumiałe dla osób przyzwyczajonych do Eclipse i Visual Studio.”: Raz po raz mam wrażenie, że Lisp jest elitarny.
Giorgio
2
„Musisz także nauczyć się zupełnie innego sposobu pracy i myślenia, i chociaż jest to w porządku, jeśli robisz to jako hobby, wątpliwe jest, czy warto robić to w biznesie.”: Czy wzrost wydajności nie jest wystarczająco dobry powód?
Giorgio
Czy wykazano tę „zwiększoną wydajność”? Z pewnością nie jest to dla mnie jasne (tak, zaprogramowałem dialekt Lisp). Nie ma srebrnych kul.
Nick Keighley,
5

Nauczyłem się LISP miliard lat temu na studiach.

LISP, podobnie jak FORTH, świetnie nadaje się do logiki. Ale większość programowania nie polega na logice, lecz na manipulowaniu danymi w nudny, mechaniczny sposób. Na przykład w tym czasie nie ma sposobu, aby uzasadnić dane liczbowe.

LISP dotyczy zagnieżdżonej funkcjonalności, a ludzie po prostu nie myślą w ten sposób. Myślą w kategoriach DO A, B, C, D, a następnie E. Nie rób A, co obejmuje robienie B i C, a następnie D i E. To dotyczy pewnego rodzaju współbieżności, która jest myląca. Z wyjątkiem predefiniowanych zadań, takich jak „złożenie zeznania podatkowego”, ludzie nie myślą jednocześnie, myślą sekwencyjnie. Właśnie dlatego języki proceduralne są dziś dominujące.

W rezultacie kod produralowy, taki jak Java, i C można łatwo przetłumaczyć na angielski. Kod LISP nie może; żaden ludzki język nie ma takiej struktury.

Jest więc świetny do rozwiązywania problemów, ale rozwiązywanie problemów nie jest bardzo ważne w programowaniu. Wprowadzanie danych, sprawdzanie poprawności, formatowanie wyjściowe, z których wszystkie były bardzo słabe w LISP.

Andy Canfield
źródło
7
Rozwiązywanie problemów JEST wszystkim, co robimy. Manipulowanie danymi nie jest łatwe w Javie ani C. Manipulowanie danymi w komórkach Cons jest znacznie łatwiejsze w Lisp i innych językach funkcjonalnych. Większość operacji na danych jest dokładnie taka sama i nie ma znaczenia, w jakiej kolejności je przetwarzamy. Można to łatwo wykonać za pomocą wywołania mapy i wskaźnika funkcji. Powiedziałbym również, że łatwiej jest myśleć w funkcjonalności zagnieżdżonej niż w funkcjonalności proceduralnej (jako że jedna szczegółowo określa twój cel, a druga szczegóły, jak wykonać ten cel), ale nie mam na to dowodów. Tak czy inaczej, nie powiedziałbym, że to jest powód, dla którego LISP nie jest używany.
jsternberg
4
Programowanie nie polega na rozwiązywaniu problemów? Nie wydaje mi się A tak przy okazji, nie sądzę, że można uczyć się języka na studiach.
Adam Arold
+1, brzmi bardzo prawdopodobne dla mnie, który nie zna żadnego Lisp. Podałbym ten sam powód, dla którego C / Java jest lepsza niż Python dla rozwiązań korporacyjnych.
Jonas Byström
Jest to jedyna jak dotąd odpowiedź, która podniosła ogromny temat funkcjonalny vs. proceduralny, ale nie zapominajmy, że myślenie proceduralne ma tendencję do lubowania majstrowania przy globusach danych w różnych miejscach, w których można dotykać z wielu miejsc i wątków, powodując problemy z synchronizacją. Funkcjonalność nie cierpi z tego powodu tak szybko, dobrze napisana funkcjonalność wcale nie cierpi.
maxpolk
1
Pewien programista zapytał mnie kiedyś, jaki jest najlepszy sposób wyrażenia pętli for za pomocą diagramu przepływu danych. Dla takich ludzi nie ma sensu stosowanie języków nieprocesowych. Think w FORTRAN.
Nick Keighley,
5

Myślę, że jednym z problemów z Lispiem, o którym jeszcze nie wspomniano, jest to, że dla przeciętnego lub początkującego programisty (jak ja, przyznaję swobodnie), może być trudno zobaczyć, jak przekształcasz kod Lisp w duży program. Jest łatwy do napisania, ale trudny do zaprojektowania. Nie sądzę, by którekolwiek z tych pojęć były szczególnie trudne, ale mentalność DIY jest tak silna, że ​​często czuję się niepewnie, od czego zacząć.

Korzystając z języka OOP, takiego jak Java lub C #, możesz użyć systemu typów, aby rozwinąć się w kierunku działającego modelu i zbudować go. W Lisp (lub Lua lub Javascript, jeśli o to chodzi) istnieje koncepcja, że ​​możesz wyjść i zrobić to w dowolny sposób. Jeśli chcesz OOP, po prostu stwórz swój własny system OOP! Z wyjątkiem tworzenia własnego OOP lub uczenia się cudzego, jest nową barierą dla języka, zanim dostaniesz użyteczne programy. Dodatkowo zawsze mam wrażenie, że OOP w Lisp lub Lua tak naprawdę nie istnieje, jakbym mógł to zignorować, gdybym naprawdę chciał, więc o co chodzi?

Krótko mówiąc, myślę, że programowanie w Lisp wymaga dużej dyscypliny i jest to bardzo trudne do zdobycia. Języki silnie typowane i języki OOP oferują rodzaj wbudowanej dyscypliny, dzięki czemu programiści mogą skoncentrować swoje ograniczone rezerwy na ukończeniu projektów zamiast na poprawianiu języka.

EDYCJA: Jako analogia, która mnie uderzyła, to tak, jakbyś potrzebował trochę pracy przy drewnie, a dwie osoby oferują ci swoje skrzynki na narzędzia. Narzędzia jednej osoby są w pewnym sensie niewygodne, ale w zasadzie wystarczy odrobinę wysiłku. Druga osoba ma duży pojemnik na części, ale obiecuje, że możesz połączyć te części, aby uzyskać najlepsze narzędzia, jakich kiedykolwiek używałeś, idealnie dopasowane do twojej przyczepności i najlepszej jakości. Musisz je najpierw zbudować.

CodexArcanum
źródło
2
Przynajmniej Common Lisp jest jawnie językiem OO: Common Lisp Object System jest częścią standardu.
Frank Shearar
To prawda, i jak rozumiem, jest bardzo potężny, ale wydaje mi się, że jest to dodatkowa cecha języka. To nie jest jak Java, w której musisz rozumieć obiekty od pierwszego dnia. Praktyczny Common Lisp nie dotyka CLOS aż do rozdziału 16. Mogę też być po prostu nastawiony na pisanie statyczne, chociaż nie lubię języków dynamicznie pisanych .
CodexArcanum
Lisp pozwala ci używać zamknięć (let-over-lambda) zamiast obiektów dla lekkiego OOP, ale uważam, że łatwo go uaktualnić, aby używać OOP przez CLOS.
aoeu256
2

Zastanawiałem się nad tym długo, a nawet poszedłem na konferencje Lisp, aby spróbować zrozumieć, czym jest ta „ciemna strona” Lisp, która powstrzymuje wszystkich przed przyjęciem tego.

Nie znalazłem kompletnej, przyzwoitej odpowiedzi.

Ignorancja może być przyczyną utraty popularności, ale bardziej mnie zastanawia to, że nawet ten, kto na pewno wie o Lisp (na przykład Google - pracuje dla nich Peter Norvig), nie korzysta z niej.

Jedyne częściowe wyjaśnienie, które wymyśliłem, to fakt, że większość świetnych pomysłów Lisp jest teraz powszechna, a jedynym naprawdę ważnym brakującym (niezwykle ważnym IMO) jest łatwość metaprogramowania.

Niestety nie widzę łatwego sposobu na adsorbowanie tej koncepcji w innych językach, ponieważ dobre metaprogramowanie wymaga homoikonicznego i regularnego języka (mówię o ogólnym metaprogramowaniu, a nie o durnej wersji opartej tylko na szablonie). Innymi słowy, w zasadzie wymaga podejścia Lisp do składni: kod to dane, a dane to kod. Pisanie kodu w języku bogatym w składnię, który manipuluje AST, jest trudniejsze, ponieważ musisz znać dwa języki: jak pisać kod i jak pisać AST. Jest to szczególnie trudne, jeśli twój AST jest stały, a także złożony i nieregularny z wieloma różnymi typami węzłów. Zamiast tego Lisp ma dość regularną (i rozszerzalną!) AST, a ty już normalnie kodujesz, pisząc bezpośrednio w AST.

Metaprogramowanie jest również z natury trudniejsze (a meta-metaprogramowanie jeszcze bardziej itd.), A większość programistów i menedżerów najwyraźniej woli po prostu odpowiedź „nikt nie będzie potrzebował”.

Szczególnie smuci mnie to, że „nowe” języki, takie jak goskończyły, wykorzystują tekstowe metaprogramowanie, gdy jest to potrzebne (generatory kodu zewnętrznego piszą pliki tekstowe) i „magię” (tzn. Kompilator może robić to, czego nie potrafią programiści).

Myślę, że rozwiązaniem problemu złożoności są potężne narzędzia i edukacja. Trend jest raczej tępymi narzędziami i udawanie, że problem nie występuje.

6502
źródło
+1 za „Myślę, że rozwiązaniem problemu złożoności są potężne narzędzia i edukacja”.
Giorgio
po 50 latach wymówka „ignorancja” jest dość cienka
Nick Keighley,
1
@NickKeighley: zależy. Nawet dzisiaj większość programistów naprawdę nic nie wie o Lisp (na przykład, kiedy słyszysz Lisp opisany jako język funkcjonalny). Nawet wśród tych, którzy „wiedzą” Lisp, prawie nikt nigdy nie widział pomysłu makro z wystarczającą szczegółowością (nie mówię o głupiej wersji schematu, ale pełnej mocy algorytmicznej z wygodą quasi-cytowania, gdy lepiej to pasuje).
6502
@ 6502: Choć IMO Lisp nie jest czysto funkcjonalna, obsługuje programowanie funkcjonalne znacznie lepiej niż wiele popularnych języków, takich jak C #, Java, C ++ i tak dalej. Dla wielu programistów FP oznacza od czasu do czasu używanie wyrażenia lambda: ci programiści nie przegapią Lisp, Clojure lub Haskell. Dodałbym więc: (1) Lisp całkiem dobrze wspiera FP i programiści funkcjonalni skorzystaliby z niego, ale (2) ignorancja na temat FP i jego zalet jest jednym z powodów, dla których Lisp nie jest używany częściej.
Giorgio,
1
@ 6502: Posiadanie list jako podstawowej struktury danych i zwykłe funkcje wysokiego rzędu na listach to także funkcja, której brakuje w Javascript. I, o ile pamiętam, JavaScript ma również wyrażenie / wyrażenie dualności. Zdecydowanie postawiłbym Lisp (Common Lisp) kilka kroków dalej w kierunku FP niż Javascript lub Python. Nie mam przez to na myśli, że Common Lisp jest językiem czysto funkcjonalnym, zgadzam się, że jest wieloparadygmatem, ale obsługuje FP znacznie lepiej niż inne języki wieloparadygmatu.
Giorgio
1

Wydaje się, że nawet CL nie ma bardzo dobrego wsparcia biblioteki. Przynajmniej według osób, które przeszły z Lisp na Python:

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

Osobiście znam jakiś Schemat i lubię się nim bawić, ale nie wyobrażam sobie wykonywania nietradycyjnego projektu w tym języku.

Nemanja Trifunovic
źródło
2
To już nie jest prawda. Quicklisp rozwiązał ten problem.
2
Warto również wspomnieć, że w CFFI można używać dowolnej biblioteki C z Common Lisp. CFFI jest dobrze udokumentowany i działa dobrze. Z drugiej strony, jeśli spędzanie kilku godzin na pisaniu opakowań dla funkcji C ma duży wpływ na twój projekt, Lisp prawdopodobnie nie jest właściwym wyborem.
Larry Coleman
Zrobiłem nietrywialny projekt w Scheme i znam firmę, która używa Scheme (Schemat kurczaka) dla kilku produktów.
Giorgio,
1

Bycie potężnym niekoniecznie oznacza powszechne użycie. Czy słyszałeś o wyrażeniu „Optymalizuj w typowym przypadku”? Niestety, jak już wielu mówiło przed przeciętnością, czy konsekwentne zapewnienie jest o wiele lepsze dla ludzi niż wielkie hity z wieloma niepowodzeniami między nimi.

Nie dotyczy to tylko seplenia, ale wielu technologii. Dobry kontakt z uniksowymi narzędziami do przetwarzania tekstu, awk, sed, perl, pozwala zaoszczędzić dni programowania. Niestety widziałem, jak ludzie źle wykonują tego rodzaju zadania przy użyciu innych narzędzi, co można było zrobić za pomocą tych narzędzi w ciągu kilku minut. Ale jeśli ktoś spędza całe swoje życie w zaćmieniu, nigdy nie doceni wartości tych rzeczy. Możesz napisać olbrzymi program z czytelnością i łatwością obsługi, i tym podobne, ale o co chodzi z pisaniem takiego programu bez pisania, to z łatwością wykonałoby to zadanie.

Kolejnym aspektem podczas projektowania narzędzi w dzisiejszych czasach jest to, jak przydatne są po wyjęciu z pudełka, aby użyć ich bezpośrednio do rozwiązania problemu. Nie możesz zbudować czegoś zbyt ogólnego, a następnie powiedzieć, że zabezpieczysz to wszystko za pomocą bibliotek i frameworków. To trochę trudne do rozwiązania w ten sposób. Dobre narzędzie dobrze komponuje się ze środowiskiem i otaczającym go problemem. Dlatego narzędzia takie jak php, perl i awk pozostają aktualne pomimo niekończących się trollingu i bashowania, ponieważ są zbyt przydatne, aby je wyrzucić i często wykonują dużo pracy niż ogólny język z wieloma bibliotekami i frameworkami.

Podobnie zobaczysz, że języki takie jak Java / Python są bardzo dobre i powiedziałbym, że najlepiej dla niektórych zadań. Szczególnie Python jest bardzo dobry i łatwy do nauki i pisania. Również te języki są naprawdę dobre, jeśli punkty końcowe danych są standardowe. Jakaś baza danych lub XML lub dane tego rodzaju. Zasadniczo ustrukturyzowane dane.

Lisp będzie tam przez długi czas, ale niekoniecznie rozpowszechniony. Jak zobaczysz, każde narzędzie ma swoją niszę. I bardzo dobrze rozwiązują niektóre problemy po wyjęciu z pudełka. Myślę i jestem pewien, że seplenienie radzi sobie dobrze w obszarach i problemach, dla których jest dobrze rozwiązywany.

kamaal
źródło
+1 za powołanie się na zasadę „Optymalizuj w typowym przypadku”.
Giorgio,
Tak, ale Zamknięcia LISP są optymalizacją dla typowego przypadku Obiektów. Zastanawiałem się także, czy ktokolwiek wprowadza zmiany w bazie kodu LISP, traktując je jak drzewo i uruchamiając na nim zapytania jak JQuery dla HTML.
aoeu256
1

W przypadku tworzenia stron internetowych za pomocą dialektów Lisp może wystąpić problem z kurczakiem i jajami - ponieważ niewiele osób używa Lisp, gospodarze albo nie pozwalają, albo nie ułatwiają, a ponieważ nie jest to łatwe, niewiele osób Użyj tego. Ale w rzeczywistości uruchomienie Lisp na hoście może być łatwiejsze niż myślisz, nawet jeśli wymaga nieco więcej pracy niż ich gotowa usługa PHP. Niedawno dostał Guile aplikacje Schemat działania tutaj tylko z niewielkim wysiłku.

gcbenison
źródło
0

IMO to głównie kwestia nieodpowiedniego wyczucia czasu: Lisp był stary (i prawie z definicji nie był już ekscytujący) na długo, zanim stał się praktyczny dla większości ludzi lub zastosowań. Clojure (na przykład) ma znacznie większą szansę. Jego sukces będzie zależał bardziej od postrzegania go jako nowego, modnego i fajnego niż cokolwiek tak praktycznego jak współpraca z Javą (i wszystkim innym, co działa na JVM).

Jerry Coffin
źródło