Funkcionální programátor

[Greenhorn]

A taky potřebujeme měnitelné reference pro komunikaci mezi handlery eventů. Výsledek je ten, že program je povětšinou jen tvořen IO monádou, a vlastně nevidíme rozdíl mezi psaním v C a Haskellu. U interpretru imperativního jazyka je tento problém stejný. Možná ale menší. Parser a serializer lze naštěstí udělat bez IO monády, částečně, měnitelné reference v ast jsou problém, ale samotný evaluátor už nejde udělat bez IO monády.

IO monádu nepotřebujete, můžete si udělat vlastní monádu, která bude podporovat jen omezený počet akcí, a tu pak interpretovat v IO monádě.

V principu podobné, ale jednodušší je udělat handler jako funkci Stav -> (Stav, [Akce]), kde Stav popisuje stav aplikace nebo jeho část a Akce popisuje akci, která se má provést po doběhnutí handleru. GUI pak bude funkce stavu - tj. typu Stav -> GUI - podobně jako to má React.

Ale jistě. Tak jako lze Haskell přeložit do impure jazyka, tak jde i skutečně čistý jazyk přeložit do Haskellu. Ale já jakožto pracující člověk, věnující se Haskellu o svém volném čase prostě nemám čas vytvářet si wrapper nad existujícími GUI knihovnami.Něco takového by prostě měl nabídnout už jazyk sám, ne spoléhat že si v tom jazyce uděláme čisté prostředí sami. Nováčci jako já jsou poté akorát zmatení, a zklamaní, protože nechápou jak ten jazyk může být čistý. Ve skutečnosti to znamená že si v něm můžeme čistý jazyk udělat, ne že je. Nezbývá mi než se přidat k panu xyz a říci že C je taky čistě funkcionální. 

[Reklama]

[xyz]

A zrovna tak i cpp, který je v zásadě čistě funkcionální

Není, v cpp žádným program nenapíšeš. Funguje to jenom díky tomu, že tam jsou velké kusy přímo C. Btw, cpp není ani turingovsky kompletní: http://stackoverflow.com/questions/3136686/is-the-c99-preprocessor-turing-complete

No tak si namiesto C/CPP predstav C/FPP, kde FPP je čisto funkcionálny predprocesor, trebárs doplnenie CPP o nejaký SK-kalkulus: bude to čisto funkcionálne aj turingovsky úplné. Nemusí to byť moc praktické - na riešenie praktických vecí z neslniečkového sveta tu predsa máme abstraktný typ C. 

Je to prostě zavádějící příklad.

To si nemyslím. Ten príspevok na jeho blogu je vcelku k veci, aj keď je písaný so značnou dávkou nadsádzky. Okrem toho si nemyslím, že by čitateľom tohto vlákna (ak sem nezablúdili omylom) neboli jasné či už tebou alebo Inkvizitorom uvádzané námietky.

[Mirek Prýmek]

No tak si namiesto C/CPP predstav C/FPP, kde FPP je čisto funkcionálny predprocesor, trebárs doplnenie CPP o nejaký SK-kalkulus: bude to čisto funkcionálne aj turingovsky úplné. Nemusí to byť moc praktické - na riešenie praktických vecí z neslniečkového sveta tu predsa máme abstraktný typ C. 

Když si představím něco jiného, tak pro to bude i něco jiného platit, to dá rozum Je to jako bys řekl, že Eiffelovka je zmrzlina a na námitku, že je z kovu a nedá se moc lízat bys řekl "tak si představ Eiffelovku z mraženého mlíka"

Podle mě tohle prostě debatu nijak nevyjasňuje, spíš naopak. Téma je už tak složitý a plný různých nuancí, tak by bylo lepší ho nezamlžovat...

[Greenhorn]

No tak si namiesto C/CPP predstav C/FPP, kde FPP je čisto funkcionálny predprocesor, trebárs doplnenie CPP o nejaký SK-kalkulus: bude to čisto funkcionálne aj turingovsky úplné. Nemusí to byť moc praktické - na riešenie praktických vecí z neslniečkového sveta tu predsa máme abstraktný typ C. 

