Useresti (un dialetto di) LISP per un'applicazione del mondo reale? Dove e perché? [chiuso]

Utilizzeresti un dialetto LISP per un programma di produzione?

Assolutamente

Che tipo di programma e perché?

Lisp è un linguaggio dinamico per scopi generici. Oggi presenta le stesse difficoltà di base di altri linguaggi dinamici generici che non sono pubblicati da Microsoft: thread nativi, integrazione della GUI, funzionamento deterministico del GC e impronte di memoria di piccole dimensioni.

I thread nativi sono realizzati da LispWorks e SBCL, credo. Forse altri? Non ho investigato completamente.

LispWorks e Franz Common Lisp - prodotti commerciali - integrano nella GUI gradi di successo. Non avendo i $$ per comprarli, non so quanto bene funzioni. Sospetto che funzionino abbastanza bene ...

Un'operazione GC deterministica può essere eseguita (è eseguita in Java ad un certo livello di successo), ma I non sa se i sistemi Lisp esistenti (quelli mantenuti) hanno un codice per farlo.

Il piccolo ingombro di memoria credo sia ottenuto da alcuni Lisps.

Il mio punto di partenza è che Common Lisp è tecnicamente pronto per realizzare sistemi di produzione. E fa .

La stragrande maggioranza degli sviluppatori viene fuori di testa da (sceglierne uno) lingue dinamiche, macro, parentesi, mancanza di IDE preferito, brutta esperienza al college, non molti lavori al suo interno, e quindi non usarlo.

Personalmente mi piacerebbe creare un sistema di produzione completo in Common Lisp partendo da zero in un ambiente di squadra.

modifica: non ho davvero risposto perché Lisp al contrario di altre lingue.

Nella mia esperienza Lisp - non significativa, ma considerevolmente più di "ciao mondo" - ho trovato il linguaggio estremamente fruibile dopo i primi dolori "Argh new language". La maggior parte della lingua si adatta in modo molto regolare e abbastanza ovvio che non trovo davvero altre lingue per funzionare come. Parte di questo è la fusione di espressioni e affermazioni. Parte di questo è il tipo di dati dell'elenco principale. Parte di questo è il sistema dei tipi. Parte di questo è il sistema macro. Non fraintendermi, però, ci sono sono punti di dolore. Ma non mi prendono a calci in faccia tanto quanto i punti deboli delle altre lingue.

Un esempio semplicistico è la routine di lunghezza di lista di Python. L'approccio Python consiste nel chiamare len(mysequence) . Ma, se ci pensiamo, una lunghezza è una proprietà di una sequenza. Quindi, mysequence.len() è un'idea più appropriata. Lisp essenzialmente rimuove quella distinzione sintattica. (length thing) è sia la sintassi della chiamata di funzione sia la sintassi del metodo. Certo, alcune persone lo trovano frustrante e vogliono la differenza sintattica. Preferirei avere la regolarità.

edit2: ho convertito la parte della mia tesi di laurea che viene eseguita sul desktop in Common Lisp ed è stato un piacere lavorare finora.

Conosco personalmente persone che usano Lisp sotto forma di Clojure in un paio di banche d'investimento e startup a Londra. Ho anche scelto Clojure come linguaggio di sviluppo principale per la mia startup, quindi sono disposto a mettere i miei soldi dove la mia bocca è: -)

