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

L'espressività non è sempre un tratto di lingua 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 poco elegante.

Inoltre, è facile abusare di linguaggi espressivi. Un programmatore java esperto può refactoring codice mal scritto rapidamente. Quanto più espressivo è il linguaggio, tanto 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 causare codice confuso e difficile da 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 società come Oracle o Microsoft. È molto più semplice 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é molti dei linguaggi più recenti cercano e compromettono prendendo in prestito potenti funzionalità da LISP, pur rimanendo facili da imparare per le masse. Scala e Ruby seguono questo modello. I cattivi programmatori possono riprenderli 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 bello.

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

Clojure ha una possibilità di diventare popolare. Funziona sulla JVM, ha una grande interoperabilità con Java e rende la programmazione concorrente molto più semplice. Questi sono tutti cose importanti per molte aziende.

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

Why is not Lisp more widespread? If it is really that powerful, people should be using it all over,

Se credi che le lingue siano scelte per i loro meriti tecnici, ti verrà una delusione per l'anima.

Tali decisioni sono prese sulla base di Strippers And Steaks . Microsoft può permetterseli. Oracle può. Sun ha speso così tanti soldi per dire a Java che sono andati in bancarotta. Due volte. Una comunità di volontari decentralizzata ed eterogenea non può competere con quella.

but instead it is nearly impossible to find, say, Lisp job advertisements.

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

Non ho esperienza nel lavorare per una vera compagnia, ma so perché LISP è stato difficile da usare per me.

Prima di tutto, questo mi ricorda questo post del blog: link

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 progetto reale è un requisito. Ora utilizzerò linguaggi che non hanno un ottimo supporto su Windows per i miei progetti personali, ma poiché non ho mai avuto la possibilità di scrivere un grande progetto software, 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 un punto di partenza in quanto 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 erano incredibilmente belle per me perché era chiaro come giorno esattamente quello che stava accadendo 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 rimuova le linee 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. Poi imparo che non esiste un modo standard per ottenere argomenti dalla riga di comando. Sono tutte funzioni non standard. Non è affatto multipiattaforma. Di solito peggiora solo di lì dato che la lingua non ha molte librerie incorporate. Ho finito per passare a Haskell e non sono andato molto lontano in Common Lisp (quindi i miei reclami potrebbero non essere nemmeno validi).

Questo tipo di cosa non standard è sempre stato un dolore per me in passato. C ++ ha lo stesso problema, ma con le librerie come Boost puoi aggirare queste debolezze.

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

IMO, è principalmente dovuto a:

• Supporto scarso della libreria. Certo, ora c'è Quicklisp, che semplifica l'installazione delle librerie, ma non compensa il fatto che siano ancora poche, e alcune sono scarsamente documentate o poco curate. Rispetto a Python, ci sono buone probabilità che scrivere applicazioni Lisp non banali (a prescindere dal particolare dialetto) probabilmente implichino ancora la reinvenzione di almeno una parte di una ruota o due.
• Mancanza di familiarità con il modello adottato dagli strumenti di sviluppo. La maggior parte delle persone che conosco sono abbastanza intimidite dal dover usare SLIME ed Emacs, il che è comprensibile per le persone usate per Eclipse e Visual Studio. Ci sono due plugin di Eclipse, penso, ne ho provato uno solo alcuni anni fa ed era piuttosto buggato. L'intero ecosistema Lisp sembra essere rimasto a metà strada tra i giorni in cui faceva parte di un sistema Lisp a pieno regime e lo standard moderno di oh-it's-other-language. Learning Lisp non si limita all'apprendimento di una nuova lingua - devi anche imparare un modo completamente diverso di lavorare e pensare, e mentre questo è ok se lo fai come hobby, è discutibile se valga la pena farlo in un affari.

Le cose cominciano a sembrare leggermente migliori, specialmente con Clojure in giro.

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 alcun modo per giustificare a destra l'output numerico.

LISP parla di funzionalità nidificate e le persone semplicemente non la pensano così. Pensano in termini di DO A, B, C, D, quindi E. Non fanno A, che implica fare B e C, quindi D ed E. Questo implica un tipo di concorrenza che è fonte di confusione. Fatta eccezione per compiti predefiniti come "presentare una dichiarazione dei redditi", le persone non pensano in modo concorrente, pensano in modo sequenziale. Questo è il motivo per cui le lingue procedurali sono dominanti oggi.

Di conseguenza, i codici produttivi Java e C possono essere facilmente tradotti 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. Inserimento dati, convalida, formattazione dell'output, tutto ciò a cui LISP era terribilmente debole.

