Vlákno názorů k článku Recenze knihy Functional Thinking (Paradigm over syntax) od JS - Skoda, ze v knizce chybi Haskell, protoze to...

Skoda, ze v knizce chybi Haskell, protoze to je "enfant terrible" v FP. To ji v mych ocich dost degraduje.

Byl jsem dlouho odpurcem FP, ale nakonec jsem skoncil (po kratkem koketovani se Scalou a Clojure) u Haskellu. Dlouho jsem premyslel nad tim, cim se FP a OOP lisi, a co to znamena pro architekturu. Nakonec, diskuse s kolegou o OOP, znamenala pro me prulom v teto otazce.

Moje soucasna domnenka - OOP a FP se lisi v pojeti rozhrani mezi castmi programu, a ve zpusobu zapouzdreni dat. V OOP jsou rozhranim volani metod objektu, tedy akce, ktere ma cilovy objekt provest. Data se pritom snazime zapouzdrit do objektu. Naproti tomu v FP jsou rozhranim samotna data (v podstate typy).

Svym zpusobem jde o dualni pristup. V OOP predavame v ramci casti programu data zapouzdrena v objektech, v FP predavame (opacnym smerem) funkce, ktere nad temi daty pracuji. IMHO kazdy design pattern v OOP lze prevest do FP tim, ze misto predavani objektu budeme predavat funkce opacnym smerem. Take se na to lze divat jako na zmenu vztazne soustavy - v OOP jsou funkce na miste a data se pohybuji, zatimco v FP se pohybuji funkce a data stoji na miste.

Proto se tak FP uplatnilo v MapReduce paradigmatu (a jeho naslednicich), ktere je cele o tom, predavat mezi distribuovanymi uzly operace k datum misto samotnych dat. A v podstate i puvodni Unixove paradigma rour je dost funkcionalni, akorat ta datova rozhrani jsou ad hoc, vetsinou textova.

Myslim, ze pristup FP je lepsi, protoze:

- Data se lepe semanticky definuji nez operace. Pokud jsou tedy rozhranim data a ne operace, je snazsi tomu rozhrani porozumet.

- Data jako rozhrani davaji vetsi prostor ke znovupouzitelnosti. Nad objektem, ktery data skryva, jsme omezeni akcemi, ktere dovoluje jeho rozhrani. V FP ale k danym datum muzeme provadet libovolne operace. To je hezky videt prave na Unixovem pristupu, ktery je asi nejlepsim uspechem modularity v pocitacich vubec.

- V OOP se casto stava, ze potrebujete data prece jenom predat, a to pak znamena spoustu operaci, ktere jsou v podstate identitou. V FP tohle odpada, protoze je zrejme, ze nekde predavate identickou funkci.

Na FP se mi líbí, že se nemusím zabývat podobnými úvahami. "Softwaroví architekti" se až donedávna zabývali převážně OOP.

Fungování OOP je jiné - ve výpočtu se nepředávají objekty jako data, ale jako CELÉ výpočetní jednotky. Data objektu jsou od jejich zpracování neoddělitelná, to je klíčová vlastnost OOP.
I tak oceňuji první hodnotný příspěvek v diskusi k objasnění FP.

"Data objektu jsou od jejich zpracování neoddělitelná, to je klíčová vlastnost OOP." - ano, velmi názorně je to vidět např. na CLOS. :)

To neni moc podstatne, v kazdem paradigmatu potrebujete nejakou kombinaci funkci a dat. Spis jde o to, jak se pracuje se "zdroji" dat.

Nejlip tenhle rozdil vynika v Haskellu, ale objevuje se do jiste miry ve vsech FP jazycich. V OOP se zdroje dat skryvaji do malych jednotek, objektu. To co se predava mezi castmi programu jsou prave odkazy na zdroje. V pure FP (jako ma Haskell) to tak neni, tam si zdroje drzi centrum, ktere misto toho dostava instrukce ve forme treba monadickych typu.

Obecne se z toho pak stava rozdil ve zpusobu, jakym se pracuje s menitelnym stavem (coz je v podstate forma zdroje dat). V OOP se ten stav zvlada tim, ze se schova pod nejake API operaci nad nim. Tim je mozne ten stav nekam jinam predat, zmenit vlastnika, aniz by se narusila jeho konzistence. V FP se stejny problem zvlada tim, ze se ten stav nikam nepredava, ale misto toho se nad nim operuje primo prostrednictvim dodanych pozadavku, jak ho zmenit.

To by asi znamenalo to, co jsem psal výše - stavy jsou odděleny od operací, které jsou vybírány k jejich zpracování explicitně, ad hoc, kdežto v OOP jsou s daty spojeny a nelze je vybírat (pouze spouštět). Je to tak?

No, asi se to tak trochu da brat, ale v (pure) FP nejde jenom o oddeleni stavu, ale vsech vnejsich akci, od operaci.

Krome toho, nelze to chapat tak, ze to v FP zpusobuje nejaky "chaos" navic, jak to vnima pan Novy - alespon v Haskellu je to co si muzete s danym datovym typem dovolit striktne omezene jeho typem. Skrze typovy system lze skryt i implementacni detaily, samozrejme.

