Clojure Java'dan ne kadar bağımsız?

Clojure dünyasında oldukça yeniyim. Birinin Clojure birlikte çalışma özellikleri aracılığıyla tüm Java kitaplıklarına kolay erişimi olduğu gerçeğini takdir ediyorum, ancak Clojure'un kendi ayakları üzerinde ne kadar durduğunu merak ediyordum.

Tabii ki Android gibi, Java ile birlikte çalışabilirliğin her zaman gerekli olacağı bazı platformlar vardır, çünkü çekirdek kütüphaneler Java'da yazılır veya gösterilir. Ayrıca, Clojure dizeleri Java dizeleri olduğundan, dize düzenleme kitaplıklarının Java Dize yöntemlerinde bir sarıcı olmasını beklerim.

Ancak diğer görevler için yerel Clojure kütüphanelerinin geliştirilememesi için hiçbir neden göremiyorum. Http, tarih değiştirme, XML ayrıştırma, şablonlama, JSON serileştirme ve serileştirme, OAuth, matematik kütüphaneleri vb.

Benim sorum şu:

Clojure, Java ekosisteminden ne kadar bağımsız hale geldi? Bunların ve diğer görevlerin çoğu için kendi deyimsel kütüphaneleri var mı?

Clojure, kod tabanı büyüdükçe ve doğal olarak çeşitlendikçe Java kütüphanelerinden giderek daha fazla bağımsız hale geliyor. Clojure'un en büyük gücü Java'yı arayabilmesidir, bu nedenle gelecekte java kullanmayan Clojure kodunu görmek olası değildir. Olduğu söyleniyor, ben Java libs (komut satırı argümanlar, temel metin minupülasyon, vb) çağıran geliştirme iyi bir anlaşma yaptık. İşte saf clojure kütüphanelerinin listesi: http://www.clojure-toolbox.com/

Bence Clojure'un barındırılan bir dil olarak tasarlandığını ve şu anda üç uygulaması olduğunu söylemek doğru:

• Clovure üzerinde jvm
• .NET için ClojureCLR
• JavaScript'te ClojureScript

Barındırılan bir dil olarak tasarlandığından, deyim, altta yatan platformun kütüphanelerini mantıklı kılan, ancak aynı zamanda taşınabilir olan bir "çekirdek" kitaplık kümesi (mutlaka kod düzeyinde değil) kullanmaktır. Zamanla, her üç platformda da çok daha fazla Clojure kütüphanesi çalışacağını umuyorum, burada mantıklı.

Ben clojure.java.jdbc ve clj-time (JodaTime etrafında bir sarıcı) korumak böylece * CLR veya * Script sürümleri kullanmak mantıklı değil ama farklı ad alanlarında API uyumlu kütüphaneler bir olasılık olabilir.

"Saf" Clojure kitaplıklarının çoğunun * CLR veya * Script sürümlerinde kullanımı kolay olmalıdır.

OP'nin sorusuna: "Clojure-the-language" oldukça taşınabilir ancak "Clojure-the-application", ClojureCLR. NET'e ve ClojureScript'ten JavaScript'e kadar Java ekosistemine kasıtlı olarak bağlıdır.

Clojure gelişmeye devam ettikçe, kesinlikle daha fazla ve daha fazla kendi kütüphanesini oluşturacak ve diğer VM'lere daha kolay bağlantı noktaları sağlayacaktır. JVM'deki Clojure söz konusu olduğunda, uzun vadeli hedefin çoğu kütüphaneyi Clojure alternatifleriyle (böylece varsayılan olarak bu değişmezliğe, STM vb.) Değiştirmek ve Java interop katmanını en düşük ilkel ve taban seviyesine getirmek olacağına inanıyorum. String gibi nesneler. Bu, özellikle Java platformu Java 8'de jigsaw / OSGi ile modüler hale getirildiğinde (2013) geçerli olacaktır.

Bununla birlikte, Clojure'un hala invokeinamik (Java 7'de bir bayt kodu talimatı olarak tanıtıldı) denemek ve yararlanmak isteyeceğine ve hangi kitaplıkların ne zaman değiştirileceği konusunda oldukça pragmatik bir yaklaşım alacağına inanıyorum (Java mükemmel bir lib'e sahipse, o zaman neden erken değiştirin).

NOT: Clojure topluluğuna derinlemesine katılmıyorum, bu yüzden bu kısmen kulaktan dolma / tahmin.