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

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.

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.

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, ...)

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.

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.

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.

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ć.

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.

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.

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.

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.

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).