Hej,
Od jakiegoś czasu noszę się z zamiarem przybliżenia się do paradygmatu funkcyjnego. Z pragmatycznego punktu widzenia (uwzględniając przede wszystkim rynek pracy), na co lepiej zwrócić uwagę? Vavr czy Scala? Może jakiś inny język funkcyjny? Proszę o możliwie wnikliwe elaboraty! :)
W obu szansa na pracę jest dość niska ;)
Może haskel?
Ja bym jeszcze wziął pod uwagę clojure.
https://clojure.org/
https://hnhiring.com/technologies/clojure
Czy ja wiem czy niska. W Krakowie niejedna firma szuka Scalowca. Poza tym Scala > Kotlin > Java jeżeli chodzi o pisanie funkcyjne. W Javie jest tyle boilerplate'u że szybko Ci się odechce. :D
vavr to mniej więcej kopiuj wklej ze standadrowej biblioteki Scali (podstawowe monady Try/Either/Option + kolekcje niemutowalne + tuple i funkcje), więc jeśli nauczysz się używać jednego to drugie też szybko załapiesz.
Większy problem to jest to że ani jedno ani drugie nie dostarcza sposobu do pisania kodu czysto funkcyjnego (czyli monady IO) oraz ładnego sposobu do pisania kodu asynchronicznego (czyli monady Task).
IHMO w miarę prawdziwe programowanie funkcyjne zaczyna się od bibliotek Scalaz, Cats, ARROW, ZIO lub Functiona Java
jak chcesz sie nauczyc pisac funkcyjnie to wez sie za haskella i potem sobie wdrazaj takie praktyki w projektach. jakos nigdy w tym kierunku specjalnie sie nie pakowalam ale na tyle na ile mialam do czynienia z projektami uzywajacymi fp:
a) w lepszych firmach/zespolach jest dosc mocna tendencja na pisanie javy funkcyjnie (co jest oczywiscie ograniczone i czesto przekombinowane bo java jest strasznie buracka jesli chodzi o skladnie i typowanie)
b) projekty w scali czesta sa pisane przez javowcow i w "javowym stylu" przez lepiej moze byc jednak isc w a)
najwiecej chyba zalezy od ciebie, jak sie naumiesz dobrych praktych to zespol/firma nie bedzie ci raczej przeszkadzac, beda sie tez bali wchodzic w dyskusje bo znajomosc monad jednak budzi respekt ;)
Kamil Żabiński napisał(a):
vavr to mniej więcej kopiuj wklej ze standadrowej biblioteki Scali (podstawowe monady Try/Either/Option + kolekcje niemutowalne + tuple i funkcje), więc jeśli nauczysz się używać jednego to drugie też szybko załapiesz.
Większy problem to jest to że ani jedno ani drugie nie dostarcza sposobu do pisania kodu czysto funkcyjnego (czyli monadyIO) oraz ładnego sposobu do pisania kodu asynchronicznego (czyli monadyTask).
IHMO w miarę prawdziwe programowanie funkcyjne zaczyna się od bibliotek Scalaz, Cats, ARROW, ZIO lub Functiona Java
Taka naprawdę super czysta czystość to brak jakichkolwiek efektów ubocznych, czyli brak obserwowalnego efektu działania programu (oprócz zużycia zasobów) ;]
Monady IO w przeciwieństwie do niemutowalnych struktur danych nie mają jasnych zalet (przynajmniej dla mnie). Przy monadach IO efekty uboczne i tak masz i masz mniej więcej te same problemy co w kodzie nieopakowującym efekty uboczne w abstrakcje. Możesz nawet napisać automat, który kod imperatywny zamieni na kod monadyczny 1:1 (tzn za pomocą monad IO możesz emulować mutowalność struktur danych, zmiennych lokalnych, stosu, itp itd). Ja tam nie jestem specjalnie przekonany do opakowywania wszystkiego w monady IO.
Jak dla mnie Scala jest takim trochę złotym środkiem - z jednej strony udostępnia masę niemutowalnych struktur danych z dobrą wydajnością (dzięki structural sharing w kolekcjach) oraz sporo mechanizmów umożliwiających funkcyjne abstrakcje (typy wyższych rzędów, rekurencja ogonowa, implicity, etc), a z drugiej nie zmusza mnie do pakowania się w monady IO na każdym kroku.
Ponadto nie ma jedynej słusznej monady IO. zio to nowe podejście do monad IO, które zmniejsza użycie monad transformers. Monada IO w zio to taka super-monada, łącząca wiele aspektów - izolacja efektów ubocznych, wartości opcjonalne, asynchroniczność, obsługa błędów, planowanie i zarządzanie zadaniami, itd Kiedyś to było rozczłonkowane na wiele monad łączonych tymi monad transformers co było uciążliwe.
beach_boy napisał(a):
Hej,
Od jakiegoś czasu noszę się z zamiarem przybliżenia się do paradygmatu funkcyjnego. Z pragmatycznego punktu widzenia (uwzględniając przede wszystkim rynek pracy), na co lepiej zwrócić uwagę? Vavr czy Scala? Może jakiś inny język funkcyjny? Proszę o możliwie wnikliwe elaboraty! :)
Ja bym wjechał w Haskella. Co prawda pracy w PL to raczej nie uświadczysz ale chyba nie ma bardziej hardcorowego funkcyjnego. Inna sprawa to projekty. Co innego onsite, a co innego remote z drugiego końca świata. Wybór należy do Ciebie.
Jak mam do wyboru bibliotekę czy język do nauki FP to wybrał bym język.
Tyle, że sensowny wybór jest szerszy:
https://en.wikipedia.org/wiki/List_of_programming_languages_by_type#Functional_languages
A to Kotlin już nie na topie?
Konfederat napisał(a):
A to Kotlin już nie na topie?
"łatwiej" chyba sie pouczyć funkcyjnego paradygmatu na czymś co go wymusza. W kotlinie możesz pisać imperatywnie bez problemu
Jestem jak Linus Torvalds żaden z nowych języków programowania mnie nie ujął.
A czy w ogóle są jakieś naprawdę nowe języki programown?
Oczywiście wszystkie języki zrzynają także między sobą i między grupami na jakie je tu podzieliłem (np. Clojure i Scala z Haskella) . Biorąc to wszystko pod uwagę zastanawiam się czy istnieje jakiś naprawdę nowy język programowania. Taki który zawierałby idee młodsze niż 20 lat? Może prawa własności obiektów w Ruscie?
Biorąc to wszystko pod uwagę zastanawiam się czy istnieje jakiś naprawdę nowy język programowania. Taki który zawierałby idee młodsze niż 20 lat? Może prawa własności obiektów w Ruscie?
Borrow checker z Rusta to (w trochę prymitywnym uproszczeniu) wbudowany w język linter do smart pointerów i move semantics z C++. Polecam sprawdzić listę języków na których Rust się wzorował przygotowaną przez samych autorów Rusta: https://doc.rust-lang.org/stable/reference/influences.html Czy smart pointery i move semantics to idee młodsze niż 20 lat? Nie dociekałem.
Z jednej strony można powiedzieć, że wszystko co da się wymyślić (w sensie możliwości które daje język) wymyślono już w Lispie kilkadziesiąt lat temu, ale to było oparte o dynamiczne typowanie. To na czym skupiają się twórcy statycznie typowanych języków są dodatkowe gwarancje wynikające ze statycznej analizy programu i tu jest ciekawie. Sztuką jest stworzenie języka, który z jednej strony da się w rozsądnym czasie ogarnąć tak, by być w nim produktywnym, a z drugiej strony by dawał duże możliwości abstrakcji i jednocześnie dużo statycznie sprawdzanych (tzn przed uruchomieniem programu) gwarancji.
Kamil Żabiński napisał(a):
- Wszystkie nowe funkcyjno obiektowe języki jak Scala, Kotlin czy F# mniej lub bardziej zrzynają z Ocamla (rok powstania 1996) tylko się nie przyznają
Nie jest żadną tajemnicą że F# to praktycznie "OCaml.NET", bo takie było założenie. Można pisać kod który będzie poprawnym OCaml i poprawnym F#.
Scala i Kotlin to jednak co innego.
Konfederat napisał(a):
A to Kotlin już nie na topie?
Kotlin nie jest uważany przez wielu za język funkcyjny. Chyba główny zarzut to brak niezmiennych kolekcji co można rozwiązać za pomocą biblioteki vavr. Jeśli do tego doda się bibliotekę ARROW to ma się już dość ładny język funkcyjny. Problemem jest to że ARROW nie ma jeszcze wersji 1.0.0 oraz posiada zależności do Javy więc nie można jej używać w kotlinie.js oraz kotlinie native
Kamil Żabiński napisał(a):
Konfederat napisał(a):
A to Kotlin już nie na topie?
Kotlin nie jest uważany przez wielu za język funkcyjny. Chyba główny zarzut to brak niezmiennych kolekcji co można rozwiązać za pomocą biblioteki vavr. Jeśli do tego doda się bibliotekę ARROW to ma się już dość ładny język funkcyjny. Problemem jest to że ARROW nie ma jeszcze wersji 1.0.0 oraz posiada zależności do Javy więc nie można jej używać w kotlinie.js oraz kotlinie native
A nie dlatego, że Kotlin jest Multi paradigm? Języków w wersji pure functional powołując się na wikipedię jest 18, a tych będących do wszystkiego znacznie więcej.
Jeśli (błędnie) za podstawę funkcyjności bierzemy zwięzły cukier składniowy dla domknięć to tych języków "funkcyjnych" jest cała masa, włącznie z Javą 8, C++, JavaScriptem itd
Nie znam się, to się wypowiem.
W skrócie: Haskell.
Byłem w podobnej sytuacji, tzn. co wybrać, bo nie mógłbym powiedzieć, że znam FP, bo umiem w Javie korzystać ze streamów i pisać w czymś tam funkcje bez efektów ubocznych. Jakiś czas temu postanowiłem zagłębić się w paradygmat funkcyjny i początkowo wybór padł na Scalę, ale po pewnym czasie doszedłem do wniosku, że jeśli chcę na poważnie podejść do tematu, to powinienem:
Po różnych przemyśleniach różnymi ludźmi, dochodzę do wniosku, że dla mnie Haskell będzie odpowiedni do wejścia w świat FP:
axde napisał(a):
Kamil Żabiński napisał(a):
Konfederat napisał(a):
A to Kotlin już nie na topie?
Kotlin nie jest uważany przez wielu za język funkcyjny. Chyba główny zarzut to brak niezmiennych kolekcji co można rozwiązać za pomocą biblioteki vavr. Jeśli do tego doda się bibliotekę ARROW to ma się już dość ładny język funkcyjny. Problemem jest to że ARROW nie ma jeszcze wersji 1.0.0 oraz posiada zależności do Javy więc nie można jej używać w kotlinie.js oraz kotlinie native
A nie dlatego, że Kotlin jest Multi paradigm? Języków w wersji pure functional powołując się na wikipedię jest 18, a tych będących do wszystkiego znacznie więcej.
Multi paradigm to trochę takie marketingowe pojęcie. Powołując się na wikipedię:
Napisałem dziś artykuł o vavr może komuś się przyda - https://javaleader.pl/2019/10/21/java-8-na-wypasie-biblioteka-vavr/
systemy napisał(a):
Napisałem dziś artykuł o vavr może komuś się przyda - https://javaleader.pl/2019/10/21/java-8-na-wypasie-biblioteka-vavr/
Jeśli chcesz uzyskać dostęp do GitHuba na 30 dni i pobrać kod źródłowy wyślij smsa o treśći DOSTEP.EDUSESSION na numer 7943. Tyle wiedzy a koszt to tylko 9 PLN (11.07 PLN z VAT).
Tego sie nie spodziewałem.
Luzne przemyslenie: jak pracuje na Linuxie, to Scala w trybie interaktywnym bardzo fajnie sprawdza sie jako kalkulator i u mnie wyparla pod tym katem Pythona :)
@WhiteLightning: spróbuj tego: https://ammonite.io/#Ammonite-REPL , ewentualnie tego: https://github.com/polynote/polynote :)