Wrażenia z 70. spotkania WJUG - Clojure i ja w akcji...zaginęliśmy?

To była dopiero przeprawa - droga przez męki dla słuchających mojego wystąpienia podczas 70. spotkania Warszawa JUG.

Zaczęliśmy około 18:10 z projektorem, który komunikatem o swojej niedyspozycji (coś związanego z wentylatorem, czy innym swoim podzespołem) zajął połowę wyświetlanego slajdu, centralnie. Próbowałem udać, że nie powinno popsuć nam to spotkania.

Pamiętając moje dokonania na polu utrzymania czasu prezentacji i że wielu przykłada do tego równie wielką wagę, jak do strony merytorycznej, poprosiłem uczestników, abyśmy równo o 19:30 zakończyli spotkanie. Od tej godziny, wyjście z sali nie mogło być okraszone złowrogim spojrzeniem prowadzącego. Takie ukonstytuowaliśmy prawo. Bez względu na miejsce w mojej prezentacji, 19:30 stała się godziną graniczną chyba, że znajdą się tacy, którzy poproszą o więcej. I tacy się znaleźli! Wtedy się dopiero zaczęło bezpardonowe zmaganie z czasem. Skończyliśmy o 21:15 w sali, w gronie około 15 osób , aby kończąc dyskusje przy wejściu - tym razem już w gronie 7 osób - zakończyć całość około 21:45. W domu pojawiłem się po 22:00 (!)

Gdyby tylko liczba uczestników, dyskusje i poszczególne czasy na odcinkach - właściwa prezentacja, dyskusje po, w sali i przy wejściu, miały być wyznacznikiem sukcesu, powiedziałbym, że był ogromny. Zawsze uważam z przymiotnikami, które podobnie jak gusta, mają różne zabarwienia dla różnych ludzi, ale tym razem nic poza "ogromny" nie przychodzi mi do głowy.

Merytorycznie? Cóż, mogło być lepiej. Z mojego "prezenterskiego" punktu widzenia nie popisałem się. To znaczy, popisałem się, ale niewiedzą, a to zdecydowanie nie było tematem spotkania. O Clojure było conieco, może trochę więcej o samym programowaniu funkcyjnym i w zdecydowanej przewadze wiele o (bez?)sensowności użycia Clojure w projektach, które obecnie są przez nas obsługiwane Javą.

Tutaj sypiąc głowę popiołem, kajam się przed uczestnikami, prosząc o wybaczenie, że dałem się ponieść próbie porównywania Clojure do Javy, kiedy wcale nie byłem do tego przygotowany, a w dodatku, wcale nie miałem zamiaru tego robić (!) Języka Java zacząłem uczyć się w czasach appletów, kiedy to one były jedynym sposobem, aby ożywić strony HTMLowe. To była era wszechobecnego CGI z perlem i znajomość rozwiązania tego akronimu albo umiejętność wyjaśnienia, o co w nim chodzi znaczyły wiele (coś, co teraz porównałbym do Java EE i zasad rządzących serwerami aplikacyjnymi). Java z appletami była czymś praktycznym i w zasadzie nie było innego wyboru. Obecnie nie ma tego luksusu - nie tylko, że wybór jest między .Net a Java EE, ale mnogość rozwiązań w samej Javie - czy to języki programowania (ale tutaj można założyć, że zaleca się Javę), czy szkieletów aplikacyjnych - może przyprawić o ból głowy. Jest zauważalnie trudniej wejść nowicjuszowi w świat języka Java i Java EE. I gdzie tu miejsce dla poznawania programowania funkcyjnego i to jeszcze w wykonaniu Clojure. Ma to jakiś sens?

To nie było pytanie, na które zamierzałem odpowiedzieć i nie odpowiedziałem.

