it-swarm-eu.dev

Proč není LISP rozšířenější?

Začínám se učit Scheme pomocí videí SICP a ráda bych se přesunula dále do Common LISP.

Jazyk se zdá být velmi zajímavý a většina lidí o něm píše knihy obhajuje, že má nepřekonatelnou expresivní sílu. Zdá se, že CL má slušnou standardní knihovnu.

Proč není LISP rozšířenější? Pokud je to opravdu mocné, měli by ho lidé používat všude, ale místo toho je téměř nemožné najít, řekněme, reklamy na LISP.

Doufám, že to není jen závorka, protože po chvilce to není velký problém.

50
Andrea

Expresivita není vždy pozitivním znakem jazyka v podnikovém prostředí. Java je nesmírně populární částečně proto, že se snadno učí, snadno zapisuje a snadno čte. Střední programátoři mohou být v Javě stále velmi produktivní, i když jejich kód je hloupý a nevhodný.

Navíc je snadné zneužívat expresivní jazyky. Odborník Java Programátor dokáže rychle refaktorovat špatně napsaný kód. Čím výraznější je jazyk, tím obtížnější je pochopení a refactoring hrozného kódu. Makra LISP jsou dobrým příkladem. Makra jsou mocné nástroje vpravo Ve špatných rukou mohou mít za následek matoucí a obtížně ladící kód.

LISP je riskantní volba pro vrcholový management. Pokud se něco pokazí, nikdo nebude obviňovat vedení za výběr populárního objektově orientovaného jazyka za podpory velké společnosti jako Oracle nebo Microsoft. Je mnohem snazší najmout programátory se zkušenostmi v populárních, snadno naučitelných jazycích.

I progresivní společnosti ochotné používat silnější jazyk obvykle LISP nevybírají. Důvodem je to, že mnoho novějších jazyků se snaží a kompromituje půjčováním výkonných funkcí od LISP, přičemž se masy snadno naučí. Scala a Ruby následovat tento model. Špatní programátoři je mohou rychle vyzvednout a nadále psát stejný průměrný kód, jaký používali v Javě. Dobří programátoři mohou využít pokročilejších funkcí psát krásný kód.

Závorky nejsou problém. Haskell je neuvěřitelně výkonný a expresivní jazyk se syntaxí podobnou Python nebo Ruby a nemá hash) nebyly široce přijaty z mnoha stejných důvodů jako LISP.

Přes to všechno doufám ...

Clojure má šanci stát se populární. Běží na JVM, má skvělý interop s Javou a zjednodušuje současné programování. To vše jsou důležité pro mnoho společností.

* Toto je můj pohled jako profesionální programátor JVM se zkušenostmi s Java, Clojure, JRuby a Scala.

70
dbyrne

Proč není LISP rozšířenější? Pokud je to opravdu mocné, měli by to lidé používat všude,

Pokud se domníváte, že jazyky jsou vybírány pro své technické přednosti, jste pro zklamané zklamání.

Taková rozhodnutí jsou učiněna na základě Strippers And Steaks . Microsoft si je může dovolit. Oracle může. Sun utratil tolik peněz hyping Java, že zkrachoval.) Dvakrát. Decentralizovaná, heterogenní dobrovolnická komunita s tím nemůže konkurovat.

ale místo toho je téměř nemožné najít, řekněme, reklamy na LISP.

