Mi is a funkcionális programozás lényege?

Erre a kérdésre a választ Li Haoyi zseniális cikkében találhatjuk meg.
Fejlesztőknek erősen ajánlott olvasmány!

( Hevi v | 2017. 02. 02., cs – 18:04 )

Erdekes volt, koszi!

Jo ideje a funkcionalis stilust preferalom (sokaig anelkul, hogy tudtam volna, hogy igy hivjak), de most meg inkabb megerositest nyert. Kollega meg is jegyezte, hogy "akkor az FP az vegulis csak Clean Code?", ami egy nagyon fontos kerdes, csak az iranya rossz :)

Pedig a cikk olvasasa utan bennem is felmerult a kerdes, hogy ha tenyleg ez az eszenciaja az FP-nek, akkor tulajdonkeppen barmelyik programozasi nyelvben lehet funkcionalisan programozni, csak vannak nyelvek amik ezt jobban tamogatjak es vannak amelyek kevesbe.

Btw hogy erted azt hogy az iranya rossz?
"akkor a Clean Code az vegulis csak FP?" => ez lenne a helyes irany? Kifejtened? :)

( haspokember | 2017. 02. 02., cs – 22:40 )

Nem tudom, lehet, csak bal labbal keltem, de ez szerintem edeskeves.

Nem sokat er az adatfolyamban valo gondolkozas, ha a processzben barhol labon loheted magad egy megfeleloen elhelyezett mutalassal (ezt hogy mondjak egy szoval magyarul?), 5 fuggveny melyen, lehetoleg egy parhuzamosan vegrehajtott utasitashalmazban.

Vereset pisilhetsz, de ha peldaul a keretek olyanok, hogy kotelezoen mutable valtozoid / objektumaid vannak (lasd Java szerializacios frameworkok), a funkcionalis programozas csak mese. Nem veletlen, hogy a Pythont a fonok kifejezetten nem funkcionalis programnyelvnek tartja / szanta, es az sem veletlen, hogy a Javaban nagyon lehatarolt teruleten van csak "adatfolyam", explicit bemenettel-kimenettel.

Raadasul rendesen megtamogatott immutable collection keszlet nelkul a fene megette az egeszet. Mert ugye ugy mukodne a dolog, hogy a fuggvenyed egy collection-t kap parameternek, es ugy modositja, hogy lemasolja a megvaltozott ertekkel. Ha a kedvenc programnyelved es/vagy konyvtarad szerint ez full copyt jelent, akkor igy jartal, te csak ne akarjal itten hipszterkedni, baratom!

Egyebkent Li Haoyi nagy arc, szeretjuk, tiszteljuk, becsuljuk, de nem ezert az irasaert :)

Eddig meg legjobban Rich Hickey fogalmazta meg a lenyeget, a Clojure's Approach to Identity and State cimu orokbecsu eloadasaban, valamikor 10 evvel ezelott (vagy meg nincs annyi? egy eletnek tunik).

Az immutability (vagyis hogy egy dolog mindig "identity", es a state az identityken valo ugralast jelent) szerintem igenis fontosabb, mint az adatfolyam. Ugyanis ha immutable vagy, akkor szuksegszeruen csak bemenet-kimenet valtozasban tudsz gondolkodni, viszont forditva ez nem igaz. Ha mar filozofalgatunk :)

> Ha mar filozofalgatunk :)

Igen, nehéz ügy ez. Önmagában sem az adatfolyam szemlélet, sem az immutability, sem a referential transparency nem nyújt biztonságot.

Nekem azért tetszik ez a megközelítés (adatfolyam), mert a legnehezebb dolog a funkcionális programozásban az, hogyan építsük fel a programunkat. Ez a megközelítés segít ebben. Szerintem is ez a kulcs ahhoz, hogy funkcionálisan gondolkozzunk, programozzunk.
Pl. ha egy függvényben van mutable dolog (pl. ciklus), de nem érinti az input, output körét, tehát az adatfolyam ettől teljesen független, attól még ez egy sokkal jobb szemlélet, mint ha immutable minden, de ahogy a cikkben is van, kvázi imperatívan épül fel a program ("Writing Things in Haskell"). Másik példa: minden immutable, de adatbázisból beolvas valamit az x.edik mélységben (tehát az adatfolyam elv sérül, illetve a referential transparency).