Jak niezależny jest Clojure od Javy?

13

Jestem całkiem nowy w świecie Clojure. Doceniam fakt, że można łatwo uzyskać dostęp do wszystkich bibliotek Java za pośrednictwem funkcji Clojure interop, ale zastanawiałem się, ile Clojure stoi na własnych nogach.

Oczywiście istnieją pewne platformy, takie jak Android, gdzie zawsze wymagana będzie interoperacyjność z Javą, ponieważ podstawowe biblioteki są napisane lub udostępnione w Javie. Ponadto, ponieważ ciągi Clojure są ciągami Java, spodziewam się, że biblioteki do manipulacji ciągami będą opakowaniem metod Java String.

Ale w przypadku innych zadań nie widzę powodu, dla którego natywne biblioteki Clojure nie mogły zostać opracowane. Pomyśl o HTTP, manipulacji datami, analizie XML, szablonowaniu, serializacji i deserializacji JSON, OAuth, bibliotekach matematycznych i tak dalej.

Więc moje pytanie brzmi:

Jak daleko Clojure stało się niezależne od ekosystemu Java? Czy ma własne biblioteki idiomatyczne do większości tych i innych zadań?

Andrea
źródło
ClojureCLR to port Clojure do frameworku .Net.
SL Barth - Przywróć Monikę
1
Według mojego gustu zbyt dużo rdzenia Clojure jest zaimplementowane w Javie, nie jest poprawnie ładowane.
SK-logic
@Barth: Wiem, że istnieją porty do innych platform, ale to niewiele mówi o pytaniu. Może działać na CLR i nadal nie ma własnych bibliotek.
Andrea
1
@JeremyHeiler, oczywiście każdy, kto ma zdrowy rozsądek, próbowałby osiągnąć taki cel. Pytanie brzmi - dlaczego Clojure nie był wdrażany w ten sposób od samego początku? To o wiele łatwiejsze niż kodowanie kompilatora w Javie.
SK-logic
1
@ SK-logic, Z tego, co mogę powiedzieć, funkcje, które Rich Hickey chciał, aby poprawnie uruchomić Clojure, zajęły sporo czasu. Oznacza to, że nie chciał spieszyć się z decyzjami projektowymi, które mogłyby negatywnie wpłynąć na język, decyzjami, które potencjalnie mogłyby przynieść lepsze wyniki, gdyby więcej czasu poświęcono na zastanowienie się nad tym, jak pewne funkcje mogą działać. Może jestem całkowicie zaniedbany, ale takie jest moje zdanie na ten temat.
Jeremy Heiler

Odpowiedzi:

2

Clojure staje się coraz bardziej niezależny od bibliotek Java, ponieważ jego baza kodu rośnie i naturalnie się różnicuje. Główną zaletą Clojure jest to, że może on wywoływać Javę, więc zobaczenie kodu Clojure w przyszłości, który nie korzysta z java, byłoby mało prawdopodobne. To powiedziawszy, zrobiłem sporo prac rozwojowych bez wywoływania bibliotek Java (argumenty linii poleceń, podstawowa minupulacja tekstu itp.). Oto lista czystych bibliotek clojure: http://www.clojure-toolbox.com/

wespiserA
źródło
Wybrałem tę odpowiedź dzięki linkowi do repozytorium czystych bibliotek Clojure.
Andrea
7

Myślę, że można śmiało powiedzieć, że Clojure został zaprojektowany jako język hostowany i ma teraz trzy implementacje:

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

Ponieważ jest zaprojektowany jako język hostowany, idiomem jest wykorzystanie bibliotek platformy, tam gdzie ma to sens, ale także zapewnienie zestawu „rdzeniowych” bibliotek, które są przenośne (z pov użycia, niekoniecznie na poziomie kodu). Oczekuję, że z czasem zobaczymy o wiele więcej bibliotek Clojure działających na wszystkich trzech platformach, o ile ma to sens.

Utrzymuję clojure.java.jdbc i clj-time (wrapper wokół JodaTime), więc nie ma sensu używać tych w wersjach * CLR lub * Script, ale biblioteki kompatybilne z API w różnych przestrzeniach nazw mogą być możliwe.

Wiele „czystych” bibliotek Clojure powinno być już dostępnych w wersjach * CLR lub * Script.

Na pytanie OP: „Clojure-the-language” jest dość przenośny, ale „Clojure-the-Implementation” jest celowo związany z ekosystemem Java, podobnie jak ClojureCLR na .NET i ClojureScript na JavaScript.

Sean Corfield
źródło
2

W miarę rozwoju Clojure z pewnością będzie budować coraz więcej własnych bibliotek, umożliwiając łatwiejsze porty dla innych maszyn wirtualnych. Jeśli chodzi o Clojure w JVM, wierzę, że długoterminowym celem będzie zastąpienie większości bibliotek lib alternatywnymi rozwiązaniami Clojure (tym samym posiadając domyślnie tę niezmienność, STM itp.), Sprowadzając warstwę interakcji Java do najniższego poziomu prymitywów i bazy obiekty takie jak String. Będzie to szczególnie prawdziwe, gdy platforma Java zostanie zmodularyzowana za pomocą jigsaw / OSGi w Javie 8 (2013)

Uważam jednak, że Clojure nadal będzie chciał skorzystać z invokedynamic (wprowadzonego jako instrukcja kodu bajtowego w Javie 7) i przyjmie dość pragmatyczne podejście do tego, które biblioteki zamieniać kiedy (jeśli Java ma idealnie dobrą bibliotekę, to dlaczego zmień to wcześnie).

UWAGA: Nie jestem głęboko zaangażowany w społeczność Clojure, więc jest to częściowo pogłoska / zgadywanie.

Martijn Verburg
źródło