¿Qué tan independiente es Clojure de Java?

Soy bastante nuevo en el mundo de Clojure. Aprecio el hecho de que uno tiene fácil acceso a todas las bibliotecas de Java a través de las características de interoperabilidad de Clojure, pero me preguntaba cuánto Clojure se sostiene sobre sus propias piernas.

Por supuesto, hay algunas plataformas, como Android, donde siempre se requerirá la interoperabilidad con Java, porque las bibliotecas principales están escritas o expuestas en Java. Además, dado que las cadenas de Clojure son cadenas de Java, espero que las bibliotecas de manipulación de cadenas sean un contenedor de los métodos de cadenas de Java.

Pero para otras tareas no veo ninguna razón por la que no se puedan desarrollar las bibliotecas nativas de Clojure. Piense en Http, manipulación de fechas, análisis XML, plantillas, serialización y deserialización JSON, OAuth, bibliotecas matemáticas, etc.

Entonces mi pregunta es:

¿Hasta dónde ha llegado Clojure para independizarse del ecosistema de Java? ¿Tiene sus propias bibliotecas idiomáticas para la mayoría de estas y otras tareas?

Clojure se está volviendo cada vez más independiente de las bibliotecas de Java a medida que su base de código crece y se diversifica naturalmente. Una fortaleza importante de Clojure es que puede llamar a Java, por lo que sería poco probable ver el código de Clojure en el futuro que no use Java. Dicho esto, he realizado una gran cantidad de desarrollo sin invocar libs de Java (argumentos de línea de comandos, minupulación de texto básico, etc.). Aquí hay una lista de bibliotecas de clojure puras: http://www.clojure-toolbox.com/

Creo que es justo decir que Clojure está diseñado como un lenguaje alojado y ahora tiene tres implementaciones:

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

Debido a que está diseñado como un lenguaje alojado, el idioma es aprovechar las bibliotecas de la plataforma subyacente donde tiene sentido, pero también proporcionar un conjunto de bibliotecas "centrales" que son portátiles (desde un punto de vista de uso, no necesariamente a nivel de código). Espero que con el tiempo veremos muchas más bibliotecas Clojure ejecutándose en las tres plataformas, donde tiene sentido.

Mantengo clojure.java.jdbc y clj-time (un envoltorio alrededor de JodaTime), por lo que no tiene sentido usarlos en las versiones * CLR o * Script, pero las bibliotecas compatibles con API en diferentes espacios de nombres podrían ser una posibilidad.

Muchas de las bibliotecas Clojure "puras" ya deberían ser fáciles de usar en las versiones * CLR o * Script.

A la pregunta del OP: "Clojure-the-language" es bastante portátil, pero "Clojure-the-implementación" está deliberadamente vinculado al ecosistema de Java, al igual que ClojureCLR a .NET y ClojureScript a JavaScript.

A medida que Clojure continúa evolucionando, sin duda construirá más y más bibliotecas propias, lo que permitirá puertos más fáciles para otras máquinas virtuales. En lo que respecta a Clojure en la JVM, creo que el objetivo a largo plazo será reemplazar la mayoría de las bibliotecas con alternativas de Clojure (por lo tanto, tener esa inmutabilidad por defecto, STM, etc.), llevando la capa de interoperabilidad de Java al nivel más bajo de primitivas y base objetos como String. Esto será especialmente cierto una vez que la plataforma Java esté modularizada con jigsaw / OSGi en Java 8 (2013)

Sin embargo, creo que Clojure aún querrá probar y aprovechar la invocación dinámica (introducida como una instrucción de código de bytes en Java 7) y adoptará un enfoque bastante pragmático sobre qué bibliotecas reemplazar cuando (si Java tiene una lib perfectamente buena, entonces ¿por qué? cámbielo temprano).

NOTA: No estoy profundamente involucrado en la comunidad de Clojure, por lo que esto es en parte rumores / conjeturas.