Když si představím něco jiného, tak pro to bude i něco jiného platit, to dá rozum Je to jako bys řekl, že Eiffelovka je zmrzlina a na námitku, že je z kovu a nedá se moc lízat bys řekl "tak si představ Eiffelovku z mraženého mlíka"

Podle mě tohle prostě debatu nijak nevyjasňuje, spíš naopak. Téma je už tak složitý a plný různých nuancí, tak by bylo lepší ho nezamlžovat...

Debata už bylo zamlžená dost z mého pohledu. Cítím z ní stejný pocit jako cítím z Haskellu. Napřed se objevil čumil, a začal vcelku logicky uvádět věci na pravou míru. Protože to ale dělal se skutečnou vervou, rozhodlo se pár místních mistrů z něj prostě udělat blba. To se nepovedlo protože radši odešel, a debata ve své zmatenosti pokračovala dále. Závěr je ten, že čumil říkal že Haskell není čistý, a měl snadno pochopitelné argumenty a dokonce vypsal řešení problému, ostatní zde tvrdili že Haskell je čistý, a podporovali to argumenty které jsem moc nechápal, byly na mne moc složité řekl bych, podobně jako některé vysvětlení na internetu proč je Haskell čistý. A na závěr jsem se zde dověděl, že vlastně IO monáda je pro GUI nevýhodná, a že pro to je FRP o kterém nazačátku mluvil čumil. K tomu všemu jsem se dozvěděl že vlastně FRP je takřka to samé co IO monáda. Citím se neskutečně otráveně a unaveně, myslím, že přesně to je jeden z důvodů proč se funkcionální jazyky nepoužívají, já bych ho také nepoužil, po zkušenostech s Haskellem. To už radši nasadím libovolný z dnešních jazyků, a budu mít to samé, a rychlejší. To co zde píšu zní zmateně, a přesně takový i jsem z této debaty. Spíš mi přišlo že si tady pár lidí vyřizovalo osobní učty.

[v]

vstup/výstup v čistě a čistěji funkcionálních jazycích je složitý problém, jaké překvapení
čumil nic nemohl uvést na pravou mírou bo tomu sám nerozumí, viz jeho dlouhý post a to co psal o měnitelných referencích v IO monádě

[Reklama]

[xyz]

No tak si namiesto C/CPP predstav C/FPP, kde FPP je čisto funkcionálny predprocesor, trebárs doplnenie CPP o nejaký SK-kalkulus: bude to čisto funkcionálne aj turingovsky úplné. Nemusí to byť moc praktické - na riešenie praktických vecí z neslniečkového sveta tu predsa máme abstraktný typ C. 

Když si představím něco jiného, tak pro to bude i něco jiného platit, to dá rozum

Aj preto si myslím, že ti táto jednoduchá modifikácia musela byť zrejmá ešte predtým, než som ti o nej napísal. Mám teda za to, že sme si vyjasnili, že pre C/FPP tvoje námietky padajú.

Podle mě tohle prostě debatu nijak nevyjasňuje, spíš naopak.

A to si práve nemyslím.

Téma je už tak složitý a plný různých nuancí, tak by bylo lepší ho nezamlžovat...

Možno by pomohlo, keby si vysvetlil, v čom presne vidíš to zahmlievanie.  Možno zistíme, že ten pocit zahmlievania pramení len z toho, že veci, ktoré sa nám zdali jasné a dobre pochopené, až tak jasné či dobre pochopené nie sú. (A samozrejme, hovoríme všeobecne o akomsi prípadnom, tebou predpokladanom, zahmlievaní pre čitateľov tohto fóra.)

[Radek Miček]

Možno zistíme, že ten pocit zahmlievania pramení len z toho, že veci, ktoré sa nám zdali jasné a dobre pochopené, až tak jasné či dobre pochopené nie sú.

V principu to je velmi jednoduché - stačí znát definici jazyka - tj. typový systém, termy, hodnoty, redukci a na základě toho určíte, zda je jazyk čistě funkcionální.

