Funkcionální programátor

Greenhorn

Re:Funkcionální programátor
« Odpověď #315 kdy: 07. 07. 2015, 20:29:04 »
A co o nich psal špatného? Mne se jeho logika příjemně chápala, byla jasná a stručná. Prosím, neříkejte o někom že něčemu vůbec nerozumí, já bych si něco takového už jen z pohledu vlastních zkušeností nedovolil. A vy máte zkušenosti podobné jako já, pokud vycházím z vytvořených projektů.
Tohle : http://forum.root.cz/index.php?topic=11417.msg134558#msg134558

Ano, má tam spoustu věcí správně ale taky dost zásadní chyby. Třeba to o mutable proměnných v bodu 3. Ano, Haskell je umí a Clena je neumí jen proto že je tam zatím nikdo neimplementoval. Pokud jsou v něčem soubory, tak mutable proměnné taky musí jít. Je úplně jedno, co přesně jsou ty malé kousky stavu co program mění. UT tomu nijak nebrání. Ani s referenční transparentností na tom jsou monády úplně stejně. Výraz s objektem world se nahradit návratovou hodnotou nedá, protože world v principu závisí na čase a stavu celého světa v daném čase.

Ty Lazy streams taky nejsou žádná ultimátní stříbrná kulka. Jsou blbě rozšiřitelné, s jedním streamem může pracovat jenom jedno vlákno.

Ano, obecné věci o FP tam má dobře. Akorát v těch detailech má kopec chyb. A ty detaily nám tu otloukal o hlavu s takovou vervou, že to dopadlo tímhle flamem.
Děkuji za shrnutí. Zajímavé. Dává to smysl, mutable proměnná se dá udělat i pomocí souborů. Když se na to koukám takto, ani Clean nebude skutečně čistý, protože nezabraňuje tady tomu problému. Jak říkal čumil to o tom vytékání dat vstupem, Clean to bude umožňovat i přes UT taky. Zajímavé. A proč by nemohly být lazy streams ultimátní stříbrná kulka? Runtime může rozkaz vykonat v kolika vláknech chce. A samotný funkcionální kód má zase svoje metody jak běžet paralelně. V tomto nevidím problém. Pletu se někde?


Greenhorn

Re:Funkcionální programátor
« Odpověď #316 kdy: 07. 07. 2015, 20:35:53 »
Je to jen taková poznámka. Něco co mne napadlo. Koukal jsem se na unique typing a myslím že jsem ho vcelku pochopil. My nemůže zkopírovat objekt World prostě proto, že zkopírovat svět nejde, objekt World je jen reference na svět, ne samotný svět, a podle UT s objektem musí pracovat pouze jedno jediné vlákno. Kdyby jsme zkopírovali World, budou existovat dvě reference na ten skutečný svět, a tím pádem už to nebude UT, protože s objektem bude pracovat více vláken.
A tady leží ten zásadní problém. O objektu World se dá uvažovat jako o singletonu. S tím ale UT nijak nepomůže. Ten umí  zaručit že na objekt bude existovat jediná reference. Ale těch jednotlivých objektů může být neomezeně.
Pro jazyk je objekt World naprosto normální entita. Netuší že je to fake reprezentace něčeho jiného. Dá se jich vytvořit libovolné množství. Jediné co tomu brání je, že to ještě nikdo nenapsal. Není to nic za co by mohlo UT. UT řeší jen unikátnost "ukazatelů". Neřeší to, na co ty ukazatele ukazují.
Závěr, pokud to správně chápu, je ten, že jak IO monáda v Haskellu, tak UT v Cleanu vykazují známky nečistoty. Akorát UT se tváří že je čistější než IO monáda, ale ve výsledku není.

Re:Funkcionální programátor
« Odpověď #317 kdy: 07. 07. 2015, 21:09:02 »
vykazují známky nečistoty
Podle jaké definice? Musí to být definice absurdní, protože pokud IO jako takové, samo o sobě znamená nečistotu, potom čistý může být jenom program bez IO - čili program, který nic neumí vyprodukovat, nic neumí vypočítat... Ok, může být, akorát taková čistota pak asi není něco, o co by kdokoli stál...

v

Re:Funkcionální programátor
« Odpověď #318 kdy: 07. 07. 2015, 21:36:02 »
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ě
A co o nich psal špatného? Mne se jeho logika příjemně chápala, byla jasná a stručná. Prosím, neříkejte o někom že něčemu vůbec nerozumí, já bych si něco takového už jen z pohledu vlastních zkušeností nedovolil. A vy máte zkušenosti podobné jako já, pokud vycházím z vytvořených projektů.