Asi se nedá říct, že by byl jeden přístup lepší. OOP se víc hodí na entity, co něco dělají a dává smysl je o něco požádat. FP se víc hodí v případě že nějak transformuju data.

Je to tedy odpovědí na moji otázku, že jejich cílové okruhy problémů jsou rozdílné?

Nejsou úplně rozdílné, nějaký překryv tam je. Ale ano, na různé problémy se hodí různé přístupy.

Ja myslim, ze FP lepsi je (viz moje argumentace). Protoze i ten objektovy pristup lze do znacne miry emulovat (treba pres typove tridy, nebo jinak, i kdyz je pravda, ze v jazycich, ktere nejsou tak striktne FP jako Haskell, jdou nektere ty veci hur).

Ale hlavne, je otazka, proc bys chtel mit v programu "entity, ktere neco delaji a dava smysl je o neco pozadat"? (Jak uz jsem psal vys, uz samotna tahle myslenka je zpusob mysleni v OOP.) Treba v Haskellu se tohle da resit pres monady, tedy ze fakticky vracis program, ktery rika, o co se ma pozadat a jak.

To druhe mi prijde vyhodnejsi, protoze nad tim programem muzes nejak pracovat, treba ho interpretovat uplne jinak - jsou to data. Jenom samotna volani ale tezko.

Je to asi trochu jako rozdil mezi GUI a prikazovou radkou. GUI ti nedava moznost napsat skript, ktery neco dela, vsechno se dela primo.

No to záleží, co v tom GUI je. Když vezmu Eclipse IDE tak mi dává jaksi větší možnosti než příkazová řádka.
Ale celá argumentace ohledně FP se točí kolem modulů a jakéhosi volání záhadných funkcí které mají něco spasit, ale pokud chci napsat nějakou funkcionalitu, tak musím nějaký kód vytvořit a jestli ho obalím do metody třídy (OOP) nebo modulu (FP) je úplně jedno. V každém případě budu volat obal::metoda (možná jen jiná syntax) a uvnitř kód: zápis, čtení, inkrementace ............. Fajn. FP je hned nad daty, ale když chci, můžu třeba v Doctrine nebo v Javě Hibernate (mapování dat na objekty) tak k tomu můžu taky lézt přímo a změnou objektu, čí zavoláním jeho funkce pracovat přímo s daty a reflektovat jejich změny.
Tak kde je tedy to jasné zlepšení?

Zlepšení by mohlo být v omezení co s těmi daty můžete dělat, jak je měnit a můžete jen map, filter, reduce. Prosíváte data a na základě vyloveného vrátíte pozměněné kopie.

Na vstupu dostanete adresu kolekce, na výstup uložíte adresu pozměněné virtuální kopie vstupní kolekce. Funkci je jedno z jakou kolekcí pracuje, přístupy k položkám, můžete dodat ve formě funkce, jako parametru.

Místo vytváření abstrakcí ve formě objektů - zákazník, objednávka, vytváříte abstrakce ve formě činnosti - sum_order(type, key, time_range) -> sum_order_item­s(orders(time_ran­ge), id(type, key), name, quantity), kde orders je funkce vracející objednávky, kde id je funkce, která vrací funkci, která otestuje zda aktuální prvek je daná objednávka, další parametry jsou funkce, které vrací funkce, které vrátí požadované hodnoty z řádku objednávky, takže na této úrovni nepotřebujete žádné datové typy a činnost je popsána zcela obecně. Všechny parametry jsou funkce.

Vyhoda FP je prave v te centralizaci pristupu k datum.. (lepe receno asi v tom, ze data jsou rozhrani, jak uz jsem psal) Ze stejneho duvodu se OOP aplikace tak casto svazuji s databazemi, protoze je to proste snazsi (klasicke relacni databaze jsou velmi ne-OOP, jelikoz maji centralni schema). To "distribuovani a skryvani dat" napric mnoha objekty v ramci OOP aplikace je sice jistym resenim modularizace programu, ale ma svoji cenu - vetsi potize pri pristupu k datum. FP ale ukazuje, ze muzeme mit vyhody obojiho - jak modularitu, tak pristup k datum. Toho se dosahuje kombinaci immutability a laziness, jak o tom pise klasicky clanek "Why functional programming matters". I kdyz samozrejme ma to svoji cenu, tou je vyssi abstrakce a vic prace pro kompilator (zatim ne zcela vyresene problemy).

Tak právě ty relační systémy bych jako argument nepoužíval - jsou to externí, neobjektové systémy bez principu zapouzdření, tudíž je třeba počítat s tím, že jestliže jsou jim svěřeny vnitřní stavy objektů, bude možno se k nim dostat. To je ale logické.
(Jak už se tu zmiňovalo) naopak přístup k vnitřním stavům je nežádoucí, protože ohrožuje konzistenci dat. Zapouzdření nevzniklo z pr_de_le!