Samozřejmě obecně může být potřeba rozhodnout HP, abyste zjistil, zda se chování programu nezmění, když výraz nahradíte jeho hodnotou. U běžných jazyků to však nebývá problém.

[Mirek Prýmek]

Napřed se objevil čumil, a začal vcelku logicky uvádět věci na pravou míru. [...] Závěr je ten, že čumil říkal že Haskell není čistý [...] ostatní zde tvrdili že Haskell je čistý

To jsi to špatně pochopil. Haskell umožňuje operaci, která může potenciálně způsobovat problémy (forknutí IO). Čumil řekl, že to je blbý a že lepší je řešení s UT. Jenže prakticky úplně stejného řešení dosáhneš s Haskellem pokud forknutí IO nepoužiješ. A naopak - pokud bys do jakéhokoli jazyka možnost mít víc IO vláken přidal, dostaneš se přesně tam, kde je Haskell. Proto je ta čumilova výhrada vůči Haskellu divná. Nikdo z něj nedělal blbce, ale těžko jazyku vyčítat, že má cosi navíc, co případně může způsobit problémy, a dávat za příklad jazyk, který tohle cosi navíc nemá a proto nemá ani ty problémy.

Jak jsem už tady kdesi psal, je to jako adorovat jako superbezpečný OS, který nepodporuje komunikaci po síti, a říkat, že to je daleko lepší než OS, který komunikaci po síti podporuje (a tím se vystavuje nebezpečí).

byly na mne moc složité řekl bych, podobně jako některé vysvětlení na internetu proč je Haskell čistý. [...] Citím se neskutečně otráveně a unaveně, myslím, že přesně to je jeden z důvodů proč se funkcionální jazyky nepoužívají,

No však tohle je taková "metadebata" o aspektech, který pro samotný programování nijak moc rozumět nemusíš. Když bys neměl moc zkušeností s OOP a přichomítl se k nějaké debatě třeba o těch záměrných nedokonalostech typového systému Swiftu, tak bys tomu taky nerozuměl. To přece není důvod nad tím úplně zlomit hůl...

A na závěr jsem se zde dověděl, že vlastně IO monáda je pro GUI nevýhodná, a že pro to je FRP o kterém nazačátku mluvil čumil.

No ale FRP mu nikdo nevyvracel, to může být dobré řešení, akorát je otázka, jakého problému a jak přesně použité. To už čumil nerozebral. Jenom tak plácnout "FRP" a tvářit se, že jsem tím něco vyřešil, žádné řešení ničeho není A mimochodem, FRP jde samozřejmě dělat i v Haskellu, takže to není nic proti němu

K tomu všemu jsem se dozvěděl že vlastně FRP je takřka to samé co IO monáda.

Ne, tady byla pointa jiná: pokud chceš mít čistý jazyk a zároveň ovlivňovat okolní svět, tak vždycky skončíš u toho, že budeš mít nějaký runtime, který bude spouštět nějaký předpis, který mu tím čistým způsobem vygeneruješ. V tomhle je to stejné, jinak se to samozřejmě v různých praktických aspektech může lišit. A nevím o tom, že by to šlo dělat nějak jinak, takže nemá smysl tímhle povyšovat jedno řešení nad jiné.

[Mirek Prýmek]

To už radši nasadím libovolný z dnešních jazyků, a budu mít to samé, a rychlejší.

To je naprosto v pořádku. Pokud ti nějaký přístup nevyhovuje, použij ten, který ti vyhovuje, to je naprosto správně. Rychlejší to být nemusí právě v případě, že budeš chtít masivně paralelizovat. Tam s OOP dost brzo narazíš.

Možno by pomohlo, keby si vysvetlil, v čom presne vidíš to zahmlievanie.

Myslím, že nemá smysl rozebírat do kdovíjaké hloubky jednu alegorii, která v jednom aspektu může sedět a ve spoustě jiných být úplně mimo...

[BoneFlute]

