Quanto è indipendente Clojure da Java?

Naviga le tue risposte
13

Sono abbastanza nuovo nel mondo dei Clojure. Apprezzo il fatto che si abbia un facile accesso a tutte le librerie Java tramite le funzionalità di interoperabilità Clojure, ma mi stavo chiedendo quanto Clojure si regga da solo.

Naturalmente ci sono alcune piattaforme, come Android, in cui l'interoperabilità con Java sarà sempre richiesta, perché le librerie di base 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 sui metodi String Java.

Ma per altri compiti non vedo ragioni per cui le librerie Clojure native non possano essere sviluppate. Pensa a Http, manipolazione della data, analisi XML, templating, serializzazione JSON e deserializzazione, 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à?

    
posta Andrea 18.01.2012 - 09:47
fonte

3 risposte

2

Clojure sta diventando sempre più indipendente dalle librerie Java poiché la sua base di codice cresce e si diversifica naturalmente. Uno dei punti di forza di Clojure è che può chiamare Java, quindi vedere il codice Clojure in futuro che non usa java sarebbe improbabile. Detto questo, ho fatto un bel po 'di sviluppo senza chiamare le librerie Java (argomenti di riga di comando, minuple di testo di base, ecc.). Ecco un elenco di librerie di clojure pure: link

    
risposta data 18.01.2012 - 22:08
fonte
7

Penso 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 è quello di sfruttare le librerie della piattaforma sottostante dove ha senso, ma anche fornire un set di librerie "core" che sono portatili (da un punto di 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.

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

Molte delle librerie Clojure "pure" dovrebbero essere immediatamente utilizzabili nelle versioni * CLR o * Script.

Alla domanda dell'OP: "Clojure-the-language" è abbastanza portatile ma "Clojure-the-implementation" è deliberatamente legato all'ecosistema Java, come ClojureCLR to .NET e ClojureScript a JavaScript.

    
risposta data 18.01.2012 - 19:24
fonte
2

Man mano che Clojure continua a evolversi, costruirà sempre più le sue librerie, consentendo porte più semplici ad altre macchine virtuali. Per quanto riguarda Clojure sulla JVM, credo che l'obiettivo a lungo termine sarà quello di sostituire la maggior parte delle librerie con le alternative Clojure (avendo quindi quella immutabilità di default, STM ecc.), Portando lo strato di interoperabilità Java al livello più basso di primitive e base oggetti come String. Ciò è particolarmente vero una volta che la piattaforma Java è stata modularizzata con jigsaw / OSGi in Java 8 (2013)

Tuttavia, credo che Clojure vorrà ancora provare e trarre vantaggio da invokedynamic (introdotto come istruzione bytecode in Java 7) e avrà un approccio abbastanza pragmatico su quali librerie sostituire quando (se Java ha una lib buona , quindi perché cambiarlo presto).

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

    
risposta data 18.01.2012 - 11:07
fonte

Leggi altre domande sui tag

Gli oggetti di dominio in Domain Driven Design dovrebbero essere solo di scrittura? Applicazione dei principi SOLID