Ho trovato un'esperienza molto illuminante per imparare Clojure nell'ultimo anno (dopo molte esperienze con Java e C #). I motivi principali di questo sono:

• Ha una strong enfasi sulla programmazione funzionale (più della maggior parte degli altri Lisps). L'autore e BDFL Rich Hickey ha spesso citato Haskell come una delle sue ispirazioni per il design del linguaggio, il che significa che ottieni cose come strutture di dati completamente immutabili e sequenze pigre infinite ecc.
• Macro metaprogramming - la filosofia del "codice è dati" Lisp è difficile da capire a meno che tu non l'abbia effettivamente sperimentata, ma è uno dei motivi per cui i Lisps sono così espressivi e produttivi. In pratica hai il potere di estendere la lingua in modo che corrisponda al tuo dominio problematico.
• Supporto fantastico per la concorrenza multi-core - In realtà penso che Clojure sia la migliore lingua per la programmazione simultanea in questo momento. Vedi link per una presentazione illuminante su questo
• Lo sviluppo interattivo presso REPL è un modo efficace e produttivo di creare applicazioni. Ti dà una vera sensazione di potere di modificare dinamicamente il codice dell'applicazione in esecuzione e ispezionare programmaticamente le strutture di dati in tempo reale .....

Sembra anche essere una scelta pratica per l'uso di produzione reale per i seguenti motivi:

• L'esecuzione sulla JVM con un'interoperabilità Java molto semplice ti dà accesso a tutte le librerie e gli strumenti nell'ecosistema Java
• Sei in esecuzione sulla JVM, una piattaforma testata per le applicazioni aziendali. Clojure beneficia di tutte le simpatiche funzionalità di JVM come l'eccellente compilation GC e JIT gratuitamente.
• È un linguaggio dinamico di default, il che lo rende molto conveniente per lo sviluppo e la prototipazione rapida con pochissima norma. Tuttavia puoi aggiungere suggerimenti di tipo statico per ottenere prestazioni piuttosto buone laddove ne hai bisogno.
• È una comunità pragmatica e utile - il tipo di cultura in cui le persone ottengono risultati e l'attenzione si concentra su soluzioni ben progettate che risolvono problemi reali
• È disponibile il supporto degli strumenti in IDE multipli . Personalmente uso Eclipse con il plugin Counterclockwise (perché ho bisogno dell'integrazione Java) ma ci sono molte altre opzioni.

Userei LISP se fosse la scelta migliore per il lavoro. Solo alcune cose che influenzano la "scelta migliore":

• supporto del fornitore. L'implementazione LISP che utilizziamo - se qualcosa va storto e interferisce con il nostro sviluppo e quindi le nostre scadenze, il venditore lavorerà per una soluzione con noi?
• supporto della libreria. Quali librerie sono disponibili? Manipolazione di stringhe, matematica, accesso ai dati, web-servlet (o LISP-equivalenti), windowing toolkit, ecc ... Non voglio dover scrivere questa roba da zero.
• supporto per gli strumenti: quanto è buono l'IDE? Solido / stabile o traballante? Buon supporto editoriale? Debugger integrato? Se ho bisogno di fare GUI dev in LISP, c'è un IDE visivo o devo codificare il layout della GUI a mano (I odio farlo).
• buy-in per gli sviluppatori (non voglio davvero passare troppo tempo a insegnare ai miei compagni di squadra una nuova lingua)

Tutti questi fattori devono essere considerati al momento di decidere se LISP è appropriato per un progetto. Nel mondo aziendale, non l'ho mai provato.

Assolutamente. Paul Graham lo spiega bene .

...Back in 1995, we knew something that I don't think our competitors understood, and few understand even now: when you're writing software that only has to run on your own servers, you can use any language you want...

We chose Lisp. For one thing, it was obvious that rapid development would be important in this market. We were all starting from scratch, so a company that could get new features done before its competitors would have a big advantage. We knew Lisp was a really good language for writing software quickly, and server-based applications magnify the effect of rapid development, because you can release software the minute it's done.

If other companies didn't want to use Lisp, so much the better. It might give us a technological edge, and we needed all the help we could get...

So you could say that using Lisp was an experiment. Our hypothesis was that if we wrote our software in Lisp, we'd be able to get features done faster than our competitors, and also to do things in our software that they couldn't do. And because Lisp was so high-level, we wouldn't need a big development team, so our costs would be lower. If this were so, we could offer a better product for less money, and still make a profit. We would end up getting all the users, and our competitors would get none, and eventually go out of business. That was what we hoped would happen, anyway.

What were the results of this experiment? Somewhat surprisingly, it worked. We eventually had many competitors, on the order of twenty to thirty of them, but none of their software could compete with ours. We had a wysiwyg online store builder that ran on the server and yet felt like a desktop application. Our competitors had cgi scripts. And we were always far ahead of them in features. Sometimes, in desperation, competitors would try to introduce features that we didn't have. But with Lisp our development cycle was so fast that we could sometimes duplicate a new feature within a day or two of a competitor announcing it in a press release. By the time journalists covering the press release got round to calling us, we would have the new feature too.

It must have seemed to our competitors that we had some kind of secret weapon-- that we were decoding their Enigma traffic or something. In fact we did have a secret weapon, but it was simpler than they realized. No one was leaking news of their features to us. We were just able to develop software faster than anyone thought possible...

Dove: Emacs è un'applicazione reale che utilizza LISP.

Perché: era un ottimo modo per esprimere la mappatura tra battitura e azione. È interpretato ed è veloce ed è ben definito ed è semplice.

Entrambi Macsyma e Autocad si basa su un dialetto di Lisp. Li classificherei come "mondo reale" oltre a Emacs.

Assolutamente lo prenderei in considerazione. Soprattutto per i nuovi lavori di sviluppo che presentavano un potenziale di calcolo parallelo. Sembra essere un buon punto per questi tipi di linguaggi funzionali.

Il Lisp è una delle migliori scelte per implementare i compilatori. E poiché l'uso di DSL e eDSL sta aumentando, il Lisp sta diventando più prezioso. Sto usando un dialetto Lisp per tutte le mie attività relative al DSL.

In questo momento sto cercando di utilizzare newLisp come sostituto di Php sul mio sito web personale tramite il framework Dragonfly . Se riesco a capire come far funzionare bene Apache, lo userò (il web server integrato funziona molto bene, ma preferirei lavorare con Apache). E una volta che succede, userò newLisp ovunque io usi Php, perché non piaccio a Php e mi piace newLisp.

Al momento, Clojure non è una buona scelta per le app per Android, ma so che le persone ci stanno lavorando. Quindi se questo viene capito, sarebbe un altro posto in cui utilizzerei un dialetto di Lisp per le applicazioni del mondo reale ... ma, ancora una volta, questo perché semplicemente non mi piace Java.

Ma onestamente, preferisco Ruby to Lisp ... ma è principalmente una questione di community e documentazione.

Ho implementato un'applicazione proprietaria e commerciale in Common Lisp chiamato Tankan che gira su Microsoft Windows come eseguibile nativo.

È un programma per allenarti a memorizzare i caratteri kanji giapponesi.

Il programma viene eseguito come server HTTP in background. L'esecuzione di questo server e la navigazione verso le sue pagine sono coordinate da una piccola area di notifica di sistema (a.k.a "Tray") che ho sviluppato utilizzando Visual C ++.

L'applicazione dell'icona minidisco avvia, monitora e arresta il server basato su Lisp e comunica con esso utilizzando pipe Win32 legate allo standard input e output. Tramite una pipe, il server Lisp informa l'icona dell'icona del vassoio dell'URL con il numero di porta corretto e l'applicazione dell'icona del vassoio può avviare il browser tramite l'API Shell per sfogliare tale URL. L'utente fa semplicemente doppio clic sull'icona per visualizzare l'interfaccia utente.

Il programma Lisp mantiene nella sua memoria uno stato sessione abbastanza complesso che contiene la cronologia degli input dell'utente e varie relazioni tra vari oggetti. La notazione circolare dell'oggetto Lisp (abilitata dalla variabile *print-circle* ) e il modo in cui funziona attraverso i metodi personalizzati di CLOS print-object è di enorme aiuto nell'implementazione della persistenza: gli utenti possono salvare lo stato su disco e riprendere da dove avevano lasciato. Tutto è salvato, incluso lo stato dell'interfaccia utente. C'è molto sottostruttura condivisa nel grafico dell'oggetto, oltre ai cicli. Inoltre, un sacco di cruft statici che non devono essere persistenti, come il contenuto degli oggetti di entrata del dizionario. Con i metodi degli oggetti di stampa personalizzati ANSI Common Lisp, è possibile creare rappresentazioni a stampa condensata per oggetti che sono comunque leggibili dal computer e con i loro riferimenti circolari preservati.

Quasi nessun JavaScript è utilizzato nell'interfaccia utente web. Anche i controlli per nascondere e mostrare parti dell'interfaccia utente vengono eseguiti tramite l'invio di moduli e il rendering dell'HTML. Ogni dettaglio dello stato dell'interfaccia utente è quindi nel server e viene mantenuto quando l'utente salva. La rigenerazione dell'HTML è molto veloce. È fatto da una gigantesca espressione backquote Lisp che alimenta una macro di generazione HTML. Il codice compilato da Clozure Common Lisp (CCL) fa sì che tutto ciò accada così velocemente che difficilmente ti rendi conto che quando fai clic su un pulsante [+] sull'interfaccia utente per aprire qualcosa, stai inviando una richiesta a un server che rigenera la tutta la maledetta pagina, e non semplicemente eseguendo alcuni JavaScript locali per cambiare la visibilità di un elemento del documento locale.

Il programma è stato originariamente sviluppato con CLISP. Grazie all'ANSI CL è un linguaggio standard, con implementazioni che si adattano bene e non troppe insidie nel linguaggio (comportamento "non definito" o "definito dall'implementazione") facilmente trasferito su CCL.

CLISP non è stato abbandonato; è ancora utilizzato per alimentare il back-end delle licenze, utilizzando gran parte della stessa base di codice comune.

Ho sviluppato un sistema di licenze originale per il programma, utilizzando la crittografia a curva ellittica fornita dalla libreria IronClad, che viene utilizzata dal server delle licenze per firmare le licenze per certificarle. (Mi sembra di ricordare che avrei potuto usare il programma della riga di comando di OpenSSL per generare i parametri EC per la chiave del server.)

Le licenze sono rappresentate come oggetti Lisp. È un tributo alla portabilità di Lisp che un programma Windows compilato da Clozure Common Lisp può generare una licenza basata su S-expression, un programma CLISP in esecuzione su un server Debian può riempire il campo della firma digitale mancante in quell'oggetto e inviarlo a il programma Windows che può validare la firma.

Sul server, oltre al servizio di licenze basato su CGI, ho una semplice API a riga di comando per la gestione delle licenze. È possibile elencare le licenze, trovarne di specifiche e modificarne gli attributi: ad esempio modificare la data di scadenza di una licenza temporanea per concedere a un utente un'eccezione. Il back-end delle licenze genera anche e-mail. Non ho usato alcuna libreria per la gestione CGI sul lato server: solo codice Lisp rollato a mano per trattare le variabili di ambiente Apache e gli argomenti della riga di comando. (Sebbene il codice della libreria sia usato per gestire la codifica degli URL e la generazione di HTML). Nessun database è utilizzato per la memorizzazione; le licenze sono catenate in un file chiamato licenses.lisp e questo è quello.

Se qualcuno mi ha pagato, certo.

Probabilmente sarebbero più interessati a pagare qualcuno che conosce la lingua. Ho giocato solo con elisp e schema poche volte.