Quali di queste vecchie critiche al lisp comune si applicano ancora oggi?

In A Critique of Common Lisp, scritto da Rodney A. Brooks e Richard P. Gabriel di Stanford nel 1984, vengono discusse alcune decisioni progettuali mantenute dal comitato di normalizzazione di Common Lisp. Mentre la maggior parte della discussione rimane valida, ci sono due affermazioni che si riferiscono alla tecnologia disponibile al momento e potrebbero essere false oggi.

Queste due affermazioni sono:

Troppi costi della lingua sono stati liquidati con l'ammonizione che "qualsiasi buon compilatore" può occuparsene. Nessuno ha ancora scritto - e probabilmente non lo farà senza uno sforzo tremendo - un compilatore che fa una frazione dei trucchi che ci si aspetta.

Dato che sono un novizio del Lisp comune o anche un apprendista, non sono in grado di essere più specifico di quanto lo siano gli autori. Sembrano affermare che una grande generalità e flessibilità sono state integrate in diversi aspetti del linguaggio, il che rende piuttosto difficile scrivere un buon compilatore.

In LISP COMUNE un po 'troppo controllo è stato posto sull'aritmetica in virgola mobile. E certamente, sebbene sia possibile ottenere il comportamento corretto di un programma ad alta intensità in virgola mobile, le prestazioni possono variare notevolmente.

A quanto ho capito, sembra che scrivere un codice numerico efficiente in Common Lisp sia possibile ma più impegnativo di quanto non sia.

Questo è stato trenta anni fa. Come dovrei considerare queste affermazioni oggi se sono disposto a scrivere programmi Common Lisp per una delle implementazioni comuni di software libero (CLISP, SBCL et al.)?

Il documento è interessante in molti modi.

La parte più interessante è questa: gli autori hanno falsificato il documento dal 1984 solo due anni dopo nel 1986 stessi. Brooks e Gabriel hanno sviluppato un compilatore Lisp altamente ottimizzante e lo hanno venduto commercialmente con successo per diversi anni: Lucid Common Lisp (PDF).

La manutenzione per questo compilatore Lisp è ancora disponibile da LispWorks : ora si chiama Liquid Common Lisp .

Le ottimizzazioni del compilatore di Liquid CL sono documentate nel Capitolo 3 della Guida per utenti avanzati : Ottimizzazione dei programmi Lisp .

Diverse applicazioni commerciali sono state scritte e distribuite in Lucid CL. Ad esempio, nella mia città natale, il primo sistema di informazione sui trasporti pubblici per l'HVV (Hamburger Verkehrsverbund) è stato distribuito usando Lucid CL su una SUN SPARCstation. Era disponibile per il pubblico nelle stazioni ferroviarie utilizzando un ampio touchscreen e nel call center.

Lucid CL ha avuto successo perché il suo compilatore in modalità di produzione ha creato applicazioni Common Lisp veloci, principalmente per piattaforme Unix / RISC.

Brooks e Gabriel stanno scrivendo su Lucid Common Lisp nel 1986:

Il compilatore retargetable dinamicamente ha dimostrato di essere un mezzo per eseguire la facilità di compilazione per una varietà di implementazioni Lisp; un mezzo per trasferire i sistemi Lisp su una varietà di computer; e uno strumento per produrre codice di alta qualità e prestazioni per una varietà di computer da una fonte comune.

Così avevano appena implementato ciò che la Critica del Common Lisp sosteneva di essere difficile o impossibile.

Oggi le implementazioni più avanzate stanno facendo molte ottimizzazioni, ma l'hardware è anche 1000 + volte più veloce di quello che avevamo nel 1984. Un VAX 11/780 aveva quindi un MIPS (milioni di istruzioni al secondo) e una macchina Lisp era anche in quella gamma. Un Motorola 68000 aveva una frequenza di clock di 8 MHz.

Le critiche sulle prestazioni in virgola mobile e le prestazioni generalmente variabili sono ancora valide, ma ciò riflette la scelta degli attuatori. Alcune implementazioni non sono sviluppate come compilatori ad alte prestazioni. Il loro obiettivo principale potrebbe essere la portabilità, la compattezza o qualcos'altro e quindi hanno obiettivi di implementazione diversi.

Come utente / sviluppatore non si è obbligati a scrivere codice portatile e utilizzare tutti i dieci sistemi Common Lisp attualmente supportati. Utilizzare l'implementazione più adatta al problema dell'applicazione.

Quando questo documento è stato scritto nel 1984, un computer con 1 megabyte di RAM e un disco rigido da 20 megabyte, in grado di sedersi sulla scrivania, era un grosso problema. Naturalmente, sorgeranno controversie sulla praticità di un linguaggio di alto livello come Lisp su hardware spartano. I progressi nella tecnologia hardware e del compilatore che hanno avuto luogo da allora hanno reso i programmi Lisp molto più facili da scrivere ed eseguire, indipendentemente da eventuali inefficienze numeriche che potrebbero essere presenti nella lingua.

I programmatori scambiano spesso l'efficienza computazionale per l'efficienza di programmazione. Lisp può essere un linguaggio lento (in alcune implementazioni, ma anche altre lingue), ma ha anche una meritata reputazione per un rapido sviluppo e molti programmi non richiedono un'infrastruttura altamente ottimizzata per esibire prestazioni adeguate.

La scelta dell'implementazione di Lisp può influire notevolmente sul profilo delle prestazioni dei programmi. Ad esempio, CLISP ammette prontamente che "Se il tuo codice è fortemente numerico, potresti preferire CMUCL". Diverse implementazioni moderne di Lisp (e Scheme) consentono di specificare suggerimenti di tipo numerico, che aumenteranno le prestazioni numeriche.

In breve, la situazione oggi è molto meglio di allora.