Je smutné, že společnosti LISP říkají pravý opak: neustále mají pracovní příležitosti, ale nemohou najít dost lidí, aby je naplnily. (Totéž platí pro Haskell, ML, O'Caml, Forth, Smalltalk, ...)

17
Jörg W Mittag

Nemám žádné zkušenosti s prací pro skutečnou společnost, ale vím, proč je pro LISP těžké použít.

Nejprve mi to připomíná tento blogový příspěvek: http://steve-yegge.blogspot.com/2006/04/LISP-is-not-acceptable-LISP.html

Hlavním problémem, který mám s LISP, je otázka „který LISP“. Obvykle pracuji na Linuxu jako na mé hlavní platformě, ale věci, které dělám, musí být kompatibilní s Windows. To znamená, že když hodnotím technologii, kterou mám použít, musí mi to usnadnit život, když pracuji na dvou radikálně odlišných operačních systémech. Tento požadavek se mi nelíbí, ale použít ho na skutečný projekt, který je požadavek. Nyní budu používat jazyky, které nemají velmi dobrou podporu pro Windows, pro své vlastní osobní vedlejší projekty, ale protože jsem nikdy nedostal šanci napsat velký softwarový projekt v nich, nemám potřebné zkušenosti.

Teď, když jsem se snažil naučit funkční jazyk, opravdu jsem se chtěl naučit Common LISP. Vypadalo to jako správná věc. Začal jsem číst Praktický Common LISP jako skokový bod, protože jsem opravdu neznal vestavěné funkce a potřeboval projekt, na kterém bych pracoval v LISP. S-výrazy byly krásné a snadné. Všechny tyto závorky byly pro mě neuvěřitelně krásné, protože bylo jasné, jak přesně se den děje v kódu.

Snažím se napsat svůj první program v LISP mimo knihu. Chtěl jsem nástroj příkazového řádku, který by počítal řádky kódu a odstranil triviální řádky z počtu kódů. Není to nejužitečnější nástroj, ale zábava. Zahrnuje přístup k souborům, trochu analýzy a počítání. Stejný nástroj jsem implementoval v Python asi před týdnem).

Potřebuji přístup k argumentům příkazového řádku. Pak se dozvím, že neexistuje žádný standardní způsob, jak získat argumenty příkazového řádku. Všechny jsou nestandardními funkcemi. Není to napříč platformou vůbec. Většinou se to jen zhoršuje, protože jazyk nemá v sobě mnoho knihoven. Nakonec jsem přešel na Haskell a nedostal jsem se příliš daleko do Common LISP (takže mé stížnosti nemusí být platné).

Tato nestandardní věc byla pro mě vždycky bolestí. C++ má stejný problém, ale s knihovnami jako Boost můžete tyto slabiny obejít.

Také to nepomůže, že syntaxe LISP pro všechno jiné než S-výrazy je trochu ošklivá.

9
jsternberg

IMO, je to hlavně kvůli:

  • Špatná podpora knihovny. Jistě, nyní existuje Quicklisp, což usnadňuje instalaci knihoven, ale nenahrazuje to, že jsou stále poměrně málo, a několik z nich je špatně zdokumentováno nebo není dobře udržováno. Ve srovnání s Pythonem existuje velká šance, že psaní netriviální aplikace LISP (bez ohledu na konkrétní dialekt) bude pravděpodobně stále zahrnovat znovuobjevení alespoň části kola nebo dvou.
  • Nedostatek znalosti modelu přijatého vývojovými nástroji. Většina lidí, které znám, je docela zastrašena nutností používat SLIME a Emacs, což je pochopitelné pro lidi, kteří byli zvyklí na Eclipse a Visual Studio. Myslím, že existují dva pluginy Eclipse, zkusil jsem jen jeden z nich před několika lety a bylo to docela buggy. Celý ekosystém LISP vypadá, jako by uvízl na půli cesty mezi dny, kdy byl součástí plnohodnotného systému LISP a moderního standardu oh-it-other-language. Výuka LISP se neomezuje pouze na učení nového jazyka - musíte se také naučit úplně odlišný způsob práce a myšlení, a přestože je to v pořádku, pokud to děláte jako koníček, je otázné, zda stojí za to to udělat v podnikání.

Věci však začínají vypadat trochu lépe, zvláště když je kolem Clojure.

8
donkey_lz

LISP jsem se naučil před miliardou let na vysoké škole.

LISP, stejně jako FORTH, je skvělý pro logiku. Ale většina programování není o logice, jde o manipulaci s daty nudnými mechanickými způsoby. Například v té době neexistuje způsob, jak správně zarovnat číselný výstup.

LISP je o vnořených funkcích a lidé si to prostě nemyslí. Přemýšlejí, co se týče DO A, B, C, D, pak E. Not Do A, což znamená dělat B a C, pak D a E. Tohle zahrnuje určitý druh souběžnosti, která je matoucí. S výjimkou předdefinovaných úkolů, jako je „podání daňového přiznání k dani z příjmu“, si lidé nemyslí souběžně, myslí si postupně. Proto jsou dnes procedurální jazyky dominantní.

