Clojure vs altri Lisp [chiuso]

L'intento della mia domanda non è quello di iniziare una guerra con le fiamme, ma piuttosto di determinare in quali circostanze ogni lingua è "lo strumento migliore per il lavoro".

Ho letto diversi libri su Clojure ( Programming Clojure , Practical Clojure , The Joy of Clojure e l'edizione Manning Early Access di Clojure in Action ) e penso che sia un linguaggio fantastico. Attualmente sto leggendo Let Over Lambda che si occupa principalmente di macro Common Lisp e, anch'esso, è un linguaggio molto interessante.

Sono non un esperto di Lisp (più di un novizio), ma questa famiglia di linguaggi mi affascina, così come la programmazione funzionale, in generale.

Vantaggi di Clojure (e svantaggi di "altri"):

• Funziona su JVM.

  • La JVM è un ambiente linguistico molto stabile e ad alte prestazioni che soddisfa abbastanza bene il sogno di Sun di "Scrivi una volta, esegui [quasi] ovunque". Posso scrivere codice sul mio Macbook Pro, compilarlo in un file JAR eseguibile e quindi eseguirlo su Linux e Microsoft Windows con pochi test aggiuntivi.

  • La JVM (Hotspot e altre) supporta la garbage collection di alta qualità e la compilazione e l'ottimizzazione just-in-time molto performanti. Dove solo pochi anni fa ho scritto tutto ciò che doveva funzionare velocemente in C, ora non esito a farlo in Java.

  • Modello standard, semplice, multithreading. Common Lisp ha un pacchetto multithreading standard?

  • Spezza la monotonia di tutte quelle parentesi con [], {}e #{}, sebbene gli esperti di Common Lisp probabilmente mi diranno che con le macro del lettore, puoi aggiungerle a CL.

Svantaggi di Clojure :

• Funziona su JVM.
  • Nessuna ricorsione o continuazione della coda. Common Lisp supporta le continuazioni? Scheme richiede supporto per entrambi, credo.

Vantaggi degli altri (Common Lisp, in particolare) (e svantaggi di Clojure):

• Macro del lettore definibili dall'utente.

• Altri vantaggi?

Pensieri? Altre differenze?

Il mio elenco personale di motivi per preferire Clojure ad altri Lisp (ps penso ancora che tutti i Lisp siano fantastici!):

• Funziona sulla JVM - quindi ottiene l'accesso automatico alla fantastica ingegneria nella stessa JVM (algoritmi avanzati di raccolta dei rifiuti, ottimizzazione JIT HotSpot ecc.)

• Interoperabilità Java molto buona: fornisce compatibilità con la vasta gamma di librerie nell'ecosistema del linguaggio Java / JVM. Ho usato Clojure come linguaggio "collante" per collegare diverse librerie Java con buoni risultati. Poiché sviluppo anche molto codice Java, è utile per me che Clojure si integri bene con gli strumenti Java (ad esempio, uso Maven, Eclipse con il plug-in Counterclockwise per il mio sviluppo Clojure)

• Bella sintassi per vettori [1 2 3], mappe {:bob 10, :jane 15}e set #{"a" "b" "c"}: considero questi strumenti piuttosto essenziali per la programmazione moderna (oltre agli elenchi ovviamente!)

• Personalmente mi piace l'uso delle parentesi quadre per le forme vincolanti: ad esempio (defn foo [a b] (+ a b)), penso che renda il codice un po 'più chiaro da leggere.

• Enfasi sulla programmazione pigra e funzionale con strutture dati persistenti e immutabili - in particolare tutta la libreria Clojure di base è progettata per supportare questa impostazione predefinita

• Eccellente implementazione STM per concorrenza multi-core. Credo che Clojure abbia la migliore storia di concorrenza di qualsiasi lingua al momento (guarda questo video per ulteriori elaborazioni dallo stesso Rich Hickey )

• È un Lisp-1 (come Scheme), che personalmente preferisco (penso che in un linguaggio funzionale abbia senso mantenere funzioni e dati nello stesso spazio dei nomi)

Tieni presente che Clojure è un linguaggio e un'implementazione (di solito sulla JVM). Common Lisp è un linguaggio con più di dieci diverse implementazioni. Quindi abbiamo una mancata corrispondenza di categoria proprio qui. Potresti ad esempio confrontare Clojure con SBCL.

Generalmente:

• una versione di Common Lisp viene eseguita su JVM: ABCL

• la maggior parte delle altre implementazioni Common Lisp non lo fanno

• la maggior parte delle implementazioni CL ha capacità multitasking, una libreria fornisce un'interfaccia comune

• Common Lisp ha la sintassi per gli array. La sintassi per altri tipi di dati può essere scritta dall'utente e viene fornita da varie librerie.

• Common Lisp non supporta né l'ottimizzazione delle chiamate di coda né le continuazioni. Le implementazioni forniscono il TCO e le librerie forniscono una qualche forma di continuazione.

Una differenza importante tra Clojure e Common Lisp è che Clojure è più prescrittivo sulla programmazione funzionale. La filosofia, gli idiomi e in una certa misura i linguaggi / le biblioteche di Clojure incoraggiano fortemente e talvolta insistono sul fatto che si programma in modo funzionale (senza effetti collaterali, nessuno stato mutevole).

Common Lisp supporta sicuramente la programmazione funzionale, ma consente anche lo stato mutevole e la programmazione imperativa.

Naturalmente, ci sono una serie di vantaggi per la programmazione funzionale, nell'area della concorrenza e altro. Ma a parità di condizioni, è anche utile poter scegliere quale approccio utilizzare per ogni situazione. Clojure non proibisce completamente la programmazione imperativa, ma è meno accomodante di quello stile rispetto al Common Lisp.

Ecco un buon video con un confronto tra Scheme (principalmente Racket) e Clojure .

Per essere onesti, Racket ha lo zucchero di sintassi (materiale aggiuntivo per i lettori) anche per i tipi di dati (#hash, #, parentesi quadre, ecc.)

Inoltre, l'unico modo di Clojure per effettuare una chiamata di coda corretta è usare recur, questo è lo svantaggio della compilazione in JVM.

Nota che recurè l'unico costrutto di loop che non consuma stack in Clojure. Non esiste un'ottimizzazione delle chiamate di coda e l'uso di chiamate automatiche per il loop di limiti sconosciuti è scoraggiato. recurè funzionale e il suo utilizzo in tail-position è verificato dal compilatore. ( Forme speciali ).