ITHub

2015, a funkcionális programozás éve?

2015, a funkcionális programozás éve?
Farkas Gábor
Farkas Gábor
| ~3 perc olvasás

Ha nem is vagy különösebben jártas a témában, nagy eséllyel találkoztál már az Erlang, a Clojure, vagy a Scala programozási nyelvekkel (utóbbiról mi is írtunk korábban). Valószínűleg arról is hallottál, hogy ezeknek köze van a funkcionális programozáshoz, amivel legtöbbünk utoljára az egyetemen találkozott. Jugon Calves kiváló írása mentén azt boncolgatjuk, miért lehet áttörés az idei év egy hatvanéves technológiának.

2015, a funkcionális programozás éve?

Alapok

Ez a cikk nem kíván még csak elméleti bevezető sem lenni a funkcionális programozáshoz, érdemes azonban legalább néhány alapdolgot idefűzni. A funkcionális programozás egy olyan programozási paradigma, amelyben a programunk alapvető építőkövei a függvények, nem pedig objektumok, vagy eljárások/metódusok. Itt a függvény fogalma semmiképp sem összekeverendő a procedurális programozásból megismert függvényekkel, amik valójában eljárások. A függvény ebben az értelemben két vagy több entitás kapcsolatát írja le, hasonlóan egy matematikai egyenlethez. Vizsgáljunk meg néhány olyan tulajdonságot, amellyel gyakorlatilag az összes funkcionális programozási nyelv rendelkezik.

A függvények első osztályú entitások, ami a gyakorlatban azt jelenti, hogy változókban tárolhatjuk őket — ez ismerős lehet, ha fejlesztettél már JavaScriptben. A függvények emellett magasabb fokúak is, azaz egy függvény lehet egy másik függvény paramétere, ill. visszatérési értéke lehet egy függvény is (a JS ezt is tudja, gondoljunk csak az eseménykezelésre). A függvények tiszták, ami annyit jelent, hogy nincsenek mellékhatásaik: nem módosítanak semmilyen értéket, csak elfogadnak inputot, és visszaadnak outputot. Ha f függvény x inputra y eredményt adta egyszer, akkor mindig azt fogja. Fontos a closure fogalma is: egy függvényen belül specifikálhatunk olyan adatokat, amelyek kizárólag ezen függvényen belül elérhetőek, más szóval megmarad a végrehajtási környezet (már mondanom sem kell, hogy JS-ben ezzel is mindenki találkozott már). Nagy újdonság lehet viszont az állapot állandósága: ha x értéke egyszer 5 lett, akkor onnantól x és 5 felcserélhetőek, ugyanazt jelentik. Ez az utolsó tulajdonság inkább negatívumnak tűnhet, de később meglátjuk, ez miért nem igaz.

Miért nem jó az objektum-orientált paradigma?

Végre elérkeztünk abba a korba, amikor az alkalmazásaink elosztott, konkurrens módon futnak. Sajnos egyáltalán nem mondható el, hogy erre fel lennénk készülve. Persze, minden jelenlegi modern nyelvben/környezetben léteznek megoldások az elosztottság és a konkurrencia kezelésére, de ezek meglehetősen nagy komplexitásúak.

A legnagyobb probléma, hogy az OOP egyik alapköve a folyamatosan változó állapot. Egy objektum állapota (privát változóinak értéke) az alkalmazás működése során jellemzően folyamatosan változik, és bonyolult folyamatokat igényel annak biztosítása, hogy ezt az állapotot minden szálon szinkronban tartsuk. Pontosan emiatt fontos mindenkinek ismernie valamilyen szinten a funkcionális programozást. Ez nem kizárólag új nyelvek megtanulását jelenti: például már a Java is tartalmaz FP elemeket. Természetesen a változó állapotra továbbra is szükség lesz, hiszen mindig kell I/O, fájlok, stb. — a lényeg, hogy csak akkor használjuk, ha nagyon szükséges.

Az utóbbi években a FP térhódítása már érezhető volt, sok szakértő úgy véli, hogy nagy, komplex, elosztott rendszereket a jövőben egyszerűen nem is lehet majd másképpen építeni. Mivel egyértelműnek tűnik az is, hogy a jövő a cloudban van, nem az a kérdés, meg kell-e tanulnunk a funkcionális programozást, hanem az, hogy miért nem kezdtük el korábban?

A tanuláshoz sajnos magyar nyelven nem áll rendelkezésre túl sok jó forrás (ha mégis ismertek ilyeneket, várom a kommenteket). Angolul érdemes a klasszikus Structure and Interpretation of Computer Programs könyvet tanulmányozni, ill. természetesen a cikk elején említett nyelvekhez tartozó tutorialokat böngészgetni a neten, amik szintén adnak némi rálátást az elméleti dolgokra is.