Funkcionální programátor

[jouda]

Dobry den, chci se zeptat jestli ma tady nekdo zkusenosti z implementaci byznys pozadavku ve funkcionalnich jazicich. Prave se nachazim na rozcesti, kdy si musim zvolit, jakym smerem se bude ubirat moje profesni kariera. Na funkcionalnich jazycich mi imponuje obzvlaste esteticnost a udrzovatelnost kodu. Obavam se vsak, ze nebudu moci plne splynout se zelezem a pokrocile kapitoly jako memory management zustane pro mne zapovezeny. Krome toho mam jeste zkusenosti s vyvojovym prostredim Turbo Pascal. V kostce - co obnasi funkcionalni programovani, pomineme li oscilacni charakteristiky?

[Reklama]

[Radovan.]

Odpovědi na své otázky najdeš v tomto evangeliu: http://www.pismak.cz/index.php?data=read&id=247187

[čumil]

Sice LISP není funkcionální, a ne, ani clojure není, ale jinak pravdivé a smutné. Memory management je impure, od toho je GC. Pokud potřebuješ paradigma s vysokou abstrakcí, vem si FP, v opačném případě zůstaň u OOP.

[Daniel Kozak]

Dobry den, chci se zeptat jestli ma tady nekdo zkusenosti z implementaci byznys pozadavku ve funkcionalnich jazicich. Prave se nachazim na rozcesti, kdy si musim zvolit, jakym smerem se bude ubirat moje profesni kariera. Na funkcionalnich jazycich mi imponuje obzvlaste esteticnost a udrzovatelnost kodu. Obavam se vsak, ze nebudu moci plne zplynot se zelezem a pokrocile kapitoly jako memory management zustane pro mne zapovezeny. Krome toho mam jeste zkusenosti s vyvojovym prostredim Turbo Pascal. V kostce - co obnasi funkcionalni programovani, pomineme li oscilacni charakteristiky?

Tak stale si muzes vybrat jazyk, ktery podporuje vice paradigmat (OOP, FP ...). Me osobne ciste FP nevyhovuje a ciste OOP taky ne. Proto mam rad jazyky, ktere me nenuti do jednoho ci druheho.

[čumil]

Dobry den, chci se zeptat jestli ma tady nekdo zkusenosti z implementaci byznys pozadavku ve funkcionalnich jazicich. Prave se nachazim na rozcesti, kdy si musim zvolit, jakym smerem se bude ubirat moje profesni kariera. Na funkcionalnich jazycich mi imponuje obzvlaste esteticnost a udrzovatelnost kodu. Obavam se vsak, ze nebudu moci plne zplynot se zelezem a pokrocile kapitoly jako memory management zustane pro mne zapovezeny. Krome toho mam jeste zkusenosti s vyvojovym prostredim Turbo Pascal. V kostce - co obnasi funkcionalni programovani, pomineme li oscilacni charakteristiky?

Tak stale si muzes vybrat jazyk, ktery podporuje vice paradigmat (OOP, FP ...). Me osobne ciste FP nevyhovuje a ciste OOP taky ne. Proto mam rad jazyky, ktere me nenuti do jednoho ci druheho.

Kočkopsy mají nevýhodu ve funkcionalite. Pokud paradigmata mají vzájemně neslučitelné vlastnosti, musí se tyto vlastnosti ve jménu koexistence potlačit. A tím znehodnotime daná paradigmata. Výsledek? Multiparadigmatické jazyky jsou obvykle prasarna, ale ne vždy, zvláště pokud zkombinovana paradigmata patří do stejné rodiny. Kupříkladu mix reaktivního a funkcionalního paradigmatu je úžasný a umožňuje nám dělat IO bez ztráty čistoty. Mix proceduralniho a funkcionalního paradigmatu je na druhou stranu katastrofální a silně FP znehodnocuje. Ano, mluvím o scale. Scala je přesně takový kočkopes. A že je objektová? Ne není, v dnešní době není objektové nic, skončilo to smalltalkem. Dnešní oop jazyky sou procedurální jazyky s troškou syntaktickeho cukru aby to vypadalo jak posílání zpráv.

[Reklama]

[hjghgjhg]

co maju vsetci furt s tym smalltalkom?

[pb.]

No co by měli šeci s tým smalltalkem - myslíja si, že nikde sa nepoužívá konstrukce známá z qt:

connect(odkud, SIGNAL(funkce()), kam, SLOT(funkce), Qt::QueuedConnection);

...teoretici

[neruda]

"Dnešní oop jazyky sou procedurální jazyky"

Desítky let vývoje, desetitisíce vývojářů ... a přitom - stačilo se zeptat prvního českého burana, který by hned věděl jak je všechno blbě a co a jak má být ..

[perceptron]

Dnešní oop jazyky sou procedurální jazyky s troškou syntaktickeho cukru aby to vypadalo jak posílání zpráv.