Napřed se objevil čumil, a začal vcelku logicky uvádět věci na pravou míru. [...] Závěr je ten, že čumil říkal že Haskell není čistý [...] ostatní zde tvrdili že Haskell je čistý

To jsi to špatně pochopil. Haskell umožňuje operaci, která může potenciálně způsobovat problémy (forknutí IO). Čumil řekl, že to je blbý a že lepší je řešení s UT. Jenže prakticky úplně stejného řešení dosáhneš s Haskellem pokud forknutí IO nepoužiješ. A naopak - pokud bys do jakéhokoli jazyka možnost mít víc IO vláken přidal, dostaneš se přesně tam, kde je Haskell. Proto je ta čumilova výhrada vůči Haskellu divná. Nikdo z něj nedělal blbce, ale těžko jazyku vyčítat, že má cosi navíc, co případně může způsobit problémy, a dávat za příklad jazyk, který tohle cosi navíc nemá a proto nemá ani ty problémy.

Já ho teda pochopil jinak. Jemu IMHO nešlo o to, že tam je nějaké forknutí  IO, nebo, že to jde obejít, ale o to, že monády z principu neřeší problém. Jedná se o nevhodné použití nástroje na problém vstupu a výstupu. Vždyť na IO se monáda používá jen proto, že umožňuje určit pořadí vyhodnocování. To je dost polovičaté, nemyslíš?

[Mirek Prýmek]

Já ho teda pochopil jinak. Jemu IMHO nešlo o to, že tam je nějaké forknutí  IO, nebo, že to jde obejít,

Začátek je tady: http://forum.root.cz/index.php?topic=11417.msg134386#msg134386 IO monáda není čistá, protože čisté IO neumožňuje race condition. A IO kdekoli (nejen v Haskellu) umožňuje RC jenom při vícevláknovém běhu. Čili IO v Haskellu není čisté právě proto, že umožňuje fork. Mně to přijde jako jednoduchý sylogismus

ale o to, že monády z principu neřeší problém. Jedná se o nevhodné použití nástroje na problém vstupu a výstupu. Vždyť na IO se monáda používá jen proto, že umožňuje určit pořadí vyhodnocování. To je dost polovičaté, nemyslíš?

Vůbec ne, protože řazení funkcí ve správném pořadí je to jediné, co u lazy jazyka pro IO potřebuješ. Nebýt línosti, monády bys vůbec nepotřeboval, protože referenční transparentnost máš zadarmo zaručenou tím, že funkci voláš pokaždé s jiným stavem světa, čili defacto volání funkce můžeš výslednou hodnotou nahradit jenom na tom jednom konkrétním místě.

[BoneFlute]

Já ho teda pochopil jinak. Jemu IMHO nešlo o to, že tam je nějaké forknutí  IO, nebo, že to jde obejít,

Začátek je tady: http://forum.root.cz/index.php?topic=11417.msg134386#msg134386 IO monáda není čistá, protože čisté IO neumožňuje race condition. A IO kdekoli (nejen v Haskellu) umožňuje RC jenom při vícevláknovém běhu. Čili IO v Haskellu není čisté právě proto, že umožňuje fork. Mně to přijde jako jednoduchý sylogismus

Imho to máš moc dlouhý. IOMonády nejsou čisté, protože umožňují RC. Přesněji, protože je nejde použít tak, aby k němu nemohlo dojít.
Nejde o to, že Haskell má forkování IO, ale o to, že nemá možnost, jak zabránit v IO race condition (při vícevláknovém běhu).

No, možná bych to popsal takto: unsafeIO mi jasně říká, že se bude dít nějaká divočina. Použitím více vláken mi nijak nenaznačuje - bacha, IOMonády nebudou fungovat korektně.

ale o to, že monády z principu neřeší problém. Jedná se o nevhodné použití nástroje na problém vstupu a výstupu. Vždyť na IO se monáda používá jen proto, že umožňuje určit pořadí vyhodnocování. To je dost polovičaté, nemyslíš?