Tematem mojej prezentacji był "Wstęp do programowania funkcyjnego z Clojure". Podkreślam słowo "wstęp" i rezerwowałem sobie wręcz rozumienie go jako "wstęp do wstępu". Raczej służyło to zebraniu postrzegania nauki innego paradygmatu programowania niż imperatywno-obiektowy w wykonaniu Javy. Postarałem się o wdrożenie podejścia "Release early, release often", z tym, że tym razem chodziło nie o namacalny produkt, a wiedzę.

Jakkolwiek moja strona prezentacyjna szwankowała, to uważam, że strona przeciwna (w sensie analogicznym do pary lewa-prawa a nie za-przeciw), czyli słuchacze, spisała się wyśmienicie. Na sali znalazło się 5 osób, które na pytanie "Czy programujesz w języku funkcyjnym?" odpowiedziały "Tak" - dwie czysto hobbistycznie, jedna programująca w Clojure w Fablo.pl, inna, która właśnie przeszła (jak to ujęła) z "naukowego" Haskella na bardziej finansowo-zorientowaną Scalę i ostatnia, która swoją przygodę z programowaniem zaczęła od programowania funkcyjnego i, jak się okazało później, zna około 30 języków programowania z Javą okrzykniętą jako ten język, który nie tylko, że ma się dobrze, ale będzie wiodącym przed długie lata. Pozostała, bodajże 35-cioosobowa, grupa to programiści Java, którzy albo mieli zajęcia z programowania funkcyjnego na studiach, albo przymierzają się do języka Scala, albo kto wie, co w pozostałych głowach siedzi.

Rozmawialiśmy o wsparciu IDE dla programowania funkcyjnego w dowolnym języku - przewijał się Groovy, Scala i Clojure, naprzemiennie. I można było zauważyć ogólnie panujące przekonanie, że brak wsparcia IDE w postaci podpowiedzi, refactoringu, przeglądania hierarchii klas w górę/dół, przeskakiwania między wywołaniem funkcji, a jej definicją, w zasadzie skreśla język jako możliwy do zastosowania w projekcie komercyjnym, w którym "więcej się czyta kod niż pisze". Tego nie brałem wcześniej pod uwagę, a to kładę na karb mojego, niewielkiego udziału w projektach programistycznych. Pojawiła się teza, że przy pewnej skali projektu, można przyjąć sensowność użycia dynamicznie-typowanego języka zamiast Javy, powiedzmy przy 100k linii kodu (wartość wyjęta z kapelusza, ale ma być dostatecznie mała, aby dało się to ogarnąć). Mieszanie składniowe języków na JVM, np. Java i Clojure, w projekcie nie zdobyło entuzjazmu, przede wszystkim dlatego, że późniejsze utrzymanie może znacząco podnieść koszty. Sensowne rozumowanie, z którym trudno się nie zgodzić.

Zaprezentowałem Clojure z mojego, javowego punktu widzenia, który pozwala mi tworzyć rozwiązania Java EE z aplikacjami webowymi w roli głównej. Tutaj Java ma się świetnie i jakkolwiek mamy do dyspozycji Grails z Groovy, Lift ze Scala, Ruby on Rails z JRuby, to nie zauważyłem akceptacji wśród uczestników dla ich powszechnego stosowania, przede wszystkim z powodu obecnego stanu wsparcia narzędziowego i późniejszego utrzymywania mieszanki składniowej Java-nieJava. Uknęliśmy wręcz termin "podejście dogmatyczne", któremu przyświeca minimalizowanie języków na JVM ze wskazaniem na Javę.

Gdybym ja był słuchaczem, nie dostrzegłbym sensu nauki programowania funkcyjnego, a już tym bardziej Clojure.

