Perché Clojure su altre Lisps JVM: Kawa, Armed Bear o SISC?

Question

La JVM aveva già tre Lisps prima dell'arrivo in scena di Clojure: Kawa , Orso armato e SISC .

Quale gap riempie Clojure che è stato lasciato da quei Lisps?

Answer 1

Kawa, ABCL e SISC sono reimplementazioni di lingue esistenti che sono piuttosto lunghe nel dente. Sono eccellenti se per qualche motivo si desidera utilizzare Scheme standard o Common Lisp standard su JVM.

Clojure è una nuova lingua. Non colma un gap . Aggiunge possibilità completamente nuove. Favorisce un approccio puramente funzionale: Schema e CL sono entrambi multi-paradigma. Clojure prende in prestito pesantemente dalla progettazione di varie lingue FP (ML, Haskell).

E sì, potresti aggiungere il supporto della concorrenza ad altri Lisp, ma questo non ha assolutamente senso. Clojure è stato progettato sin dall'inizio come linguaggio concorrente. Tanto che la scrittura di programmi concorrenti è banale in Clojure, non nella scienza missilistica come nei linguaggi non funzionali (Schema, CL non esclusi). Guarda in questo modo:

Le persone dicono che C ti consente di scrivere programmi veloci per impostazione predefinita.

Bene, Clojure ti permette di scrivere programmi simultanei di default.

Answer 2

1. " Clojure è un Lisp non vincolato dalla retrocompatibilità " (che proviene dal sito web Clojure). È un nuovo inizio. Sono progressi. Usa le idee che rendono potente Lisp / Scheme ma ripensale intorno alla piattaforma di piattaforma.

2. Clojure sarà sempre il Clojure più recente. Con qualsiasi altra lingua trasferita su JVM, la versione JVM potrebbe essere sempre in fase di recupero. Se non hai bisogno della piattaforma Java perché usare SISC su un altro schema? Se lo fai, perché non usare quello Lisp (Clojure) che è stato progettato appositamente per questo?

3. Progettato pensando alla concorrenza.

Answer 3

La risposta più semplice che posso trovare è, Clojure non è Common-Lisp. Clojure non è vincolato dalla storia di altre Lisps. È una nuova lingua costruita per la JVM.

Answer 4

Semplicemente non ne ero a conoscenza, il che è un grande vantaggio per Clojure (che le persone hanno fatto abbastanza rumore che ho scoperto). La cosa più grande che Clojure ha che non ho visto in quelli che hai elencato è Memoria transazionale software .

Clojure è stato progettato anche per la JVM, invece di essere un layer per un'altra lingua, quindi è un po 'più "Java-y" immagino che lo sarebbero gli altri quando devi fare l'interoperabilità.

Answer 5

La pagina logica su clojure.org afferma:

  

Perché ho scritto ancora un altro linguaggio di programmazione? Fondamentalmente perché volevo:

     

  
• A Lisp
  
• per la programmazione funzionale
  
• simbiotico con una piattaforma consolidata
  
• progettato per la concorrenza
  

     

e non sono riuscito a trovarne uno.

Le 3 lingue che hai citato (Kawa, ABCL e SISC) soddisfano questi requisiti? Sono:

• Lisps (dialetti CL o Scheme) ?
• per la programmazione funzionale ?
• simbiotico con una piattaforma consolidata (la JVM) ?

ma non sono progettati per la concorrenza (STM); tuttavia, per essere onesti e completi, ci sono almeno 2 librerie STM che ho trovato per CL che non sono ancora state menzionate:

1. STMX
   • Testato su ABCL. In fase di sviluppo attivo.
2. CL-STM
   • Morto? L'ultima modifica è avvenuta nel 2007.

Hmm ... Allora perché creare un nuovo Lisp? Principalmente perché si tratta di librerie . La pagina logica su clojure.org continua (enfasi aggiunta):

  

Che dire dei Lisps standard (Common Lisp e Scheme)?

     

  
• Standardizzazione post innovazione lenta / assente
  
• Strutture di dati core mutabili, non estendibili
  
• Nessuna concorrenza nelle specifiche
  
• Esistono già buone implementazioni per JVM (ABCL, Kawa, SISC et al)
  
• I Lisps standard sono le loro piattaforme
  

È un problema di progettazione della concorrenza linguistica , come altri hanno già detto.

Inoltre, perché fermarsi alla JVM? Il supporto CLR Clojure è in fase di sviluppo attivo .

Questi sono i 2 vuoti che colma, dal mio punto di vista. Dovresti usare Clojure se soddisfa le tue esigenze. Non preoccuparti di perdere le tue abilità se Clojure cade dalla mappa. Le tue capacità di Lisp, ma soprattutto il tuo modo di pensare, passeranno agli altri dialetti di Lisp.

Answer 6

Se fossi cinico, direi che è perché Clojure ha un sito web più bello e un nome più sexy.

/ p>

Answer 7

Vorrei anche aggiungere che Clojure è un linguaggio relativamente nuovo, implementato da una persona, con buone capacità di marketing e molta energia. Sta investendo molto tempo e hype nel clojure ... a volte, l'hype è una profezia che si autoavvera in quanto se riesci a convincere abbastanza persone che è l'ultima cosa più grande, allora puoi ottenere abbastanza supporto e slancio per renderlo effettivamente lavoro.

