Perché Lisp non è più diffuso? [chiuso]

Sto iniziando a imparare Scheme dai video SICP e vorrei passare al Common Lisp successivo.

La lingua sembra molto interessante e la maggior parte delle persone che scrivono libri su di essa sostengono che abbia un potere espressivo senza pari. CL sembra avere una libreria standard decente.

Perché Lisp non è più diffuso? Se è davvero così potente, le persone dovrebbero usarlo dappertutto, ma invece è quasi impossibile trovare, ad esempio, annunci di lavoro Lisp.

Spero non sia solo la parentesi, in quanto dopo poco non sono un grosso problema.

L'espressività non è sempre un tratto linguistico positivo in un ambiente aziendale. Java è estremamente popolare in parte perché è facile da imparare, facile da scrivere e facile da leggere. I programmatori mediocri possono ancora essere molto produttivi in ​​Java, anche se il loro codice è prolisso e inelegante.

Inoltre, è facile abusare di linguaggi espressivi. Un esperto programmatore Java può refactificare rapidamente il codice scritto male. Più la lingua è espressiva, più difficile diventa la comprensione e il refactoring del codice orribile. Le macro LISP sono un buon esempio. Le macro sono strumenti potenti nelle mani giuste. Nelle mani sbagliate, possono risultare in codice confuso e difficile da eseguire il debug.

LISP è una scelta rischiosa per il senior management. Se le cose vanno male, nessuno incolperà la gestione per aver scelto un linguaggio popolare orientato agli oggetti supportato da una grande azienda come Oracle o Microsoft. È molto più facile assumere programmatori con esperienza in lingue popolari e facili da imparare.

Anche le aziende progressiste che desiderano usare un linguaggio più potente di solito non scelgono LISP. Questo perché molte delle lingue più recenti cercano di scendere a compromessi prendendo in prestito potenti funzionalità da LISP, restando facili da imparare per le masse. Scala e Ruby seguono questo modello. I cattivi programmatori possono prenderli rapidamente e continuare a scrivere lo stesso codice mediocre che hanno fatto in Java. I bravi programmatori possono sfruttare le funzionalità più avanzate per scrivere codice stupendo.

Le parentesi non sono il problema. Haskell è un linguaggio incredibilmente potente ed espressivo con una sintassi simile a Python o Ruby e non è stato ampiamente adottato per molte delle stesse ragioni di LISP.

Nonostante tutto, spero ...

Clojure ha la possibilità di diventare popolare. Funziona su JVM, ha un'ottima interoperabilità con Java e semplifica la programmazione simultanea. Queste sono tutte cose importanti per molte aziende.

* Questa è la mia prospettiva di programmatore JVM professionista con esperienza in Java, Clojure, JRuby e Scala.

Perché Lisp non è più diffuso? Se è davvero così potente, le persone dovrebbero usarlo ovunque,

Se ritieni che le lingue siano state scelte per i loro meriti tecnici, ti aspetta una delusione straziante.

Tali decisioni vengono prese sulla base di Strippers And Steaks . Microsoft può permetterseli. Oracle può. Sun ha speso così tanti soldi per ipnotizzare Java che sono falliti. Due volte. Una comunità di volontari decentralizzata, eterogenea, non può competere con questo.

ma invece è quasi impossibile trovare, ad esempio, annunci di lavoro Lisp.

