Quali di queste vecchie critiche alla chiarezza comune valgono ancora oggi?

Question

Quali di queste vecchie critiche alla chiarezza comune valgono ancora oggi?

#1 da (31 voti)
#2 da (21 voti)

29

In Una critica di Common Lisp scritta da Rodney A. Brooks e Richard P. Gabriel di Stanford nel 1984, vengono discusse alcune decisioni di progettazione prese dal comitato di normalizzazione di Common Lisp. Mentre la maggior parte della discussione rimane valida, ci sono due dichiarazioni che si riferiscono alla tecnologia disponibile al momento e potrebbero essere false oggi.

Queste due affermazioni sono:

Too many costs of the language were dismissed with the admonition that ‘any good compiler’ can take care of them. No one has yet written—nor is likely to without tremendous effort—a compiler that does a fraction of the tricks expected of it.

Dato che sono un novizio Lisp comune, o addirittura un apprendista, non sono in grado di essere più specifico degli autori. Sembrano affermare che una grande generalità e flessibilità sono state incorporate in diversi aspetti del linguaggio, il che rende la scrittura di un buon compilatore abbastanza difficile.

In COMMON LISP a little too much control was placed on floating-point arithmetic. And certainly, although the correct behavior of a floating-point-intensive program can be attained, the performance may vary wildly.

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

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

common-lisp

posta user40989 26.11.2013 - 13:08

fonte

2 risposte

21

Quando questo documento fu scritto nel 1984, un computer con 1 megabyte di RAM e un disco rigido da 20 megabyte, capace di stare seduti sulla tua scrivania, era un grosso problema. Naturalmente, le dispute sorgono sulla praticità di una lingua di alto livello come Lisp è su hardware che spartano. I progressi della 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 spesso scambiano l'efficienza computazionale per l'efficienza della programmazione. Lisp può essere un linguaggio lento (in alcune implementazioni, ma lo può anche in altri linguaggi), ma ha anche una meritata reputazione per lo sviluppo rapido e molti programmi non richiedono un'infrastruttura altamente ottimizzata per esibire prestazioni adeguate.

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

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

risposta data 26.11.2013 - 18:02

fonte

Leggi altre domande sui tag common-lisp

Interface and Inheritance: il meglio di entrambi i mondi? Filosofia dietro lo schema del memento

score 31 · Accepted Answer

La carta è interessante in molti modi.

La parte più interessante è questa: gli autori hanno falsificato la carta dal 1984, solo due anni dopo, nel 1986. Brooks e Gabriel hanno sviluppato un compilatore Lisp altamente ottimizzante e l'hanno venduto commercialmente di grande successo per diversi anni: Lucid Common Lisp (PDF ).

La manutenzione di questo compilatore Lisp è ancora disponibile da LispWorks : ora è chiamato 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 implementate in Lucid CL. Ad esempio, nella mia città natale, il primo sistema di informazione sul trasporto pubblico per l'HVV (Hamburger Verkehrsverbund) è stato installato utilizzando Lucid CL su SUN SPARCstation. Era disponibile per il pubblico nelle stazioni ferroviarie utilizzando un ampio touch screen e nel call center.

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

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

The dynamically retargetable compiler has been shown to be a means by which ease of compilation for a variety of Lisp implementations can be performed; a means of porting Lisp systems to a variety of computers; and a tool for producing high-quality, high-performance code for a variety of computers from a common source.

Quindi avevano appena implementato ciò che la Una Critica del Common Lisp sosteneva essere difficile o impossibile.

Al giorno d'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 poi 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 implementatori. 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 diversi obiettivi di implementazione.

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