Sospetto che gli implementatori di Kawa ecc. non abbiano molto in gioco, quindi non stanno esaltando il loro prodotto. Inoltre, cosa c'è da hype? " Abbiamo un'ottima lingua .. si chiama Lisp " È una vendita di marketing più difficile.

Penso che Java ne sia un ottimo esempio. Aveva alcune carenze molto gravi, ma poiché era stato commercializzato e pubblicizzato in modo così intenso da ottenere un notevole slancio, il che significava supporto da parte di venditori di hardware / software, produttori di strumenti, investimenti per settore, ecc. Ad ogni modo, ha raggiunto un certo grado di successo, sebbene odiassi programmare. Clojure potrebbe raggiungere un simile successo, mentre altri Lisp non lo hanno fatto.

Answer 8

Il vantaggio di Clojure è che ti dà accesso a tutte le librerie / codice java là fuori e supporto multi-thread perché è basato su JVM. Inoltre, è stato progettato pensando alla concorrenza, qualcosa che generalmente non è progettato in lisp, anche se a causa delle primitive di mappatura probabilmente non sarebbe difficile progettare un lisp che supporti bene la concorrenza.

Detto questo, ho provato Clojure e ho odiato la sintassi e il dolore nel fattore di testa che sembra andare d'accordo con qualsiasi cosa connessa a Java.

Answer 9

Clojure è "un lisp", non è alcun lisp che già conosci. Ho passato l'ultimo un paio di giorni leggendo il materiale e guardando i video, e sono impressionato. Suo la premessa è che i programmi funzionali (basati su dati immutabili) sono il modo migliore per farlo gestire la concorrenza. Clojure implementa un sistema simile a lisp basato su JVM per fornirlo.

Answer 10

Non dobbiamo avere un'altra risposta (e non mi aspetto voti per questa), ma qui ci sono alcuni piccoli miglioramenti a molte altre risposte.

Le novità non sono necessariamente migliori. Più recenti e mal progettati non sono buoni, nuovi e non mantenuti non sono buoni, e i nuovi senza una comunità di utenti più ampia (o almeno in crescita) non sono buoni. (Nuove lingue escono regolarmente, ma la maggior parte di loro cade a causa del disuso.)

Adoro Common Lisp. Parte della sua bellezza è la sua eccentricità, che deriva dal fatto che è stato progettato da comitati con l'obiettivo di retrocompatibilità con diversi dialetti incompatibili.

Adoro Scheme. È un linguaggio bellissimo ed elegante. Tuttavia, il suo sviluppo dipende dai comitati, e forse questo lo ha rallentato a volte. In ogni caso, i suoi obiettivi sono diversi da quelli di Clojure.

Common Lisp e Scheme hanno enfasi come la ricorsione della coda che non sono adatte all'efficienza sulla JVM. Clojure è stato progettato fin dall'inizio per mappare bene su JVM e per interagire (abbastanza) bene con Java. (Non sono sicuro di cosa significhi sui dialetti Clojurescript e CLR.)

Il fatto che Clojure sia stato sviluppato, inizialmente, da una persona, Rich Hickey, ed è controllato da lui insieme a una piccola squadra, non lo rende necessariamente migliore di una lingua controllata dai comitati. Se quella persona prendesse delle decisioni sbagliate, Clojure non sarebbe una buona lingua.

Tuttavia, e questo è il punto importante : Hickey ha progettato un linguaggio che è ben pensato, elegante e che dall'inizio includeva una suite di funzioni sistematicamente correlate che lo rendono facile molto con un po '. Questo vale per l'interoperabilità JVM di base e per il resto della lingua. Le persone che controllano Clojure continuano ad essere rigorose nel rispettare gli obiettivi della lingua, finora.

Questa è una grande parte di ciò che amo di Clojure: è ben progettato sia nel suo insieme che nei suoi dettagli. Ciò significa che una volta che ti ci abitui, è un piacere programmarlo.

Sarebbe solo un po 'un'esagerazione (o un eufemismo?) dire che Clojure ha il potere di Common Lisp con l'eleganza di Scheme. Common Lisp ha molte cose di cui hai bisogno integrate nella lingua, ma è un casino (lo dico con amore) e quando hai bisogno di qualcosa di più di ciò che è nella lingua, a volte ci sono diverse librerie incompatibili con diversi compromessi. Lo schema di progettazione è piccolo, sebbene siano disponibili librerie. Clojure ha un corpus crescente di librerie standard (a differenza di CL) che sono più o meno parti della lingua. Un buon esempio di ciò è il progetto core.matrix, che fornisce un'interfaccia comune a diverse implementazioni di matrici. Questo è importante, perché esistono diverse implementazioni di matrici che sono le migliori per un uso occasionale di matrici piccole o per un uso estensivo di matrici enormi, ad esempio.

Nulla di tutto ciò intende dire che Clojure è migliore di Common Lisp o Scheme; non è. Le tre lingue hanno virtù diverse.

Answer 11

È nuovo! Ciò significa che non molti vecchi lispers lo useranno poiché la tradizionale comunità lisp è bene, tradizionale, ma significa anche che le persone senza precedenti esperienze lisp la prenderanno come la nuova cosa.

Imho, Clojure è per i vecchi Lisps ciò che Ruby era per Smalltalk. Non necessariamente migliore, ma abbastanza buono. E soprattutto, è più accettabile per il tuo datore di lavoro perché ha slancio ed è visto come una lingua in aumento, proprio come una volta era Ruby.