Stranamente, le società Lisp dicono esattamente il contrario: hanno costantemente opportunità di lavoro ma non riescono a trovare abbastanza persone per riempirle. (Lo stesso vale per Haskell, ML, O'Caml, Forth, Smalltalk, ...)

Non ho esperienza di lavoro in un'azienda reale, ma so perché LISP è stato difficile da usare per me.

Prima di tutto, questo mi ricorda questo post sul blog: http://steve-yegge.blogspot.com/2006/04/lisp-is-not-acceptable-lisp.html

Il problema principale che ho con Lisp è la domanda "che Lisp". Di solito lavoro su Linux come piattaforma principale, ma le cose che faccio devono essere compatibili con Windows. Ciò significa che quando sto valutando una tecnologia da utilizzare, deve semplificarmi la vita quando lavoro su due sistemi operativi radicalmente diversi. Non mi piace questo requisito, ma usarlo su un vero progetto è un requisito. Ora userò lingue che non hanno un ottimo supporto su Windows per i miei progetti secondari personali, ma poiché non ho mai la possibilità di scrivere un grande progetto software in loro, non ho l'esperienza necessaria.

Ora, quando stavo cercando di imparare un linguaggio funzionale, volevo davvero imparare Common Lisp. Sembrava la cosa giusta da fare. Ho iniziato a leggere Practical Common Lisp come punto di partenza poiché non conoscevo le funzioni integrate e avevo bisogno di un progetto su cui lavorare in Lisp. Le espressioni S erano belle e facili. Tutte quelle parentesi sono state incredibilmente belle per me, dato che era chiaro esattamente cosa stava succedendo nel codice.

Quindi provo a scrivere il mio primo programma in Lisp al di fuori del libro. Volevo uno strumento da riga di comando che contasse le righe di codice e rimuovesse le righe banali dal conteggio del codice. Non lo strumento più utile, ma divertente da fare. Implica l'accesso ai file, un po 'di analisi e il conteggio. Avevo implementato lo stesso strumento in Python circa una settimana prima.

Devo accedere agli argomenti della riga di comando. Quindi ho imparato che non esiste un modo standard per ottenere argomenti da riga di comando. Sono tutte caratteristiche non standard. Non è affatto multipiattaforma. Per lo più peggiora da lì in quanto il linguaggio non ha molte librerie integrate. Ho finito per passare a Haskell e non sono andato molto lontano in Common Lisp (quindi le mie lamentele potrebbero non essere nemmeno valide).

Questo tipo di cose non standard è sempre stato un dolore per me in passato. Il C ++ ha lo stesso problema, ma con librerie come Boost puoi ovviare a questi punti deboli.

Inoltre, non aiuta che la sintassi di Lisp per tutto tranne che per le espressioni S sia un po 'brutta.

IMO, è principalmente dovuto a:

• Supporto per librerie scadente. Certo, c'è Quicklisp ora, che semplifica l'installazione delle librerie, ma non compensa il fatto che siano ancora abbastanza poche, e parecchie sono scarsamente documentate o non molto ben tenute. Rispetto a Python, ci sono buone probabilità che scrivere un'applicazione Lisp non banale (indipendentemente dal dialetto particolare) probabilmente implicherà comunque il reinventare almeno parte di una o due ruote.
• Mancanza di familiarità con il modello adottato dagli strumenti di sviluppo. La maggior parte delle persone che conosco sono piuttosto intimidite dal dover usare SLIME ed Emacs, il che è comprensibile per le persone abituate a Eclipse e Visual Studio. Ci sono due plugin di Eclipse, penso, ne ho provato uno solo pochi anni fa ed è stato piuttosto difettoso. L'intero ecosistema di Lisp sembra essere bloccato a metà strada tra i giorni in cui faceva parte di un sistema in esecuzione Lisp a tutti gli effetti e il moderno standard di oh-è-un'altra lingua. L'apprendimento di Lisp non si limita all'apprendimento di una nuova lingua: devi anche imparare un modo completamente diverso di lavorare e pensare, e mentre questo va bene se lo fai come hobby, è discutibile se valga la pena farlo in un attività commerciale.

Le cose stanno iniziando a sembrare leggermente migliori, specialmente con Clojure.

Ho imparato LISP un miliardo di anni fa al college.

LISP, come FORTH, è ottimo per la logica. Ma la maggior parte della programmazione non riguarda la logica, si tratta di manipolare i dati in modi meccanici noiosi. Ad esempio, al momento non esiste un modo per giustificare a destra l'output numerico.

LISP riguarda la funzionalità nidificata e le persone semplicemente non la pensano in questo modo. Pensano in termini di DO A, B, C, D, quindi E. Non fare A, che implica fare B e C, quindi D ed E. Questo comporta un tipo di concorrenza che è confusa. Ad eccezione di attività predefinite come "presentare una dichiarazione dei redditi", le persone non pensano contemporaneamente, ma pensano in sequenza. Ecco perché oggi le lingue procedurali sono dominanti.

Di conseguenza, il codice del prodotto come Java e C può essere tradotto facilmente in inglese. Il codice LISP non può; nessun linguaggio umano è strutturato in questo modo.

Quindi è ottimo per la risoluzione dei problemi, ma la risoluzione dei problemi non è molto importante nella programmazione. Immissione dei dati, validazione, formattazione dell'output, in cui LISP era terribilmente debole.

Penso che un problema con Lisp non ancora menzionato sia che per un programmatore mediocre o alle prime armi (come me, lo ammetto liberamente), può essere difficile vedere come si trasforma il codice Lisp in un grande programma. È facile da scrivere ma difficile da progettare. Non credo che nessuno dei concetti sia particolarmente difficile, ma la mentalità fai-da-te è così forte che spesso mi sento in perdita da dove cominciare.

Con un linguaggio OOP come Java o C #, puoi usare il sistema dei tipi per spingerti verso un modello funzionante e costruirlo. Con Lisp (o Lua, o Javascript, per quella materia) c'è questa idea che puoi uscire e farlo come vuoi. Se vuoi OOP, crea il tuo sistema OOP! Tranne creare il tuo OOP o imparare qualcun altro, è una nuova barriera in cima alla lingua prima di ottenere programmi utilizzabili. Inoltre mi sento sempre come se l'OOP in Lisp o Lua non fosse davvero lì, come se potessi davvero ignorarlo, se lo volessi davvero, quindi che senso ha?

In breve, penso che la programmazione in Lisp richieda molta disciplina, ed è molto difficile da trovare. Le lingue fortemente tipizzate e le lingue OOP offrono entrambe una sorta di disciplina integrata, quindi il programmatore può concentrare le proprie riserve limitate sul completamento dei progetti invece di modificare la lingua.

EDIT: Come un'analogia che mi ha appena colpito, è come se avessi bisogno di fare un po 'di lavoro in legno e due persone ti offrano le loro cassette degli attrezzi. Gli strumenti di una persona sono piuttosto scadenti, ma sostanzialmente farebbero il lavoro con un po 'di sforzo. L'altra persona ha una grande quantità di pezzi, ma è promettente che puoi combinarli per creare i migliori strumenti che tu abbia mai usato, perfettamente adatti alla tua presa e della migliore qualità. Devi solo costruirli prima.

Mi chiedo lo stesso da molto tempo e sono persino andato alle conferenze di Lisp per cercare di capire cos'è questo "lato oscuro" di Lisp che impedisce a tutti di adottarlo.

Non ho trovato una risposta decente completa.

L'ignoranza può essere la ragione della popolarità mancante, ma ciò che mi confonde di più è che anche chi sicuramente conosce Lisp (ad esempio Google - Peter Norvig lavora per loro) non lo sta usando.

L'unica spiegazione parziale che mi viene in mente è che la maggior parte delle grandi idee di Lisp sono ormai all'ordine del giorno, l'unica che manca davvero importante (una IMO estremamente importante) è la facilità di metaprogrammazione.

Sfortunatamente non vedo un modo semplice di assorbire questo concetto per altre lingue perché la metaprogrammazione per essere carina richiede un linguaggio omoiconico e regolare (sto parlando di metaprogrammazione generale, non della versione solo stupida del modello). In altre parole, richiede fondamentalmente l'approccio Lisp alla sintassi: il codice è dato e i dati sono codice. Scrivere codice in un linguaggio ricco di sintassi che manipola un AST è più difficile perché è necessario conoscere due lingue: come scrivere il codice e come scrivere l'AST. Ciò è particolarmente difficile se il tuo AST è fisso e anche complesso e irregolare con molti tipi di nodi diversi. Lisp invece ha un AST ragionevolmente regolare (ed estensibile!) E già normalmente codice scrivendo direttamente l'AST.

La metaprogrammazione è anche intrinsecamente più difficile (e la meta-metaprogrammazione ancora di più e così via) e la maggior parte dei programmatori e manager apparentemente preferisce semplicemente la risposta "nessuno avrebbe bisogno di quella".

Trovo particolarmente triste il fatto che "nuovi" linguaggi come goquello abbiano finito per usare la metaprogrammazione testuale quando è necessario (generatori di codice esterni che scrivono file di testo) e "magia" (cioè il compilatore può fare ciò che i programmatori non possono fare).

Penso che la soluzione al problema della complessità siano strumenti ed educazione potenti. La tendenza è apparentemente invece strumenti smussati e fingendo che il problema non sia presente.

Sembra che anche CL non abbia un ottimo supporto per le librerie. Almeno secondo le persone che sono passate da Lisp a Python:

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

Personalmente, conosco qualche Schema e mi diverto a giocarci, ma non riesco a immaginare di fare un progetto non banale in quella lingua.

Essere potenti non implica necessariamente un uso diffuso. Hai mai sentito parlare del termine "Ottimizza per il caso comune"? Sfortunatamente, come molti hanno detto prima della mediocrità, se assicurato costantemente è molto meglio per le persone rispetto ai grandi successi con molti fallimenti tra di loro.

Questo non è solo il caso di lisp, ma con molte tecnologie. Un buon tocco sugli strumenti di elaborazione del testo Unix, awk, sed, perl può farti risparmiare giorni di programmazione. Sfortunatamente ho visto persone impiegare giorni a svolgere questo tipo di attività con altri strumenti, cosa che avrebbe potuto fare con questi strumenti in modo più efficiente in pochi minuti. Ma se si trascorre tutta la vita in eclissi, non verrà mai ad apprezzare il valore di queste cose. Puoi scrivere un programma enorme con leggibilità e manutenibilità e tutto il resto, ma qual è il punto centrale di scrivere un programma del genere senza scriverlo, avrebbe potuto facilmente fare il lavoro.

Un altro aspetto durante la progettazione di strumenti in questi giorni quanto sono utili pronti all'uso per usarli direttamente per risolvere un problema. Non puoi costruire qualcosa di troppo generico e poi dire che lo coprirai attraverso librerie e framework. È un po 'difficile risolvere le cose in questo modo. Un buon strumento si adatta bene all'ambiente e ai problemi che lo circondano. Ecco perché strumenti come php, perl e awk continuano a rimanere rilevanti nonostante trolling e bashing infiniti, perché sono troppo utili per buttarli via e spesso fanno molto lavoro di un linguaggio generale con molte librerie e framework imbullonati.

Allo stesso modo vedrai che lingue come Java / Python sono molto buone e direi meglio per certe attività. Python in particolare è molto buono e facile da imparare e scrivere. Anche queste lingue funzionano davvero bene se gli endpoint dei dati sono standard. Una sorta di database o XML o dati di quel tipo. Dati sostanzialmente strutturati.

Lisp sarà lì a lungo, ma non necessariamente molto diffuso. Come vedrai, ogni strumento ha la sua nicchia. E risolvono alcuni problemi molto bene fuori dalla scatola. Penso e sono sicuro che lisp stia andando bene in aree e problemi per i quali è progettato per risolversi bene.

Per lo sviluppo web con i dialetti di Lisp, può esserci un po 'di problema a base di gallina e uovo - poiché poche persone usano Lisp, gli host o non lo consentono o non lo rendono facile, e poiché non è facile, poche persone usalo. Ma in realtà, far funzionare Lisp su un host può essere più semplice di quanto si possa pensare, anche se richiede un po 'più di lavoro rispetto al loro servizio PHP predefinito. Recentemente ho avuto l'astuzia Scheme apps lavorare qui con solo un piccolo sforzo.

IMO, è soprattutto una questione di scadenze scadenti: Lisp era vecchio (e quasi per definizione non più eccitante) molto prima che diventasse pratico per la maggior parte delle persone o degli usi. Clojure (per un esempio) ha molte più possibilità. Il suo successo dipenderà molto di più dall'essere percepito come nuovo, alla moda e alla moda di qualsiasi cosa pratica come l'interoperabilità con Java (e tutto il resto che gira su JVM).