Decima regola di Greenspun, ogni grande progetto include un interprete Lisp? [chiuso]

L'affermazione è iperbole. Ma ci sono segni evidenti di invidia Lisp in altre lingue. Guarda C # e come sta diventando più funzionale in natura. Guarda i vari Business Process Management, il flusso di lavoro e i framework EAI che fanno di tutto per rendere possibile la programmazione del sistema senza modificare il programma.

C'è un libro su Domain Specific Languages di Martin Fowler che parla di come fare la meta-programmazione in linguaggi orientati agli oggetti. Quindi c'è un po 'di verità nell'iperbole.

Paul Graham ha chiamato Lisp il linguaggio più potente guardando la lista dei primi arrivati con Lisp , è facile vedere perché molte lingue impallidiscono in confronto.

Il modo per aggirare la decima regola è la programmazione poliglotta. Rendendosi conto che una lingua / struttura non è il martello d'oro. Quindi, invece di creare un'implementazione ad hoc di Lisp, è sufficiente utilizzare Lisp.

La "decima regola" di Greenspun è stata un po 'fuori dagli schemi. Una volta allungato abbastanza, se lo fai coprire "qualsiasi sistema di scripting o configurazione", allora ovviamente la risposta a questa domanda dovrà essere "sì", poiché la configurazione è qualcosa che qualsiasi programma non banale richiede in una certa misura, e scripting è solo leggermente meno comune man mano che si sale verso la scala della complessità.

D'altra parte, dai un'occhiata a GOAL , una variante Lisp inventata da Naughty Dog per la programmazione dei giochi. Non sembra affatto un Lisp "classico". È un sistema di stile estremamente imperativo, con funzionalità orientata agli oggetti, nessun interprete, supporto minimo per la garbage collection (che si basa invece su funzionalità di pulizia a livello di runtime) e ampio supporto per l'assembly inline.

In altre parole, quando hanno provato a usare Lisp per un progetto sufficientemente complesso, hanno scoperto che per fare qualcosa di utile hanno dovuto trasformare la lingua in un'implementazione ad-hoc, specificatamente informata di metà del C ++! ;) (E alla fine dovettero smettere di usarlo dopo che il ragazzo che progettò GOAL se ne andò, perché nessuno poteva capire il suo codice.)

Curiosamente, una risposta a questa domanda è già in Programmatori SE .

Per citare la parte pertinente:

Greenspun's point was (in part) that many complex programs have built-in interpreters. Rather than building an interpreter into a language he suggested it might make more sense to use a language like Lisp that already has an interpreter (or compiler) built-in.

At the time I had been working on a rather big app that performed user-defined calculations using a custom interpreter for a custom language. I decided to try re-writing its core in Lisp as a large-scale experiment.

It took roughly six weeks. The original code was ~100,000 lines of Delphi (a Pascal variant). In Lisp that was reduced to ~10,000 lines. Even more surprising, though, was the fact that the Lisp engine was 3-6 times faster. And keep in mind that this was the work of a Lisp neophyte! That whole experience was quite an eye-opener for me; for the first time I saw the possibility of combining performance and expressiveness in a single language.
-- Michael Lenaghan

Per chiarire ulteriormente questa parte, Michael ha risposto a un commento con:

Wow, that must have been some really horrible Delphi code if it somehow managed to perform 3-6x slower than a Lisp implementation!" Right, I'll count that as my fail for not explaining it better. The Lisp implementation was able to transform user expressions into Lisp expressions--a trivially easy process--and then compile the Lisp expressions to native code (with full optimization). That's the meaning of Greenspun's Tenth Rule.
-– Michael Lenaghan

Dato che questa risposta è composta da un'altra risposta di qualcun altro, è wiki della comunità.

La regola è uno scherzo, ma c'è un po 'di verità in esso. Qualsiasi sistema complesso conterrebbe un numero di parti interpretate (vedi, in che modo il "modello di interpreti" è popolare tra coloro che credono in tutti quei modelli mumbo-jumbo). Qualsiasi sistema complesso deve fornire alcuni strumenti di configurazione, spesso strutturati, spesso interpretati.

È molto probabile che qualsiasi sistema complesso abbia diversi passaggi di generazione del codice e vari preprocessori personalizzati nel suo processo di creazione (si pensi a cose come moc in Qt o tablegen in LLVM).

