Z jakich zagadnień prog. funkcyjnego korzystać, aby pisać dobry kod?

Cześć,

Uczę się obecnie najróżniejszych zagadnień z FP w Scali z wielu źródeł, a nastepnie chciałbym wziąć się za książkę Get Programming with Haskell, która jest świetnie napisana.
Niestety ilość zwłaszcza tych bardziej zaawansowanych zagadnień w FP jest ogromna i sam już nie wiem, które są najbardziej przydatne, a które nie.

Jak dotąd, mam taką listę zagadnień z FP, które moim zdaniem bardzo przydają się do pisania dobrego biznesowego kodu:

• Immutability: obiekty immutable itp

• Pure functions: Pisanie funkcji bez side effectów oraz stosowanie się do zasad referentially transparent functions

• Funkcyjne struktury danych np. pakiet immutable w Scali

• High-order functions: unikanie imperatywnego kodu i stosowanie streamów oraz operacje: lambdy, funkcje: map(), filter(), reduce(), fold() itd

• Pattern matching

• Functional Error Handling: Stosowanie Option i Either zamiast wyjątków

• Currying? Zastanwiam się na ile Currying jest tak naprawdę przydatny

• Monoidy

• Znajomosć generyków i różnego typu polimorifzmu: parametric/subtyping/ad-hoc polymorphism

• Monady

• Monady IO

• Algebraic Data Types ?

• Umiejętność oddzielenia kodu funkcyjnego od kodu gdzie mamy do czynienia z side effects np w I/O

Czy Waszym zdaniem warto uczyć się takich bardziej zaawansowanych zagadnień jak np. Category Theory, Kind Polymorphism, Kleisli Category itp (kiedyś @jarekr000000 wrzucał taką fajną listę tego typu zagadnień na Githubie)? Przyznam szczerze, że cięzko byłoby mi zastosować te zagadnienia w praktyce np. w Scali, bo wydają mi się mało praktyczne (może dlatego, że nie znam ich dobrze)

Co jeszcze dorzucilibyście do tej mojej listy, co może faktycznie przydać się w praktyce? ;)

Znalazłem jeszcze taką listę: https://hub.packtpub.com/a-five-level-learning-roadmap-for-functional-programmers/

Nie licząc podtypowania (subtyping) który jest z OOP i algebraicznych typów danych (które IMHO podpadają pod rzeczy zaawansowane) to jest to lista podstawowych zagadnień :p wszystko jest potrzebne :) chociaż może currynig nie jest naturalny w Scali
Może te rzeczy nie są potrzebne żeby pisać produkcyjny kod w Scali ale są niezbędne żeby pisać w Haskellu

Chciałeś powiedzieć aby pisać dobry kod w paradygmacie funkcyjnym. Mogę Ciebie zapewnić że deweloperzy jądra Linuxa piszą dobry kod w paradygmacie proceduralnym.

Ja się zatrzymałem na Monadach, nawet w Scali były nie do końca strawne (for comprehension działa tak sobie, nie można mixować monad, trzeba opierać się o biblioteki typu catz żeby mieć transformery, meh).

Problem z Monadą IO jest taki że wszystkie liby których używasz muszą się dogadać na implementację. Inaczej czeka ciebie pisanie wraperów. ZIO wprowadza uber monadę która ma szanse stać się takim standardem w Scali. Nie korzystałem z ZIO, osobiście pewnie pożegnam się wkrótce też ze Scalą.

Generalnie idea Monady IO jest piękna ale w praktyce takie problemy wychodzą:

• Logowanie to IO czy nie IO? (W praktyce wszystkie projekty na których robiłem traktowały logowanie jako świętą krowę i nie szło ono funkcyjnie)
• Cache i Memoized funkcji z IO to IO czy nie IO? Sygnatura wymusza IO, choć tak naprawdę jak dane są rzadko zmienne to nie powinno być IO. Da się to rozbić na 2 interface ten co napycha cache i ten co tylko czyta.
• Jak się do tego doda jeszcze async to wyjdzie Future[IO[Either[...]]] ciężko z takim bytem pracować
• Refactor funkcji nie IO na IO ssie

Generalnie nie dam Ci żadnej rady, czuję że jesteś już wyżej ode mnie jeżeli chodzi o FP.

Jak się do tego doda jeszcze async to wyjdzie Future[IO[Either[...]]]

Zwykle IO jest async. ZIO to złączenie async IO i Either :)

@0xmarcin:

Logowanie to IO czy nie IO? (W praktyce wszystkie projekty na których robiłem traktowały logowanie jako świętą krowę i nie szło ono funkcyjnie)

Tak długo jak to log diagnostyczny ( na użytek "wewnętrzny" programistów) to można spokojnie traktować log jako "świętą krowę", przyjmować, że funckcje, które wrzucają coś tylko do loga są nadal czyste.

Cache i Memoized funkcji z IO to IO czy nie IO?

IO - jasne, przyznaje, że nie rozumiem tu wątpliwości.

Baldr napisał(a):

Kleisli

Ja właśnie zrozumiałem co to jest Kleisli :D Gdzieś tak po 5 latach XD I jest to coś czego szukałem gdzieś od roku XD Precz z do-notation, niech żyje notacja strzałkowa :P Czuję się naćpany tą wiedzą. Chyba wpiszę sobie do CV że wreszcie rozumiem co to Kleisli :P I poraz enty przepiszę swoje projekty hobbystyczne, tym razem tak żeby używały Kleisli :D