Hlavní navigace

Recenze knihy Functional Thinking (Paradigm over syntax)

5. 4. 2016
Doba čtení: 6 minut

Sdílet

Vývojáři sledující dění v oblasti rozvoje programovacích jazyků zajisté zaznamenali, že v posledních několika letech se (opět) dostává do módy funkcionální paradigma.

The tricky part is learning to think in a different way.

Na trhu již dnes existuje minimálně několik desítek knih zabývajících se funkcionálním programováním či funkcionálním paradigmatem. Některé z těchto knih jsou ve skutečnosti spíše učebnicemi určitého programovacího jazyka (vlastní paradigma je mnohdy jen naznačeno v úvodu), další knihy pak teoretickým úvodem do funkcionálního programování, popř. i do lambda kalkulu a teorie kategorií. Knížka nazvaná Functional Thinking s podtitulem Paradigm over syntax je naproti tomu pojata prakticky, protože na mnoha praktických příkladech seznamuje čtenáře s některými aspekty funkcionálního programování, přičemž se předpokládá, že čtenář již ovládá „klasické“ imperativní a OO paradigma. Příklady jsou implementovány ne v jednom, ale hned ve čtyřech programovacích jazycích, protože autor pro vysvětlování funkcionálního přístupu používá Groovy, Scalu, Clojure a Javu 8 (tedy jazyky běžící nad JVM).

Life's too short for malloc.

Knihu Functional Thinking však ve skutečnosti není možné považovat za učebnici ani jednoho z těchto programovacích jazyků (ostatně by to nebylo na přibližně 160 stránkách možné), ale skutečně za seznámení čtenářů s funkcionálním paradigmatem a jeho dopadem na způsob vývoje aplikací. Nejprve jsou vysvětleny rozdíly mezi imperativním a funkcionálním paradigmatem a hned ve druhé kapitole se čtenáři seznámí s funkcemi typu map, filter a reduce i se způsobem jejich použití (a pojmenování) v Groovy, Scale, Clojure i Javě 8. Následuje poměrně podrobně popsané vysvětlení dalších technik obvykle používaných ve funkcionálních jazycích: funkce vyššího řádu, uzávěry (closures), currying, memoizace (uložení výsledků funkcí bez vedlejších efektů do vyrovnávací paměti) a taktéž využití takzvaných líných sekvencí (resp. v této knize pouze líných seznamů).

Typically, developers learn new languages by applying what they know about existing languages. But learning a new paradigm is difficult – you must learn to see different solutions to familiar problems.

Jen poměrně krátce je zmíněno použití rekurze a některé problémy, které může „obyčejná“ rekurze při výpočtech způsobit. S touto problematikou samozřejmě souvisí i TCO (Tail Call Optimization), což je ovšem téma, které je v knize popsáno jen velmi stručnou formou a bohužel navíc bez demonstračních příkladů. To je zejména u programovacích jazyků postavených nad JVM škoda (na druhou stranu se například v Clojure dá v praxi většinou bez rekurze obejít). Tam, kde je to možné a praktické, jsou uvedeny demonstrační příklady ve všech čtyřech zmíněných programovacích jazycích, ovšem samotná teorie, která za těmito technikami stojí, není většinou příliš rozvedena (to ostatně ani většinou vývojáři nepotřebují).

It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures.

V páté kapitole je vysvětleno, proč se v mnoha funkcionálních jazycích setkáme s použitím pouze několika základních typů datových struktur (typicky seznamu, mapy a množiny) a jaký to má dopad na celkovou architekturu vytvářených programů, zejména v porovnání s klasickým OO přístupem. Ovšem hlavním tématem této kapitoly je popis, jak je možné daný programovací jazyk „ohnout“ takovým způsobem, aby se v něm dal snadno implementovat řešený algoritmus (a nikoli naopak, že se řešení problémů „ohne“ tak, aby to odpovídalo vlastnostem programovacího jazyka). Z tohoto důvodu je tato kapitola rozdělená do několika rozdílných částí, protože každý programovací jazyk má v tomto ohledu jiné vlastnosti (Clojure je velmi elastický, na rozdíl od Javy atd.). Je trošku škoda, že tato kapitola není rozsáhlejší, protože například vysvětlení multimetod v Clojure je podle mého názoru nedostatečné a asi se jedná jen o připomenutí, že takováto technika vůbec existuje.

I never want to work in a non-garbage-collected language again. I paid my dues in languages like C++ for too many years, and I don't want to surrender the conveniences of modern languages.

