Java funkcyjnie. Materiały

Radzę się uczyć od podstaw w lepszym języku, a dopiero potem wrócić do Javy. Haskell jest dobry do nauki na początek lub Scala.

Knigi co sam przeczytałem i daję stępel jakości:

• Programming in Haskell by Graham Hutton
• Functional Programming in Scala

W sumie nie ma tego dużo:

• Niemutowalność
• Rekurencja
• Funkcje jako wartości
• Funkcje wyższego rzędu i kombinatory
• Typy wyższych rzędów, typy algebraiczne
• Pattern matching, destructuring
• fold right, fold left, persystentne struktury danych, nieskończone strumienie danych
• Monoidy -> ... -> Monady wraz z przykładami: Option, Either, Try
• Notacja do (w Haskellu) lub for comprehension (w Skali)
• Efekty i transformery (czyli jak łączyć różne monady, oraz monady z Future)
• Funkcyjne projektowanie aplikacji np. property based tests czy ukrywanie IO za monadą
• Lenses
• Free Monad
• Continuation Passing Style

+- bo piszę z głowy. W Javie wiele z tego nie jest możliwe lub nie jest wygodne więc pozbywasz się połowy tematów.

W Scali polecam Functional Programming Simplified, Alvin Alexander: https://www.amazon.com/Functional-Programming-Simplified-Alvin-Alexander-ebook/dp/B076J7CJKY

Moim zdaniem jest fajnie napisana, w przeciwieństwie do Functional Programming in Scala (tej czerwonej).

Do Haskella: https://www.amazon.com/Get-Programming-Haskell-Will-Kurt/dp/1617293768

Zanim ktoś inny rzuci to "Category Theory for Programmers" Bartosza Milewskiego. Co prawda nie Java i nie projekty, ale programowanie funkcyjne się zgadza.

podpinam się pod @Saalin - wykłady Milewskiego nt. Category Theory

Wstępniak całkiem dobry, przez całość niestety nie przebrnąłem z braku odpowiednich trybików w głowie - czasem miałem wrażenie, że to o czym mówi to masło maślane, ale może się komuś przyda

Cala seria "functional programming in ..." jest dobra i przystepna dla poczatkujacych w moim odczuciu.

Programowanie funkcyjne w Javie to trochę jak driftowanie rowerem - naczytasz się o monadach, teorii kategorii, … a potem będziesz próbował to wcisnąć w smutny Javowy kodzik…

Niemniej fajnie jest nauczyć się czegoś nowego! Mi się bardzo podobał kurs ze Scali na Courserze, dzięki niemu nauczyłem się m.in. co to flatMap i nie straszyło mnie już to np. w RxJavie. Na pewno uczy to innego myślenia, co jest na plus. Kwestia zastosowania w Javie - raczej wyjdzie pokracznie i nieczytelnie.

Kwestia zastosowania w Javie - raczej wyjdzie pokracznie i nieczytelnie.

Niestety, tak właśnie jest.

Problem taki, że imperatywna alternatywa wychodzi czytelnie, tylko rzyga błędami na produkcji. Dodajmy do tego jeszcze nutkę magii, która nie ułatwia rozwiązywania i wykrywania problemów i mamy ładne piekiełko. Ale przynajmniej dobrze płatne.

Przy okazji - jako, że OP pytał o "projekty".
Mój przykład (server ponga) z czasów kiedy jeszcze wierzyłem w funkcyjną javę ( dawno i niedawno):
https://github.com/javaFunAgain/ratpong

@jarekr000000: prawie jestem pewien, że alternatywa funkcyjna nie rzyga błędami na produkcji tylko i wyłącznie dlatego, że jest popularna wśród ludzi, którzy ją znają i rozumieją. Kiedy Haskel trafi do mainstreamu i trafi ci się projekt napisany przez przysłowiowych Hindusów pod kierownictwem przysłowiowych niemieckich architektów to zobaczysz dziwy w kodzie i na produkcji, o których nie śniło się waszym ewangelistom.

wartek01 napisał(a):

Kiedy Haskel trafi do mainstreamu i trafi ci się projekt napisany przez przysłowiowych Hindusów pod kierownictwem przysłowiowych niemieckich architektów to zobaczysz dziwy w kodzie i na produkcji, o których nie śniło się waszym ewangelistom.