uvedl měnitelné reference jako důkaz nečistototy io monády, ale ty se dají implementovat i ve State monádě, která je 100% čistá, krom toho je to v rozporu s definicí kterou sám uvedl - funkce v prostředí, zápis do reference způsobí změnu prostředí

v

Re:Funkcionální programátor
« Odpověď #319 kdy: 07. 07. 2015, 21:41:14 »
vykazují známky nečistoty
Podle jaké definice? Musí to být definice absurdní, protože pokud IO jako takové, samo o sobě znamená nečistotu, potom čistý může být jenom program bez IO - čili program, který nic neumí vyprodukovat, nic neumí vypočítat... Ok, může být, akorát taková čistota pak asi není něco, o co by kdokoli stál...

neinteraktivní není neužitečný :)


Re:Funkcionální programátor
« Odpověď #320 kdy: 07. 07. 2015, 21:42:17 »
neinteraktivní není neužitečný :)
No jo, jenže podle téhle definice čistoty by nešel ani batch processing :)

Greenhorn

Re:Funkcionální programátor
« Odpověď #321 kdy: 07. 07. 2015, 21:43:06 »
vykazují známky nečistoty
Podle jaké definice? Musí to být definice absurdní, protože pokud IO jako takové, samo o sobě znamená nečistotu, potom čistý může být jenom program bez IO - čili program, který nic neumí vyprodukovat, nic neumí vypočítat... Ok, může být, akorát taková čistota pak asi není něco, o co by kdokoli stál...
Čumil tu definici moc hezky napsal. Podle matematické definice. Oboje metody podle mích zkušeností umožňují dělat nedeterministické funkce. V Cleanu nemám zkušenosti, ale jak JSH napsal, je to takřka to samé co IO monáda. A navíc, IO lze dělat. Jen vypadá výrazně jinak, než na co jsme my programátoři odkojení na klasických jazycích zvyklí.

Greenhorn

Re:Funkcionální programátor
« Odpověď #322 kdy: 07. 07. 2015, 21:45:07 »
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ě
A co o nich psal špatného? Mne se jeho logika příjemně chápala, byla jasná a stručná. Prosím, neříkejte o někom že něčemu vůbec nerozumí, já bych si něco takového už jen z pohledu vlastních zkušeností nedovolil. A vy máte zkušenosti podobné jako já, pokud vycházím z vytvořených projektů.

uvedl měnitelné reference jako důkaz nečistototy io monády, ale ty se dají implementovat i ve State monádě, která je 100% čistá, krom toho je to v rozporu s definicí kterou sám uvedl - funkce v prostředí, zápis do reference způsobí změnu prostředí
Zajímavé. Mohl by jste to první více vysvětlit? A druhou část komentáře jsem bohužel nepochopil.

Re:Funkcionální programátor
« Odpověď #323 kdy: 07. 07. 2015, 21:46:59 »
Čumil tu definici moc hezky napsal.
Myslíš tu, kterou Haskell splňuje?

http://forum.root.cz/index.php?topic=11417.msg134755#msg134755

v

Re:Funkcionální programátor
« Odpověď #324 kdy: 07. 07. 2015, 21:49:31 »
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ě
A co o nich psal špatného? Mne se jeho logika příjemně chápala, byla jasná a stručná. Prosím, neříkejte o někom že něčemu vůbec nerozumí, já bych si něco takového už jen z pohledu vlastních zkušeností nedovolil. A vy máte zkušenosti podobné jako já, pokud vycházím z vytvořených projektů.

uvedl měnitelné reference jako důkaz nečistototy io monády, ale ty se dají implementovat i ve State monádě, která je 100% čistá, krom toho je to v rozporu s definicí kterou sám uvedl - funkce v prostředí, zápis do reference způsobí změnu prostředí
Zajímavé. Mohl by jste to první více vysvětlit? A druhou část komentáře jsem bohužel nepochopil.

ve State monádě lze implementovat měnitelné reference, funkce jako createVar, readVar, writeVar, uvedel jsem tayd kus kódy, který demonstruje kdy v čistém kódu dvě různá volání stejné funkce vrátí jinou hodnotu

Greenhorn

Re:Funkcionální programátor
« Odpověď #325 kdy: 07. 07. 2015, 22:01:57 »
Čumil tu definici moc hezky napsal.
Myslíš tu, kterou Haskell splňuje?

