Eu sou bastante novo no mundo Clojure. Aprecio o fato de que se tem acesso fácil a todas as bibliotecas Java por meio dos recursos de interoperabilidade Clojure, mas fiquei imaginando o quanto o Clojure suporta em suas próprias pernas.
Obviamente, existem algumas plataformas, como o Android, onde a interoperabilidade com Java sempre será necessária, porque as bibliotecas principais são gravadas ou expostas em Java. Além disso, como as cadeias de caracteres Clojure são cadeias Java, espero que as bibliotecas de manipulação de cadeias sejam um invólucro nos métodos Java String.
Mas para outras tarefas, não vejo razão para que as bibliotecas nativas do Clojure não possam ser desenvolvidas. Pense em Http, manipulação de datas, análise XML, modelagem, serialização e desserialização JSON, OAuth, bibliotecas matemáticas e assim por diante.
Então, minha pergunta é:
Até que ponto Clojure chegou a se tornar independente do ecossistema Java? Possui bibliotecas idiomáticas próprias para a maioria dessas e de outras tarefas?
Respostas:
O Clojure está se tornando cada vez mais independente das bibliotecas Java, à medida que sua base de códigos cresce e diversifica naturalmente. Um dos pontos fortes do Clojure é que ele pode chamar Java, portanto, é improvável que, no futuro, o código Clojure não use java. Dito isto, desenvolvi bastante sem chamar Java libs (argumentos de linha de comando, minupulação básica de texto, etc.). Aqui está uma lista de bibliotecas puras de clojure: http://www.clojure-toolbox.com/
fonte
Eu acho que é justo dizer que o Clojure foi projetado como uma linguagem hospedada e agora tem três implementações:
Como foi projetada como uma linguagem hospedada, o idioma é alavancar as bibliotecas da plataforma subjacente onde faz sentido, mas também fornecer um conjunto de bibliotecas "principais" que são portáveis (de um ponto de vista de uso, não necessariamente no nível do código). Espero que, com o tempo, veremos muito mais bibliotecas Clojure em execução nas três plataformas, onde isso faz sentido.
Eu mantenho clojure.java.jdbc e clj-time (um invólucro em torno do JodaTime) para que não faça sentido usá-los nas versões * CLR ou * Script, mas bibliotecas compatíveis com API em diferentes namespaces podem ser uma possibilidade.
Muitas das bibliotecas "puras" do Clojure devem ser fáceis de usar nas versões * CLR ou * Script.
Para a pergunta do OP: "Clojure-the-language" é bastante portátil, mas "Clojure-the-Implementation" está deliberadamente ligado ao ecossistema Java, assim como ClojureCLR para .NET e ClojureScript para JavaScript.
fonte
À medida que o Clojure continua evoluindo, certamente criará mais e mais bibliotecas próprias, permitindo portas mais fáceis para outras VMs. No que diz respeito ao Clojure na JVM, acredito que o objetivo a longo prazo será substituir a maioria das bibliotecas por alternativas do Clojure (com essa imutabilidade por padrão, STM etc.), reduzindo a camada de interoperabilidade Java ao nível mais baixo de primitivos e base objetos como String. Isso será especialmente verdadeiro quando a plataforma Java for modularizada com o jigsaw / OSGi no Java 8 (2013)
No entanto, acredito que o Clojure ainda desejará tirar proveito do invokedynamic (introduzido como uma instrução de bytecode no Java 7) e adotará uma abordagem bastante pragmática sobre quais bibliotecas substituir quando (se o Java tiver uma lib perfeitamente boa, então por que mude cedo).
NOTA: Não estou envolvido profundamente na comunidade Clojure, portanto isso é parcialmente um boato / adivinhação.
fonte