Musiałem docenić, bo to prawda. Ale teraz mam dylemat - czy powinienem zaprzestać tej funkcyjnej propagandy (fp) i promować pisanie imperatywne, po to aby w moim skromnym Haskellowo / Scalowym poletku nie zalęgli się seniorzy tylko z nazwy i germańscy architekci?

@wartek01: Dziury w logice biznesowej mozna wszedzie zrobic. Ale bledow z NPE, czy takich zwiazanych z AOP albo mutowalnoscia (i tak dalej i tak dalej), mozna uniknac zmieniajac jezyk.

@jarekr000000: no ja jestem jednak idealistą i marzy mi się świat, w którym o dogmatach programowania (od "który paradygmat jest najlepszy" poprzez dyskusję o dobrych praktykach) dyskutuje się dopiero po ustaleniu takiej prozaicznej kwestii jak problem, jaki rozwiązujemy. Inne praktyki powinny obowiązywać przy przejmowaniu dużego molocha biznesowego, inne przy pisaniu aplikacji biznesowej od zera, inne przy pisaniu ogólnodostępnego API, a inne przy przetwarzaniu dużych ilości danych w czasie rzeczywistym.

FP samo w sobie uważam za fajne i faktycznie zbyt mało popularne - bo istnieje całkiem sporo problemów, które da się rozwiązać pisząc funkcyjnie lepiej niż pisząc np. imperatywnie. Fajnie by było, żeby ludzie mieli ten klucz z napisem "functional programming" w swojej skrzynce z narzędziami - bo jeśli ktoś nigdy z tym się nie zetknął to nigdy nie będzie wiedział, że tego można używać.

Natomiast nie lubię przedstawiania takiego jednego rozwiązania jako złotego młotka na wszystko. To doprowadzi do sytuacji w której ludzie usłyszą na konferencji "trzeba robić X bo Y tak mówił" przez co skończymy z jakąś inną formą idiotyzmu.

@stivens: błędów związanych z AOP można bardzo łatwo uniknąć - nie korzystając z bibliotek do AOP.

Co do NPE to temat na trochę szerszą dyskusję (zaczynając od tego czy null w ogóle jest potrzebny czy nie - IMO jest, pomimo tego, że zgadzam się z większością argumentów z Billion Dollar Mistake). Ale null-safety możesz mieć nie tylko w FP.

Ja to widzę tak, duże firmy pokroju Google prowadzą różnego rodzaju badania, nie wiem co by im szkodziło zrobić takie że N zespołów pisze w podejściu funkcyjnym, N w obiektowym, N w imperatywnym, a N jest grupą kontrolną - pracują jak zazwyczaj. Zespoły należałoby wcześniej przeszkolić w danym podejściu. Po roku można zmierzyć ilość bugów, problemów, szybkość dostarczania - zwłaszcza że przy skali Google można tym zespołom dać dokładnie te same systemy do napisania i potem load-balancować ruch po równo do nich wszystkich. Dałoby to przybliżony obraz który paradygmat jest lepszy.

