Quanto è indipendente Clojure da Java?

Sono abbastanza nuovo nel mondo Clojure. Apprezzo il fatto che si abbia un facile accesso a tutte le librerie Java tramite le funzionalità di interoperabilità di Clojure, ma mi chiedevo quanto Clojure si trovi sulle sue gambe.

Naturalmente ci sono alcune piattaforme, come Android, in cui l'interoperabilità con Java sarà sempre richiesta, poiché le librerie principali sono scritte o esposte in Java. Inoltre, poiché le stringhe Clojure sono stringhe Java, mi aspetto che le librerie di manipolazione delle stringhe siano un wrapper per i metodi Java String.

Ma per altre attività non vedo alcun motivo per cui le librerie Clojure native non possano essere sviluppate. Pensa a Http, manipolazione della data, analisi XML, templating, serializzazione e deserializzazione JSON, OAuth, librerie matematiche e così via.

Quindi la mia domanda è:

Fino a che punto Clojure è diventato indipendente dall'ecosistema Java? Ha le sue librerie idiomatiche per la maggior parte di queste e altre attività?

Clojure sta diventando sempre più indipendente dalle librerie Java man mano che la sua base di codice cresce e si diversifica naturalmente. Uno dei principali punti di forza di Clojure è che può chiamare Java, quindi è improbabile che in futuro venga visualizzato il codice Clojure che non utilizza Java. Detto questo, ho fatto una buona parte dello sviluppo senza chiamare le librerie Java (argomenti della riga di comando, minupolazione del testo di base, ecc.). Ecco un elenco di librerie di clojure pure: http://www.clojure-toolbox.com/

Penso che sia giusto dire che Clojure è progettato come lingua ospitata e ora ha tre implementazioni:

• Clojure su JVM
• ClojureCLR su .NET
• ClojureScript su JavaScript

Poiché è progettato come linguaggio ospitato, l'idioma è sfruttare le librerie della piattaforma sottostante laddove ha senso, ma anche fornire una serie di librerie "core" che sono portatili (da un punto di vista dell'utilizzo, non necessariamente a livello di codice). Mi aspetto che nel tempo vedremo molte più librerie Clojure in esecuzione su tutte e tre le piattaforme, dove ha senso.

Mantengo clojure.java.jdbc e clj-time (un wrapper per JodaTime), quindi non ha senso usare quelli sulle versioni * CLR o * Script ma librerie compatibili con API in diversi spazi dei nomi potrebbero essere una possibilità.

Molte delle librerie "pure" di Clojure dovrebbero essere già facili da usare nelle versioni * CLR o * Script.

Alla domanda del PO: "Clojure-the-language" è piuttosto portatile ma "Clojure-the-implementazione" è volutamente legato all'ecosistema Java, così come ClojureCLR a .NET e ClojureScript a JavaScript.

Man mano che Clojure continua a evolversi, creerà sicuramente sempre più librerie proprie, consentendo porte più facili per altre VM. Per quanto riguarda Clojure sulla JVM, credo che l'obiettivo a lungo termine sarà quello di sostituire la maggior parte delle librerie con alternative a Clojure (avendo così l'immutabilità di default, STM ecc.), Portando il livello di interoperabilità Java al livello più basso di primitive e base oggetti come String. Ciò sarà particolarmente vero una volta che la piattaforma Java è modulare con jigsaw / OSGi in Java 8 (2013)

Tuttavia, credo che Clojure vorrà ancora provare a trarre vantaggio dall'invocinamica (introdotta come istruzione bytecode in Java 7) e adotterà un approccio abbastanza pragmatico su quali librerie sostituire quando (se Java ha una lib perfettamente perfetta, allora perché cambiarlo presto).

NOTA: non sono profondamente coinvolto nella comunità Clojure, quindi questo è in parte sentito dire / ipotesi.