Výsledkem je, že produrální kód má rád Java a C lze snadno přeložit do angličtiny. Kód LISP nemůže, žádný lidský jazyk není takto strukturován).

Je to skvělé pro řešení problémů, ale řešení problémů není v programování příliš důležité. Zadávání dat, ověřování, formátování výstupu, ve kterém byl LISP strašně slabý.

5
Andy Canfield

Myslím, že jeden problém s LISP, který ještě není zmíněn, je, že pro průměrného nebo začínajícího programátora (jako jsem já, volně přiznávám), může být obtížné pochopit, jak z LISP kódu uděláte velký program. Je snadné psát, ale těžko architekt. Nemyslím si, že žádný z konceptů je obzvláště obtížný, ale mentalita pro kutily je tak silná, že často cítím ztrátu, kde začít.

S OOP jako Java nebo C #) můžete použít typový systém k posílení sebe směrem k pracovnímu modelu a odcizit to. S LISP (nebo Lua, nebo Javascript, na to přijde) je tu představa, že můžete jít ven a udělat to, jak chcete. Pokud chcete OOP, vytvořte si svůj vlastní systém OOP!) Kromě vytváření vlastního OOP, nebo učení někoho jiného, ​​je novou bariérou v horní části jazyka, než se dostanete k použitelným programům. Navíc se vždycky cítím jako OOP v LISP nebo Lua tam opravdu není, jako já mohl bych to ignorovat, kdybych opravdu chtěl, tak o co jde?

Stručně řečeno, myslím si, že programování v LISP vyžaduje hodně disciplíny, a to je velmi těžké přijít. Silně napsané jazyky a OOP jazyky oba nabízejí jakousi vestavěnou disciplínu), takže programátor může zaměřit své omezené rezervy na dokončení projektů namísto vyladění jazyka.

EDIT: Jako analogie, která mě právě zasáhla, je to, jako kdybyste potřebovali udělat nějaké práce se dřevem a dva vám nabízejí své sady nástrojů. Nástroje jedné osoby jsou trochu drsné, ale v zásadě by to provedly s trochou úsilí. Druhá osoba má velkou část dílů, ale slibuje, že tyto části můžete kombinovat, abyste vytvořili ty nejlepší nástroje, které jste kdy použili, dokonale přizpůsobené vaší přilnavosti a té nejvyšší kvalitě. Musíte je nejprve postavit.

5
CodexArcanum

Dlouho jsem přemýšlel o tom samém a dokonce jsem šel na konference LISP, abych se pokusil pochopit, co je to „temná stránka“ LISP, která brání každému v přijetí.

Nenašel jsem žádnou úplnou slušnou odpověď.

Neznalost může být příčinou chybějící popularity, ale to, co mě více hádá, je to, že i ten, kdo ví o LISP (například Google - Peter Norvig pro ně pracuje) jej nepoužívá.

Jediné částečné vysvětlení, které přijdu, je to, že většina skvělých nápadů LISP je nyní běžná, jediným opravdu důležitým chybějícím (nesmírně důležitým IMO) je snadnost metaprogramování.

Bohužel nevidím žádný snadný způsob, jak tuto koncepci adsorbovat do jiných jazyků, protože metaprogramování být Nice vyžaduje homoikonický a pravidelný jazyk (mluvím o obecném metaprogramování, nikoli o němé verzi pouze pro šablony). Jinými slovy to v podstatě vyžaduje přístup LISP k syntaxi: kód jsou data a data jsou kód. Psaní kódu v jazyce bohatém na syntaxi, který manipuluje s AST), je obtížnější, protože potřebujete znát dva jazyky: jak napsat kód a jak napsat AST. AST je pevná a také složitá a nepravidelná s mnoha různými typy uzlů. LISP místo toho má přiměřeně pravidelný (a rozšiřitelný!) AST) a ty již normálně kód přímo napsáním AST.

Metaprogramování je také ze své podstaty obtížnější (a meta-metaprogramování ještě více atd.) A většina programátorů a manažerů zřejmě prostě dává přednost odpovědi „nikdo by to nepotřeboval“.