Vůbec ne, protože řazení funkcí ve správném pořadí je to jediné, co u lazy jazyka pro IO potřebuješ. Nebýt línosti, monády bys vůbec nepotřeboval, protože referenční transparentnost máš zadarmo zaručenou tím, že funkci voláš pokaždé s jiným stavem světa, čili defacto volání funkce můžeš výslednou hodnotou nahradit jenom na tom jednom konkrétním místě.

Což ale u více vláken neplatí. Nebo se pletu?

[Mirek Prýmek]

Imho to máš moc dlouhý. IOMonády nejsou čisté, protože umožňují RC. Přesněji, protože je nejde použít tak, aby k němu nemohlo dojít.
Nejde o to, že Haskell má forkování IO, ale o to, že nemá možnost, jak zabránit v IO race condition (při vícevláknovém běhu).

No, možná bych to popsal takto: unsafeIO mi jasně říká, že se bude dít nějaká divočina. Použitím více vláken mi nijak nenaznačuje - bacha, IOMonády nebudou fungovat korektně.

To je pořád totéž: monády umožňují RC jenom při běhu ve více vláknech. Údajné řešení běh více vláken neumožňuje. Není tedy o nic lepší než monády.

Což ale u více vláken neplatí. Nebo se pletu?

Proč by to neplatilo? Monády jsou prostě způsob, jak lazy jazyk donutit dodržet nějaké pořadí vyhodnocování.

Ve více vláknech máš pak samozřejmě problém jejich prolínání, takže by se případně hodil i nějaký další mechanismus pro řazení těch vláken mezi sebou. To ale ten čumilem vyzdvihovaný Clean taky nedělá.

[BoneFlute]

Imho to máš moc dlouhý. IOMonády nejsou čisté, protože umožňují RC. Přesněji, protože je nejde použít tak, aby k němu nemohlo dojít.
Nejde o to, že Haskell má forkování IO, ale o to, že nemá možnost, jak zabránit v IO race condition (při vícevláknovém běhu).

No, možná bych to popsal takto: unsafeIO mi jasně říká, že se bude dít nějaká divočina. Použitím více vláken mi nijak nenaznačuje - bacha, IOMonády nebudou fungovat korektně.

To je pořád totéž: monády umožňují RC jenom při běhu ve více vláknech. Údajné řešení běh více vláken neumožňuje. Není tedy o nic lepší než monády.

Což ale u více vláken neplatí. Nebo se pletu?

Proč by to neplatilo? Monády jsou prostě způsob, jak lazy jazyk donutit dodržet nějaké pořadí vyhodnocování.

Ve více vláknech máš pak samozřejmě problém jejich prolínání, takže by se případně hodil i nějaký další mechanismus pro řazení těch vláken mezi sebou. To ale ten čumilem vyzdvihovaný Clean taky nedělá.

Protože přece o přesně o tomhle to bylo. Ty sám jsi tuším řekl, že napsat to čistě bez vláken je triviální.

To není pořád totéž, to je to na tom zásadní. Pokud ti monády zajišťují pořadí výpočtu, ale jen někdy, tak je to zajištění dost hloupé, to se na mě nezlob.

Proto jsem psal, že monády jsou nevhodně zvolený nástroj. Protože z toho jakože matematického hlediska dělají co mají a dělají to správně. Ale z praktického hlediska to nefunguje.

[Mirek Prýmek]

Protože přece o přesně o tomhle to bylo. Ty sám jsi tuším řekl, že napsat to čistě bez vláken je triviální.

Nebylo. Bylo to o tom, že Clean to má údajně uděláno dobře. Akorátže jenom pro jedno vlákno. Což je podmínka, za které jsou monády úplně stejně dobré.

Pokud ti monády zajišťují pořadí výpočtu, ale jen někdy, tak je to zajištění dost hloupé, to se na mě nezlob.

No zajišťují ti pořadí výpočtu v jednom vlákně - vytvářejí ti prostě možnost kousek kódu psát "imperativně" (do block). Pokud chceš nějakou synchronizaci mezi vlákny, je na to potřeba jiný nástroj. Na tom mi nepřijde nic polovičatého. Monády prostě dělají to, co dělat mají.