http://forum.root.cz/index.php?topic=11417.msg134755#msg134755
Můžete si říkat co chcete, já nejsem zažraný teoretik. Když můžu v Haskellu napsat kód, který vypadá a chová se úplně stejně jako kód napsaný v Cčku, tak Haskell prostě není pure. Alespoň pro mne jako pro obyčejného programátora. To už bych mohl odůvodnění proč je Haskell pure naroubovat i na Cčko. A to by se pak člověku vysmál každý řekl bych. Nejsem jediný programátor který je Haskellem silně zmaten.

Greenhorn

Re:Funkcionální programátor
« Odpověď #326 kdy: 07. 07. 2015, 22:03:22 »
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ě
A co o nich psal špatného? Mne se jeho logika příjemně chápala, byla jasná a stručná. Prosím, neříkejte o někom že něčemu vůbec nerozumí, já bych si něco takového už jen z pohledu vlastních zkušeností nedovolil. A vy máte zkušenosti podobné jako já, pokud vycházím z vytvořených projektů.

uvedl měnitelné reference jako důkaz nečistototy io monády, ale ty se dají implementovat i ve State monádě, která je 100% čistá, krom toho je to v rozporu s definicí kterou sám uvedl - funkce v prostředí, zápis do reference způsobí změnu prostředí
Zajímavé. Mohl by jste to první více vysvětlit? A druhou část komentáře jsem bohužel nepochopil.

ve State monádě lze implementovat měnitelné reference, funkce jako createVar, readVar, writeVar, uvedel jsem tayd kus kódy, který demonstruje kdy v čistém kódu dvě různá volání stejné funkce vrátí jinou hodnotu
O tom nic nevím. Byl by jste tak hodný, a napsal delší okomentovanou ukázku?

Re:Funkcionální programátor
« Odpověď #327 kdy: 07. 07. 2015, 22:07:57 »
Když můžu v Haskellu napsat kód, který vypadá a chová se úplně stejně jako kód napsaný v Cčku, tak Haskell prostě není pure.
No, to je dost zvláštní tvrzení. Představ si, že bys měl main funkci, která by vracela "seznam IO akcí" - načti tohle, vraž to sem, zapiš tohle tam. Výsledkem main funkce by byl jenom tenhle seznam. což je statická abstraktní struktura, kterou jistě můžeš generovat čistě.

...no a tuhle strukturu prostě vezmeš a v runtimu uděláš ty akce. Co je na tom teda nečistého a podle jaké definice?

No a tohle je v podstatě přesně to, co IO monáda dělá.

v

Re:Funkcionální programátor
« Odpověď #328 kdy: 07. 07. 2015, 22:09:41 »
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ě
A co o nich psal špatného? Mne se jeho logika příjemně chápala, byla jasná a stručná. Prosím, neříkejte o někom že něčemu vůbec nerozumí, já bych si něco takového už jen z pohledu vlastních zkušeností nedovolil. A vy máte zkušenosti podobné jako já, pokud vycházím z vytvořených projektů.

uvedl měnitelné reference jako důkaz nečistototy io monády, ale ty se dají implementovat i ve State monádě, která je 100% čistá, krom toho je to v rozporu s definicí kterou sám uvedl - funkce v prostředí, zápis do reference způsobí změnu prostředí
Zajímavé. Mohl by jste to první více vysvětlit? A druhou část komentáře jsem bohužel nepochopil.

ve State monádě lze implementovat měnitelné reference, funkce jako createVar, readVar, writeVar, uvedel jsem tayd kus kódy, který demonstruje kdy v čistém kódu dvě různá volání stejné funkce vrátí jinou hodnotu
O tom nic nevím. Byl by jste tak hodný, a napsal delší okomentovanou ukázku?

import Control.Monad.State

f = evalState g 0
   where g = do
      a <- get
      put 1
      b <- get
      return (a, b)

main = print f

vypíše (0,1), tj. get vrátí pokaždé jinou hodnotu, přesto je f čistá funkce, čarodějnictví?!

Re:Funkcionální programátor
« Odpověď #329 kdy: 07. 07. 2015, 22:14:45 »
vypíše (0,1), tj. get vrátí pokaždé jinou hodnotu, přesto je f čistá funkce, čarodějnictví?!
Ovšem to "a <- get" není, pokud se nepletu, normální volání normální funkce. Takže to "různá volání stejné funkce vrátí jinou hodnotu" je přinejmenším zavádějící.

Teď si z hlavy nevybavím, jak to tam přesně je, ale v principu to bude syntaktický cukr pro dvoje volání nějaké lambdy s různými parametry.