Je mi obzvláště smutné, že „nové“ jazyky, jako je go, skončily v případě potřeby pomocí textového metaprogramování (generátory externích kódů psávající textové soubory) a „magické“ (tj. Kompilátor může dělat to, co programátoři nemohou dělat) .

Myslím, že řešením problému složitosti jsou mocné nástroje a vzdělání. Trend je zjevně místo toho tupé nástroje a předstírání problému není přítomno.

2
6502

Zdá se, že ani CL nemá velmi dobrou knihovní podporu. Alespoň podle lidí, kteří přešli z LISP na Python:

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

Osobně znám nějaký Schéma a rád si s ním hraji, ale neumím si představit, že v tomto jazyce provedeme netriviální projekt.

1

Být silný nemusí nutně znamenat široké použití. Slyšeli jste o termínu Optimalizace pro běžný případ? Bohužel, jak mnozí říkali před průměrností, je-li zajištěno důsledně, je pro lidi mnohem lepší než velké zásahy s mnoha selháními mezi nimi.

To není jen případ LISP, ale spousta technologií. Dobrý dotyk nad Unixovými nástroji pro zpracování textu, awk, sed, Perl vám může ušetřit dny programování. Bohužel jsem viděl, jak lidé berou dny dělat takové úkoly v jiných nástrojích špatně, co se s těmito nástroji mohlo udělat efektivněji během několika minut. Ale pokud jeden stráví celý svůj život v Eclipse, nikdy nepřijde ocenit hodnotu těchto věcí. Můžete napsat obrovský program se čitelností a udržovatelností, a to vše, ale co je vlastně celé psaní tohoto programu, aniž byste jej psali, by to mohlo snadno udělat.

Dalším aspektem při navrhování nástrojů v dnešní době je, jak moc užitečné je použít přímo k vyřešení problému. Nemůžete vytvořit něco příliš obecného a pak říci, že to vše zajistíte prostřednictvím knihoven a rámců. Je to trochu obtížné věci takhle vyřešit. Dobrý nástroj geluje dobře s prostředím a problémem kolem něj. To je důvod, proč nástroje jako php, Perl a awk zůstávají relevantní i přes nekonečné trollingy a fackování, protože jsou příliš užitečné na to, aby je vyhodily a často dělají spoustu práce než obecný jazyk s mnoha knihovnami a kostry připojenými.

Podobně uvidíte, že jazyky jako Java/Python jsou velmi dobré a pro některé úkoly bych řekl nejlépe. Python zvláště je velmi dobrý a snadno se učí a zapisuje. Také tyto jazyky jsou opravdu dobré, pokud jsou vaše koncové body dat standardní. Nějaká databáze nebo XML nebo data tohoto druhu. V podstatě strukturovaná data.

LISP tam bude po dlouhou dobu, ale ne nutně rozšířený. Jak uvidíte, každý nástroj má své místo. A některé problémy řeší velmi dobře. Myslím, že jsem si jist, že se LISP daří dobře v oblastech a problémech, pro které je navržen tak, aby dobře řešil.

1
kamaal

Pro vývoj webových stránek s dialekty LISP může být problém s kuřecím masem a vejcem - protože jen málo lidí používá LISP, hostitelé to buď neumožňují, nebo neumožňují, a protože to není snadné, málokdo použij to. Ale ve skutečnosti může být běh LISP na hostiteli jednodušší, než si možná myslíte, i když to vyžaduje trochu více práce než jejich out-of-the-box PHP služba ano. Nedávno jsem dostal guile Schéma aplikací pracujících zde s trochou úsilí.

1
gcbenison

IMO, je to většinou otázka špatného načasování: LISP byl starý (a téměř podle definice už ne vzrušující) dlouho předtím, než se stal praktickým pro většinu lidí nebo použití. Clojure (například) má mnohem lepší šanci. Jeho úspěch však bude mnohem více záviset na tom, že bude vnímán jako nový, módní a chladný než cokoli praktického, jako je spolupráce s Java (a vše ostatní, co běží na JVM)).

0
Jerry Coffin