W mojej opinii język ma spory wpływ na produktywność zwłaszcza gdy porównujemy C z Kotlinem.
Biblioteka standardowa (a zwłaszcza jej jakość oraz dokumentacja, StackOverflow) ma bardzo duży wpływ na produktywność.
Popularność, zwłaszcza ilość rozwiązanych problemów ma średni wpływ na produktywność (np. jak coś zapiąć w Maven'ie).
IDE, dbg, profilery oraz otoczka package/deploy ma niewielki wpływ na produktywność ale może podnieść komfort pracy (refactoringi).

Haskell vs Java: Haskell poza byciem super językiem przegrywa na wszystkich frontach, także przewiduje że dobry zespół haskellowców poległby w starciu ze światem rzeczywistym gdzie trzeba się wpiąć w AD, generować PDFy oraz zip'y z CSVkami, wpychać dane do MongoDB i rozpoznawać barcode'y.

0xmarcin napisał(a):

Haskell vs Java: Haskell poza byciem super językiem przegrywa na wszystkich frontach, także przewiduje że dobry zespół haskellowców poległby w starciu ze światem rzeczywistym gdzie trzeba się wpiąć w AD, generować PDFy oraz zip'y z CSVkami, wpychać dane do MongoDB i rozpoznawać barcode'y.

To ostatnie to biblioteki. I ma to faktycznie duży wpływ. Obecne w haskellu znajdziesz biblioteki do wszystkiego (https://hackage.haskell.org/package/HPDF).
Niestety bardzo często są to biblioteki słabej jakości - brakuje dokumentacji, ficzerów i często mają źle zrobiony build (przez to się robi dependency hell).

To jest główny szok kulturowy po przejściu z Javy (tu akurat Kotlin, Scala i inne jvm mają tą przewagę, że nadal biblioteki javowe działają).

Tym niemniej, tu Haskell był wymieniony w kontekście uczenia się fp - to nadal IMO najprostsza droga.
Produkcyjny haskell i problemy to inna historia (u mnie działa :-), ale nie jest tak, że wszystko jest piękne - nawet sam język ma baaaardzo słabe punkty).

duże firmy pokroju Google prowadzą różnego rodzaju badania, nie wiem co by im szkodziło zrobić takie że N zespołów pisze w podejściu funkcyjnym, N w obiektowym, N w imperatywnym, a N jest grupą kontrolną - pracują jak zazwyczaj.

Moim zdaniem jest za duża wariancja - N musiałoby być potężne. Jak założymy, że mają robić projekty "kontrolne" to koszt się robi kosmiczny.
Ileś razy widziałem zespoły, które zatrzymały się na dewelopmencie z powodu kompletnie małego wypadku, technicznego lub nawet organizacyjnego.

Większość książek o funkcyjnej Javie to tak naprawdę książki o Javie 8 - czyli o streamach i lambdach.
Wyjątkiem jest https://www.manning.com/books/functional-programming-in-java
w której autor tworzy własny DSL na potrzeby FP. Trochę poszerza horyzonty, ale jak wspomniano wyżej podejrzewam że na produkcji komunikaty błędów będą przy takim DSL nie do ogarnięcia.
Jakąś nadzieję budzi to: https://leanpub.com/functional-java-with-vavr
ale jeszcze nie czytałem.

vpiotr napisał(a):

w której autor tworzy własny DSL na potrzeby FP. Trochę poszerza horyzonty, ale jak wspomniano wyżej podejrzewam że na produkcji komunikaty błędów będą przy takim DSL nie do ogarnięcia.

Trochę mit.

1. ludzie potrafią ogarnąć czasem stack trace ze springa z hibernatem - gdzie masz kilkaset linijek (o ile nie utnie) i żadna z nich z twojego kodu (lubię ten przypadek),
2. wszelkie reactory, rxjavy itp - podorabiały się dobrego supportu do diagnostyki i debugu. Problem jest naprawialny, ale oczywiście w naiwnie zrobionej bibliotece - na potrzeby akademickie - jakieś tam problemy będą.

vpiotr napisał(a):

Większość książek o funkcyjnej Javie to tak naprawdę książki o Javie 8 - czyli o streamach i lambdach.

Wyjątkiem jest https://www.manning.com/books/functional-programming-in-java
w której autor tworzy własny DSL na potrzeby FP. Trochę poszerza horyzonty, ale jak wspomniano wyżej podejrzewam że na produkcji komunikaty błędów będą przy takim DSL nie do ogarnięcia.
Jakąś nadzieję budzi to: https://leanpub.com/functional-java-with-vavr
ale jeszcze nie czytałem.

Ten magiczny DSL to trochę pokręcona wariacja na temat vavra (czy javaslang jak to się chyba wtedy nazywało) jedyne co było tam strasznie magicznego to tool do robienia rekurencji na stercie zamiast na stosie :D ale powinno udać się zrobić sensowne logowanie dla czegoś takiego. To jednak tylko lista wywołań lambd zapisana na stercie
Bardziej bym się przejmował czy produkcyjny GC wytrzyma te wszystkie haskellowe kombinacje które proponował w tej książce :P

KamilAdam napisał(a):

Bardziej bym się przejmował czy produkcyjny GC wytrzyma te wszystkie haskellowe kombinacje które proponował w tej książce :P

Ja mam trochę takiego kodu ostro zakręconego - funkcyjny do zarypania kotlin + reactor i np. mielenie tysięcy PDFów lub jakichś koszmarnych XMLi. Działa ok, choć były momenty kiedy walczyłem żeby zmieścić się w RAM na serwerze.