Penso che un problema con Lisp non ancora menzionato sia che per un programmatore mediocre o inesperto (come me stesso, 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 penso che nessuno dei concetti sia particolarmente difficile, ma la mentalità del fai-da-te è così strong che mi sento spesso in perdita da dove cominciare.

Con un linguaggio OOP come Java o C #, puoi usare il sistema dei tipi per potenziare te stesso verso un modello funzionante, e costruirlo. Con Lisp (o Lua, o Javascript, se è per questo) c'è questa nozione che puoi uscire e farlo nel modo che preferisci. Se vuoi OOP, crea il tuo sistema OOP! Tranne che creare il tuo OOP, o imparare qualcun altro, è una nuova barriera sulla lingua prima di ottenere programmi utilizzabili. Inoltre mi sento sempre come l'OOP in Lisp o Lua non è davvero lì, come se potessi semplicemente ignorarlo se volessi davvero, quindi qual è il punto?

In breve, penso che programmare in Lisp richieda molta disciplina, ed è molto difficile da trovare. I linguaggi strongmente tipizzati e le lingue OOP offrono entrambi una sorta di disciplina incorporata, quindi il programmatore può concentrare le proprie riserve limitate sulla finitura dei progetti invece di perfezionare 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 offrono le loro cassette degli attrezzi. Gli strumenti di una persona sono piuttosto scadenti, ma sostanzialmente finiscono il lavoro con un po 'di sforzo. L'altra persona ha un grande contenitore di parti, ma è promettente che tu possa combinare quelle parti per realizzare i migliori strumenti che tu abbia mai usato, perfettamente adatti alla tua presa e alla migliore qualità. Devi solo costruirli per primi.

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

link

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 sentito parlare del termine "Ottimizza per il caso comune"? Sfortunatamente come molti hanno detto prima della mediocrità, se assicurato in modo coerente è molto meglio per le persone rispetto ai grandi successi con molti fallimenti tra di loro.

Questo non è solo il caso del 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à in altri strumenti, cosa che avrebbe potuto fare con questi strumenti in modo più efficiente in pochi minuti. Ma se uno trascorre tutta la sua vita in un'eclissi non arriverà mai ad apprezzare il valore di queste cose. Potresti scrivere un programma enorme con leggibilità e manutenibilità e tutto il resto, ma a che punto è 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 utile fuori dalla scatola sono di utilizzarli direttamente per risolvere un problema. Non è possibile creare qualcosa di troppo generico e quindi affermare che si coprirà tutto ciò con librerie e framework. È un po 'difficile elaborare le cose in questo modo. Un buon strumento si fonde bene con l'ambiente e il problema intorno ad esso. Questo è il motivo per cui strumenti come php, perl e awk continuano a rimanere rilevanti nonostante l'interminabile troll e pestaggio, perché sono troppo utili per buttarli via e spesso fanno molto lavoro di una lingua generica con molte librerie e framework imbullonate.

Allo stesso modo vedrai che linguaggi come Java / Python sono molto buoni e direi migliori per certe attività. Specialmente Python è molto buono e facile da imparare e scrivere. Anche questi linguaggi funzionano molto bene se i tuoi endpoint di dati sono standard. Una sorta di database o XML o dati di quel tipo. Dati fondamentalmente strutturati.

Lisp sarà lì per molto tempo, ma non necessariamente diffuso. Come vedrai ogni strumento ha la sua nicchia. E risolvono alcuni problemi in modo immediato. Penso e sono sicuro che il lisp stia facendo bene in aree e problemi per i quali è stato progettato per risolvere bene.

Mi sono chiesto lo stesso a lungo, e sono persino andato alle conferenze 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 potrebbe essere la ragione della popolarità mancante, ma ciò che mi lascia perplesso è che anche chi di sicuro 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 Lisp sono ormai all'ordine del giorno, l'unica veramente importante mancante (una IMO estremamente importante) è la facilità di metaprogrammazione.

Sfortunatamente non vedo un modo semplice per 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 del solo modello dumbed-down). In altre parole, richiede fondamentalmente l'approccio Lisp alla sintassi: il codice è dato e il dato è 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. Questo è 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 normalmente si codifica direttamente scrivendo direttamente l'AST.

Metaprogramming è anche intrinsecamente più difficile (e meta-metaprogrammazione ancora di più e così via) e la maggior parte dei programmatori e manager a quanto pare preferiscono semplicemente la risposta "nessuno avrebbe bisogno di quella".

Trovo particolarmente triste il fatto che linguaggi "nuovi" come go finiscano per utilizzare metaprogrammazione basata su testo quando è necessario (generatori di codice esterni che scrivono file di testo) e "magico" (il compilatore può fare ciò che i programmatori non possono fare) .

Penso che la soluzione al problema della complessità siano strumenti potenti e istruzione. La tendenza sembra essere invece strumenti smussati e far finta che il problema non sia presente.

IMO, è soprattutto una questione di tempismo scadente: 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 una possibilità molto migliore. Il suo successo dipenderà molto di più dal fatto di essere percepito come nuovo, alla moda e interessante rispetto a qualsiasi cosa pratica come l'interoperabilità con Java (e con qualsiasi altra cosa che gira su JVM).

Per lo sviluppo web con i dialetti Lisp, ci può essere un po 'di problemi con la gallina e l'uovo - perché poche persone usano il Lisp, gli host non lo permettono o non lo rendono facile, e perché non è facile poche persone lo usano Ma in realtà, far funzionare Lisp su un host può essere più facile di quanto si possa pensare, anche se richiede un po 'più di lavoro rispetto al proprio servizio PHP fuori dal comune. Recentemente ho ricevuto guile app di Scheme che funzionano qui con un piccolo sforzo.