Ve světě objektově orientovaných jazyků se poměrně často používají (popř. aspoň citují) návrhové vzory (design patterns). A právě problematice návrhových vzorů je věnována šestá kapitola. Vzory jsou probírány s ohledem na funkcionální programování, které se v mnoha ohledech odlišuje od OO přístupu. Proto také některé původní návrhové vzory nemají ve funkcionálním paradigmatu svůj přesný obraz (a ani nemohou mít, protože v OO přístupu se řeší odlišný základní problém – komunikace mezi objekty). V šesté kapitole jsou některé tradiční návrhové vzory zmíněny a je ukázáno, jak je lze implementovat při použití funkcionálního paradigmatu. Podle mého názoru je však nejdůležitější samotný závěr této kapitoly, který se věnuje znovupoužití kódu a refaktoringu, včetně popisu rozdílu mezi použitím dědičnosti v OOP (mnohdy zneužívaná technika) a kompozice jakožto alternativní techniky.

Working in a particular abstraction every day causes it to seep gradually into your brain, influencing the way you solve problems.

Teprve v předposlední kapitole je čtenář podrobněji seznámen s některými novými vlastnostmi programovacího jazyka Java 8. Umístění této kapitoly až na konec knihy je ovšem logické – pokud by tato kapitola byla umístěna na začátek, musela by pravděpodobně být pojata jako pouhá referenční příručka seznamující čtenáře s novou syntaxí a novými třídami popř. metodami. Ovšem díky tomu, že se popis nových vlastností Javy 8 ocitl až na prakticky samotném konci knihy, se autorovi podařilo dosáhnout zajímavého efektu: po popisu každé nové vlastnosti (lambdy, proudy, mezioperace i ukončující operace nad proudy) si čtenář uvědomí, proč byla daná vlastnost do Javy 8 přidána a jak je možné tuto vlastnost použít při použití funkcionálního paradigmatu resp. funkcionálního přístupu k implementovaným algoritmům. Dále je v této kapitole popsána tvorba „funkcionálního rozhraní“, zejména pak způsob tvorby tříd, z nichž se konstruují neměnitelné (immutable) objekty.

Every Access project will eventually fail because, while 80% of what the user wants is fast and easy to create, and the next 10% is possible with difficulty, ultimately the last 10% is impossible because you can’t get far enough underneath the built-in abstractions, and users always want 100% of what they want.

Závěrečná kapitola je věnována použití většího množství paradigmat v jednom projektu, samozřejmě s varováním, s jakými problémy se může toto řešení setkat. Autor se zde zabývá i rozdílem mezi nástroji (nikoli nutně programovacími jazyky) založenými na určitém kontextu a naopak nástroji, které jsou jednodušší, obecnější a je možné je spojovat s využitím kompozice. Zde samozřejmě nesmí chybět historka popsaná například zde (jen krátce: Knuthův program napsaný na více než deseti stránkách komentovaného Pascalovského kódu přepsal Doug McIlroy do pouhých šesti příkazů spojených přes unixovou rouru).

This is why every project eventually hates Maven. Maven is a classic contextual tool.

ict ve školství 24

Shrnuto:

  1. Nečekejte učebnici programování a už vůbec ne učebnici nějakého konkrétního programovacího jazyka.
  2. Předpokládá se aktivní znalost alespoň jednoho z jazyků v této knize použitých (stačí i Java před verzí 8, libovolná verze Groovy, Scaly či Clojure).
  3. Takovými „maličkostmi“, jako jsou konvence pojmenování souborů, překlad aplikace či její spuštění, se autor nezabývá; ostatně na toto téma existuje mnoho jiných knih a učebnic.
  4. Nečekejte ani popis teorie kategorií (ta je zmíněna snad jen na dvou místech).
  5. Naproti tomu lze předpokládat, že programátoři používající imperativní a OO přístup se dozví naprostou většinu důležitých a relevantních informací potřebných pro vyzkoušení funkcionálního přístupu.
  6. Pokud se někdo chce nezávazně seznámit s funkcionálním paradigmatem a jeho použitím v moderních jazycích, je tato kniha pro začátek velmi dobrá.

Poznámka na závěr: cena necelých 40 dolarů se může při objednání papírové verze dost prodražit, pokud budete mít stejné štěstí jako autor recenze a budete muset deklarovat cenu zboží v balíku :-)

Autor článku

Vystudoval VUT FIT a v současné době pracuje na projektech vytvářených v jazycích Python a Go.