Molti sistemi si destreggiano tra le complesse strutture di dati ad albero utilizzando set (quasi sempre) di strumenti per la manipolazione e la trasformazione degli alberi progettati in modo molto simile a quelli della Common Lisp.

Tutte queste cose sono gratuite con Lisp, e nella maggior parte dei casi tutte quelle ad hoc, non pianificate, non pensate attraverso implementazioni sufficientemente approfondite sarebbero assolutamente inferiori.

Ogni sistema sufficientemente complesso avrà concetti e requisiti specifici del dominio che sono estremamente difficili da esprimere con le astrazioni del linguaggio in cui stai lavorando. Questo inavvertitamente costringe i programmatori a creare astrazioni specifiche per domare il fardello di colmare il divario semantico tra il linguaggio di programmazione e il dominio specifico. Una volta che ce ne sono abbastanza di queste astrazioni, in pratica hai un interprete di una lingua specifica del dominio. Questa è una parte inevitabile dello sviluppo del software.

La regola potrebbe probabilmente essere più accurata (e meno divertente) come "ogni grande sistema basato su software sarà richiesto per implementare un comportamento dinamico".

Questo può essere fatto in due modi:

1. Un file di configurazione di grandi dimensioni con dozzine di parametri e centinaia di definizioni.

2. Un linguaggio di script AD-HOC.

"sendmail" è probabilmente l'esempio canonico di tipo "1". Non riesco a pensare a nessun buon esempio di tipo "2" che non implichi l'incorporamento di un linguaggio di scripting "reale" a la Warcraft / LUA o persino Netscape / Javascript.

Il problema è che per pochi parametri è semplice e veloce farlo con un file di configurazione, ma questa soluzione non è davvero scalabile. Tuttavia, in nessun caso sarà conveniente scaricare il file di configurazione a favore di un approccio di script quando si aggiungono una o due opzioni al file di configurazione. Quindi il codice che interpreta il file di configurazione finisce per essere un interprete scritto male.

Potrebbe essere vero, come altri hanno affermato, molti programmi richiedono la configurabilità e quindi contengono vari interpreti di tipo Lisp.

Tuttavia, la dichiarazione implica anche un sorrisetto che tutto ciò che serve per fare un programma è Lisp e che tutte le altre lingue sono inferiori.

Ma è sbagliato, Lisp può essere espressivo, ma è anche troppo astratto, prova a nascondere i dettagli di una piattaforma e fa finta che non esistano liste nel mondo dei computer.

La realtà della programmazione ad alte prestazioni, è che a volte abbiamo bisogno di mischiarsi con bit e byte, e fare cose specifiche del sistema operativo, quindi non è possibile fare tutto con solo Lisp come implica l'istruzione.

È piuttosto il contrario, non importa quanto sia complicato, intelligente o sofisticato il linguaggio che inventi, tutto ciò che finisce per essere è solo un altro modo per scrivere assembly.

Indipendentemente dal fatto che fosse pensato per essere preso sul serio, è vero per i più grandi progetti C e C ++ su cui ho lavorato.

Ciò che non è vero è che i linguaggi di scripting personalizzati assomigliano al Common Lisp. Gli esempi positivi assomigliano a Scheme (perché i designer più intelligenti hanno integrato Guile, SpiderMonkey e Lua invece di inventare la propria lingua). Gli esempi più importanti di DailyWTF erano un linguaggio simile a Forth e un linguaggio simile a MUMPS.

Un altro esempio (non sicuro se conta come Greenspunning, ma certamente un WTF) era un interprete XSLT usato per lo scripting generico. Questo è stato più simile a Lisp in quanto hanno aggiunto un ciclo di feedback in cui l'output sarebbe stato trasformato in XSLT una seconda volta, quindi ora hai effettivamente macro.
Il motivo qui però non era quello di ottenere l'accesso a funzionalità lispie ma di aggirare le procedure di QA del codice aziendale (che aggiungeva 3 settimane di latenza a ogni correzione di bug. XML era considerato "dati" ed esente dal processo.)

Purtroppo no!

Sebbene sia meglio incorporare un vero interprete lisp (y) (javascript o lua alos fa un buon lavoro), aggiungere un homebrew 4gl a un progetto riduce le dimensioni complessive e aumenta la flessibilità.

I progetti che "codificano tutto" hanno un numero di moduli enormemente maggiore e diventano ingombranti e inflessibili.