ano, a?

mozete sediet doma pri pive a robit while(true) printf("svet ide do zadeke")

svetu vladne oop ako videne v jave/.net, pripadne multiparadigmaticky gulas ako javascript ci scala alebo v sucasnosti nahypovana vzbura ... clojure. (na smalltalk sa spomina pri vatre)

ano java oop je proceduralne aby ste ho mohli pouzivat ako stateless a teda pseudo funkcionalne

[Kiwi]

No co by měli šeci s tým smalltalkem - myslíja si, že nikde sa nepoužívá konstrukce známá z qt:

connect(odkud, SIGNAL(funkce()), kam, SLOT(funkce), Qt::QueuedConnection);

...teoretici

A se Smalltalkem to souvisí jak? Už teď mám takový pocit, že tvá odpověď mi vykouzlí úsměv na rtech.

[pb.]

No jak... nijak. Stejně jako smalltalk nesouvisí s funkcionálním programováním - to jest s původním dotazem, a stejně jako
nesouvisí s množstvím dalších dotazů, na které nějaký místní purista odpoví "jediný objektový jazyk je smalltalk, vše ostatní
je syntaktické pozlátko".

Posílání zpráv z objektu do objektu dneska opravdu není zvykem - jako jednodušší a praktičtější se prosadilo něco jiného.
Ale podobné mechanismy existují a hojně se používají, ač teď nejsou právě součástí jazyka.

[Kolemjdoucí]

Na funkcionalnich jazycich mi imponuje obzvlaste esteticnost a udrzovatelnost kodu.

Čistě funkcionální programátor neexistuje, vždy budeš muset aktivně umět několik dalších jazyků a paradigmat, to proto že funkcionální hardware neexistuje, existuje pouze hardware imperativní.
Estetičnost a udržovatelnost funkcionálních kódu je obecně oblíbený omyl, realita je mnohem horší než všechny očekávání, viz zde:
http://augustss.blogspot.cz/2007/08/quicksort-in-haskell-quicksort-is.html
http://stackoverflow.com/questions/7717691/why-is-the-minimalist-example-haskell-quicksort-not-a-true-quicksort

[Kiwi]

No jak... nijak. Stejně jako smalltalk nesouvisí s funkcionálním programováním - to jest s původním dotazem, a stejně jako
nesouvisí s množstvím dalších dotazů, na které nějaký místní purista odpoví "jediný objektový jazyk je smalltalk, vše ostatní
je syntaktické pozlátko".

Posílání zpráv z objektu do objektu dneska opravdu není zvykem - jako jednodušší a praktičtější se prosadilo něco jiného.
Ale podobné mechanismy existují a hojně se používají, ač teď nejsou právě součástí jazyka.

No ale - a co? Smalltalk, Self, Objective C, Ruby, do jisté míry i Java a jistě by se našly další objektové jazyky. Objektové programování jeho autor definoval jako model založený na uzavřených funkčních entitách uchovávajících svůj stav, vzájemně komunikujících zprávami a na polymorfismu dosaženém pozdní vazbou. Sám autor pojmu objektově orientované programování se podivuje nad tím, jak je možné, že to tolik lidí nebylo schopno pochopit. Takže z tohoto hlediska je názor některých lidí na některé "objektové" jazyky pochopitelný. Stačí porovnat, jak se dá v takovém Smalltalku nebo Objective C kouzlit s objekty třeba s Javou nebo dokonce C++ aby člověku hned bylo jasné, co je podstatou objektového programování. Když někdo začne dávat funkce do struktur, které přejmenuje na "class" a umožní od nich odvozovat další struktury, tak to prostě nestačí. To je pořád jen staré známé strukturované programování, není důvod tomu říkat jinak, protože oproti němu nepřináší vůbec nic nového. To by bylo totéž, jako nazývat parní stroj turbinou jen kvůli tomu, že ho dělíte na vysokotlakou a nízkotlakou část. To prostě nestačí, turbina funguje na trochu jiném principu.

[Kit]

Posílání zpráv z objektu do objektu dneska opravdu není zvykem - jako jednodušší a praktičtější se prosadilo něco jiného.

To mi vysvětli. Posílání zpráv v OOP dělám běžně.

[Kolemjdoucí]

Objektové programování jeho autor definoval jako model založený na uzavřených funkčních entitách uchovávajících svůj stav, vzájemně komunikujících zprávami a na polymorfismu dosaženém pozdní vazbou. Sám autor pojmu objektově orientované programování se podivuje nad tím, jak je možné, že to tolik lidí nebylo schopno pochopit.

Původní OOP pochopí každý za 5 minut, je to asynchronní zasílání zpráv procesům a hledání metod podle názvu. Původní koncept OOP se používá tam kde je jeho místo a to v inter-process komunikaci. Dnešní OOP je úplně něco jiného protože řeší úplně jiné problémy.