Podczas mojego wystąpienia o Clojure nie pokazałem niestety nic, co nie byłoby możliwe w Javie i Java EE, a biorąc wsparcie narzędziowe i ogólny stan świadomości programistycznej o nich, to, wespół z moim prawie zerowym teoretycznym, a zerowym, praktycznym doświadczeniem, takie podejście nie miało racji zaistnienia. Za dużo jeszcze we mnie myślenia javowego, a za mało Clojure i PF. Kiedy dodać do tego brak prezentacji chociażby Clojure STM i tak podkreślanej prostoty zrównoleglania zadań w językach funkcyjnych, rozumowanie, że da się zrobić w Clojure, to, co potrafimy i robimy na codzień w Javie jest dalece niewystarczająca. Jest niewystarczające również, aby myśleć o nauce, której nie towarzyszy przeświadczenie, albo chociaż nadzieja na możliwe, przyszłe użycie praktyczne. Pełna zgoda i tutaj upatruję swoje braki. Chociażby Clojure STM jest rozwiązaniem do użycia z poziomu Javy, jako biblioteka i tu właśnie widziałbym sens prezentacji Clojure jako wzbogacenia naszego przybornika programisty. To da się użyć natychmiast. Później dopiero widziałbym ewangelizację Clojure przez pryzmat zrównoleglania, a w kolejnych odsłonach i tylko przy założeniu, że poprzednie są zrozumiałe, a być może i wykorzystywane, wchodziłbym w temat innej składni i samego programowania funkcyjnego w ogólności. To jest moja nauka na przyszłość, która wyznacza dalsze kierunki rozwoju w Clojure.

Z pozostałych tematów, które uczestnicy wyrazili jako wartościowe do pokazania w ramach naszych spotkań Warszawa JUG pojawiły się: testowanie, refactoring, wykorzystanie skryptu jako klasy, jak efektywny jest bajtkod Clojure, monady z przykładami, TCO w rekurencjach na przykładzie chociażby ciągu Fibonacciego i równoległe rysowanie kółek. Ze swej strony dodam do tego: demonstracja siły przeładowywania definicji funkcji w locie, w trakcie tworzenia oprogramowania, bez konieczności restartu środowiska uruchomieniowego oraz możliwość poznawania API Javy z użyciem Clojure REPL.

Tym samym chciałbym podziękować wszystkim uczestnikom za udział w mojej prezentacji Clojure i towarzyszące temu, niezwykle inspirujące dyskusje. Dziękuję również za cierpliwość podczas lektury tego wpisu. Ryzykuję, że zabrzmię banalnie, ale współpraca z Wami to czysta przyjemność dająca mi wiele satysfakcji. Pewnie już zwyczajowo, ale wciąż z serca, wszystkim życzę podobnych doznań.

Prezentacja dostępna jest do pobrania jako JacekLaskowski-WJUG-Wstep-PF-Clojure-19.10.2010.pdf.

Jeśli przychodzi Wam do głowy temat warty omówienia podczas spotkań JUGowych, piszcie. Ustawiam się w roli zdającego relację z postępu moich prac podczas kolejnych spotkań. Wy przywdziewacie szaty zlecających i jednocześnie egzaminujących wyniki. Czyż to nie idealny sposób na naukę dla obu stron?! "Ucząc się uczę", albo "Ucząc uczę się". Nie wierzę, że nie znajdzie się ochotnik, aby skorzystać z oferty.

Kolejne spotkanie za 2 tygodnie. Chętni? W przypadku braku, zakładam, że oddaje mi się pola na rzecz dalszego przedstawiania wad i zalet programowania funkcyjnego z Clojure. Z góry dziękuję i rezerwuję sobie prawo, do skorzystania jedynie w ostateczności.

p.s. Do warsjawy 2010 pozostały 3 dni. Do tej pory zarejestrowało się już ponad 150 osób (dokładnie 151 - stan na godzinę 11:00)! Skala zainteresowania sobotnią konferencją przeszła najśmielsze oczekiwania organizatorów. Niech będzie ona równie wartościowa dla prelegentów, jak moje wczorajsze wystąpienie dla mnie, a uczestników proszę o podobny poziom aktywności. Parafrazując słowa Owsiaka "Oj, będzie się działo!"