Zapytany o Clojure na gtalku - Jaki on jest? Warty naszego czasu?

Coraz częściej wokół mnie pojawia się pytanie o sens nauki Clojure. Tym razem padło na gtalku, więc po odpowiedzi, postanowiłem ujawnić ją (niedługą!) na blogu pro publico bono. Komentarze mile widziane.

ON: Hej Jacku. Pozwolę sobie tak zadać jedno konkretne pytanie. Bazując na Twojej wiedzy i doświadczeniu. Clojure jest: fajne, ciężkie, przereklamowane, rewolucyjne, tego mi było trzeba, daje duże możliwości (nie potrzebne skreślić) :-)

JA: Gdybym miał wybierać z podanego zbioru, wybrałbym na pewno: fajne i rewolucyjne. Do dwóch ostatnich muszę się przekonać, ale tak jest reklamowane. Ktoś powiedział, że "jeśli język programowania nie wymaga zrewolucjonizowania myślenia, to nie warto się go uczyć". Można to przypisać do każdej z naszych działalności, nie tylko nauki nowego języka programowania, czy technologii. Dla mnie Clojure jest po prostu boski (dla wielu takim jest Ruby czy Scala, ale są one z mojego punktu widzenia jedynie ewolucyjne - Clojure jest Rewolucyjne).

ON: No może jeszcze jedno. Czy obecnie Clojure i biblioteki może być stosowane do "prawdziwych' web aplikacji? Bo mi się kojarzy to tylko i wyłącznie do bibliotek server side

JA: Zacznij od compojure, któremu się przyglądam. Możesz również skorzystać z sandbar. To są dedykowane biblioteki/rozwiązania na potrzeby aplikacji webowych. Jeśli do tego dodać, że Clojure to Java, a raczej swego rodzaju DSL do Javy (bo ostatecznie i tak mamy bajtkod i jesteśmy nim ograniczeni), to czy Clojure czy Java nie ma wielkiego znaczenia w kontekście gotowości szkieletów webowych. Każdy się nadaje. Warto jednak skorzystać z możliwości Clojure i nie łatać, a łączyć, czyli...compojure albo sandbar.

ON: Hmm, w zasadzie skoro Clojure operuje na JVM to po co dedykowany web framework do niego? Czy nie można po prostu skorzystać z HTML, JS i w jakiś sposób (mam nadzieję, ze jakoś się da) wystawić REST serwisy? W zasadzie powinno dać się mieszać Clojure ze Scalą i Groovy :-) 

JA: Nie czuję się w pełni przygotowany do odpowiedzi na to pytanie, bo pewnie, gdybym znał odpowiedź, stworzyłbym jej realizację - nowy szkielet webowy bazując na dotychczasowych doświadczeniach w JEE. Z mojej perspektywy funkcyjnej wygląda jednak, że celem dowolnego "web framework" jest uproszczenie tworzenia aplikacji i konstrukcje języka mogą w tym bardzo pomóc, np. w Clojure mamy makra, które operują na danych podczas kompilacji, zamiast funkcjach, które operują podczas uruchomienia. Łącząc obie konstrukcje języka możemy stworzyć rozwiązanie - szkielet webowy, w którym zadeklarowanie obsługi żądania sprowadzi się do 2-3 zrozumiałych linii zamiast 20-30 niekoniecznie zrozumiałych (chociażby przez swoją objętość). W końcu, w programowaniu funkcyjnym nie chodzi o to jak, ale co.

Problem z dotychczasowymi szkieletami webowymi to, że bierzesz wszystko, albo masz kłopoty. Trudno skorzystać z części i wyskoczenie poza ramy może być bolesne, a już połączenie z innymi rozwiązaniami może przyprawić o ból głowy. Stąd też różnica między rozwiązaniami typu szkielet (framework) a rusztowanie (scaffolding). Pierwsze zostanie na wieki, drugie wyrzucasz, kiedy nabierzesz wprawy i doświadczenia, albo kiedy zorientujesz się, że są prostsze rozwiązania.

W Clojure forowane podejście polega na łączeniu mniejszych cegiełek do zrealizowania tworzenia aplikacji webowych. Tu nie ma pytania: Seam vs Struts2 vs Wicket vs JSF, ale składa się rozwiązania, aby obsłużyć bardziej skomplikowany problem - w końcu wszystko w Clojure jest funkcją, albo idąc dalej, strukturą danych, np. listą. Jeśli składanie funkcji matematycznych jest powszechnie stosowane i zrozumiane, to dlaczego tworzenie oprogramowania takim nie może być?!

Odnośnie REST Web Services i łączenia ze Scalą i Groovy, uchylam się od odpowiedzi. Za mało mam jeszcze zrozumienia, gdzie i jak mógłbym zastosować Clojure, aby łączyć go z Javą i wykorzystania z JEE, a gdzie tu jeszcze dokładać do tego Scalę i Groovy.

ON:...dopiero do niego wysłałem odpowiedź, więc ciąg dalszy nastąpi...kiedyś.