Má Haskell budoucnost?

[zboj]

"Return" to je v Haskellu a je to matoucí. Normálně se tomu říká "unit", což je mnohem názornější vzhledem k pravidlům pro monády, ne?

Jj.

Chtěl jsem jenom říct, že pokud bys chtěl, můžeš na levou stranu koleje napsat "x" a na pravou "[ x ]" a bude to stejně dobře vysvětlovat/ilustrovat/popisovat i jinou instanci monády - List. A jakoukoliv další. Akorát u těch funkcí je to takový nejnázornější. Funkce je prostě takový kolejiště, po kterým jezdí vláčky - vlákna. List s kolejištěm tak intuitivně nesouvisí

To teda fakt nesouvisí

[Reklama]

[v]

"Return" to je v Haskellu a je to matoucí. Normálně se tomu říká "unit", což je mnohem názornější vzhledem k pravidlům pro monády, ne?

Jj.

Chtěl jsem jenom říct, že pokud bys chtěl, můžeš na levou stranu koleje napsat "x" a na pravou "[ x ]" a bude to stejně dobře vysvětlovat/ilustrovat/popisovat i jinou instanci monády - List. A jakoukoliv další. Akorát u těch funkcí je to takový nejnázornější. Funkce je prostě takový kolejiště, po kterým jezdí vláčky - vlákna. List s kolejištěm tak intuitivně nesouvisí

To teda fakt nesouvisí

tak analogie vláčku a seznamu není zas tak přitažená za vlasy (v monádě pak pure ~ zařazení vagonu nebo přistoupení člověka na nádraží)

[zboj]

"Return" to je v Haskellu a je to matoucí. Normálně se tomu říká "unit", což je mnohem názornější vzhledem k pravidlům pro monády, ne?

Jj.

Chtěl jsem jenom říct, že pokud bys chtěl, můžeš na levou stranu koleje napsat "x" a na pravou "[ x ]" a bude to stejně dobře vysvětlovat/ilustrovat/popisovat i jinou instanci monády - List. A jakoukoliv další. Akorát u těch funkcí je to takový nejnázornější. Funkce je prostě takový kolejiště, po kterým jezdí vláčky - vlákna. List s kolejištěm tak intuitivně nesouvisí

To teda fakt nesouvisí

tak analogie vláčku a seznamu není zas tak přitažená za vlasy (v monádě pak pure ~ zařazení vagonu nebo přistoupení člověka na nádraží)

Aby pak ta metafora nebyla složitější než matematický zápis monád

[Mirek Prýmek]

K tem burritos - Crockford (alespon v tom videu, co jsem videl) monady primo neprirovnava k burritos. Tam slo o to ze

Aby clovek pochopil monady, musi se nejdrive naucit Haskell a teorii kategorii.

je v podstate to stejne jako

Aby clovek pochopil burritos, musi se nejdrive naucit spanelsky.

Rozhodne z toho nevyplyva, ze monady = burritos, "Haskell + teorie kategorii" = spanelstina nebo ze kdyz pochopim burritos, tak pochopim monady .

Jo, ale minule jsme se ještě bavili o jiném článku, kde někdo humorně psal zhruba ve stylu "No jasně, a pak vžycky přijde nějakej franta, kterej začne monády přirovnávat k burritos a jiní lidi to pochopí tak, že monády voní"

Prostě metafory jsou nebezpečné, v tom s "v" souhlasím.

Je opravdu k placi videt tu argumentovat C#pistu, jak ze pojmenovani "map, fold/reduce, filter" je nevhodne, ze C# to ma jako "select, aggregate, where" a jak je to mnohem nazornejsi a lip to vystihuje danou funkci...

Ty a to mně třeba vůbec nepobuřuje. Mám radost z toho, že principy FP probublávají do jiných jazyků a těší mě, když se lidi naučí s tím pracovat, protože ty jiné jazyky jim nevytvářejí tolik bariér jako třeba právě ten Haskell. A vůbec mi nevadí ani když "obyčejný" programátor tu věc používá a o jejich FP kořenech vůbec neví. No a? Hlavně že si osvojil hezký FP přístup a píše pěkný kód, no ne? Co můžeš mít proti?
 

Hodne me prekvapilo, kdyz jsem se dozvedel o Redux, ktere je v podstate FRP (ted se divam na ten clanek a ono to cerpa i z Elmu, nepsal jsi v tom?). Ve vodach Reactu je to myslim hodne popularni a uz i s Angularem to lidi pouzivaji.

Ne, nedělal, nejsem webař, webařinu dělám jenom tak trochu. Když jsem si dělal letmej průzkum, co by se na frontendu dalo použít, viděl jsem mj. vtipnej článek o tom, že abyste v JS světě dosáhli všeho toho, co máte v Elmu musíte mít: React, Redux, bla bla bla... (ten seznam byl hrozně dlouhej) - a ten článek končil ve stylu "no a stojí vám to za to?!"

Osobně jsem z JS světa nejvíc koketovat s Motorcycle, udělal jsem si pár pokusů v něm a v Elmu a hrozně moc mě odradilo to, že v Motorcycle z povahy věci (JS) může k chybě dojít kdekoli až v runtime, přičemž extenxivní používání různých futures a lazy eval atd. pak dělají tu chybu strašně těžko debugovatelnou. Tenhle dojem jsem hodně rychle nabyl a byl to definitivní důvod, proč jsem šel cestou Elmu. Možná na ten debug existují nějaký fígle, ale rychle jsem nabyl dojmu, že fakt nechci mít deset narovnáváků na pět ohýbáků a to všechno ještě dávat dohromady nějakým Gruntem nebo kýho čerta

[andy]

Ad vysvětlení Monadu -  já mám pocit, že Monady nechápu pořádně doteď. Ty základní už jo, ale to je v podstatě díky tomu, že to člověk používá, naběhne si na spoustu vidlí a problému při konverzi typů, takže pak pochopí, jak to funguje. Na začátku jsem vůbec netušil, co je třeba tohle:

Kód: [Vybrat]

newtype Reader r a = Reader { runReader :: r -> a }A popravdě i teď bych nad tím musel drobet přemýšlet. Trochu líp jsem to pochopil, když jsem se snažil pochopit Free/Operational monad, ale pak přijde ContT a jsem zase v háji... Ta výhybková notace je hezká, jenomže když pak třeba pomocí Monadu implementujete něco jako Pipe (nebo třeba inkrementální parser), tak vám výhybka moc nepomůže.

Ještě jsem to nikomu nevysvětloval, ale v současné době mi nejlepší přijde analogie "programovatelného středníku" v "do" notaci. V podstatě tenhle článek http://apfelmus.nfshost.com/articles/operational-monad.html. A chápu, že začátečník se nad tím osype, ale pro mě tohle tak nějak vedlo k pochopení, co to Monad je. Aspoň trošku.

[Reklama]

[Mirek Prýmek]

Aby pak ta metafora nebyla složitější než matematický zápis monád

Přesně )))

Víte, sčítání, to je vlastně jako když vláček jede s polozataženými okýnky a do jednoho z těch okýnek vletí brambora s křídly a z druhé strany vypadne bábovka )

[Mirek Prýmek]

v současné době mi nejlepší přijde analogie "programovatelného středníku" v "do" notaci.

Mně přijde do notace naopak jako to největší zlo, které nikdy nemělo vzniknout a když už vzniklo, tak se na něho mělo zapomenout a kdokoli by se měl stydět ho zmínit

[noef]

Je opravdu k placi videt tu argumentovat C#pistu, jak ze pojmenovani "map, fold/reduce, filter" je nevhodne, ze C# to ma jako "select, aggregate, where" a jak je to mnohem nazornejsi a lip to vystihuje danou funkci...

Ty a to mně třeba vůbec nepobuřuje. Mám radost z toho, že principy FP probublávají do jiných jazyků a těší mě, když se lidi naučí s tím pracovat, protože ty jiné jazyky jim nevytvářejí tolik bariér jako třeba právě ten Haskell. A vůbec mi nevadí ani když "obyčejný" programátor tu věc používá a o jejich FP kořenech vůbec neví. No a? Hlavně že si osvojil hezký FP přístup a píše pěkný kód, no ne? Co můžeš mít proti?

Jako ja jsem samozrejme taky rad, ze FP se pouziva i v tak popularnim jazyce, jako je C#. Ale mrzi me, ze pak pul vlakna o FP se resi, ze tohle C# mel davno a C#pisti se tam placaji po zadech, jak ostatni jazyky a pristupy jsou zaostale. Az po nekolika stranach, kdyz lidi postli dostatek dukazu ( ), ze M$ opravdu to FP nevymyslel, tak jim doslo, ze asi nemaji pravdu a radeji prestali psat. Pritom stacilo mit na skole jeden predmet, kde si prakticky zkusili, jak ten map/filter/fold funguji, splacali projekt a uznali, ze je to zajimava alternativa k cyklu a zaradili si to v hlavne k potencionalnimu hlubsimu prozkoumani v budoucnu, az bude cas nebo mezi kandidaty na volitelne predmety.

[Mirek Prýmek]

Já fakt nechápu, co je za komplikace v default-lazy jazyku.

1. je to pro běžné programátory nepřirozené (většina jazyků je eager)
2. neodpovídá to tomu, jak skutečně počítač na hw úrovni funguje, takže se to de facto musí nějak mapovat jedno na druhé a každé mapování zhoršuje tvoji schopnost uvažovat nad vlastnostmi výsledku.

Normální eager evaluace funguje jako kuchařka: 1. vem vejce 2. rozklepni ho do misky 3. utři ho s cukrem

Nikomu se dobrovolně nechce přemýlet nad tím, jak to dopadne, když k rozklepnutí vajíčka dojde až po utření

Třeba tohle používám naprosto běžně:

Kód: [Vybrat]

zip konecny_seznam [1..] To prostě strict nefunguje. Resp. funguje, když vymyslíš speciální definici listu, aby byl lazy.

Jo, to máš částečně pravdu. Ale 1. když to neznáš, tak to nepotřebuješ (je to "třešnička navíc") 2. stejně elegantně jako lazy evaluací se to dá řešit nějakou podobou streamu, která je intuitivně daleko pochopitelnější.

Ale mě to přijde jako naprosto zbytečná komplikace

Komplikace to je, ale nic nemůže být větší komplikace než nutnost pochopit IO monádu, abys mohl vypsat Hello, Mirek

[Mirek Prýmek]

Ale mrzi me, ze pak pul vlakna o FP se resi, ze tohle C# mel davno a C#pisti se tam placaji po zadech, jak ostatni jazyky a pristupy jsou zaostale.

Tak co, no? Ty to víš, jak to je, tak se nad tím můžeš jenom pousmát, ne?

[zboj]

Aby pak ta metafora nebyla složitější než matematický zápis monád

Přesně )))

Víte, sčítání, to je vlastně jako když vláček jede s polozataženými okýnky a do jednoho z těch okýnek vletí brambora s křídly a z druhé strany vypadne bábovka )

To je citace z čeho?

[Kit]

Aby pak ta metafora nebyla složitější než matematický zápis monád

Přesně )))

Víte, sčítání, to je vlastně jako když vláček jede s polozataženými okýnky a do jednoho z těch okýnek vletí brambora s křídly a z druhé strany vypadne bábovka )

To je citace z čeho?

Odtud: http://forum.root.cz/index.php?topic=13225.msg166129#msg166129

[Mirek Prýmek]

To je citace z čeho?

To je volná improvizace na tebou nadnesenou myšlenku

[andy]

Jo, to máš částečně pravdu. Ale 1. když to neznáš, tak to nepotřebuješ (je to "třešnička navíc") 2. stejně elegantně jako lazy evaluací se to dá řešit nějakou podobou streamu, která je intuitivně daleko pochopitelnější.

tak když neznáš haskell a FP tak to taky nepotřebuješ... ale hlavně vůbec nechápu, co je na laziness tak složitého. Jakýkoliv strict program funguje úplně v pohodě v lazy prostředí. Opačně to neplatí. Ano, můžeš si udělat explicitní "thunk" jako v Purescriptu, případně s podporou jazyka (ocaml???), ale u člověka, by třeba s haskellem začínal, mi vůbec není jasné, proč by měl laziness řešit. Tak se tvař, že to je strict, výsledky z toho budou padat stejné. Kde je problém?

Nikomu se dobrovolně nechce přemýlet nad tím, jak to dopadne, když k rozklepnutí vajíčka dojde až po utření

Jenomže to je monadická záležitost. Pure FP, kde je laziness vidět nejvíc, je spíš něco jako "projektový plán". A "krizový management" taky nevyhodnocuješ "eager", ale teprve až v momentě, kdy přijde krize.

v současné době mi nejlepší přijde analogie "programovatelného středníku" v "do" notaci.

Mně přijde do notace naopak jako to největší zlo, které nikdy nemělo vzniknout a když už vzniklo, tak se na něho mělo zapomenout a kdokoli by se měl stydět ho zmínit

Když mě to vysvětlení, že to je programovatelný středník připadá, že to vlastně ani není analogie. A té do-notaci to prostě sedí. Ty příšernosti s "\x -> a >>= ..." jsem fakt nechápal. IMO když se začne s tím, že to je monoid (tedy programovatelný středník, asociativní ideálně jako a >> (b >> c)) a pak se to rozšíří o to vysvětlení, jak se přenáší hodnota z jednoho kusu výpočtu, tak to nepoužívá analogie a je to jednoduché na pochopení. Ale možná jsem ztratil schopnost to vysvětlit....

[zboj]

Jo, to máš částečně pravdu. Ale 1. když to neznáš, tak to nepotřebuješ (je to "třešnička navíc") 2. stejně elegantně jako lazy evaluací se to dá řešit nějakou podobou streamu, která je intuitivně daleko pochopitelnější.

tak když neznáš haskell a FP tak to taky nepotřebuješ... ale hlavně vůbec nechápu, co je na laziness tak složitého. Jakýkoliv strict program funguje úplně v pohodě v lazy prostředí. Opačně to neplatí. Ano, můžeš si udělat explicitní "thunk" jako v Purescriptu, případně s podporou jazyka (ocaml???), ale u člověka, by třeba s haskellem začínal, mi vůbec není jasné, proč by měl laziness řešit. Tak se tvař, že to je strict, výsledky z toho budou padat stejné. Kde je problém?

Nikomu se dobrovolně nechce přemýlet nad tím, jak to dopadne, když k rozklepnutí vajíčka dojde až po utření

Jenomže to je monadická záležitost. Pure FP, kde je laziness vidět nejvíc, je spíš něco jako "projektový plán". A "krizový management" taky nevyhodnocuješ "eager", ale teprve až v momentě, kdy přijde krize.

v současné době mi nejlepší přijde analogie "programovatelného středníku" v "do" notaci.

Mně přijde do notace naopak jako to největší zlo, které nikdy nemělo vzniknout a když už vzniklo, tak se na něho mělo zapomenout a kdokoli by se měl stydět ho zmínit

Když mě to vysvětlení, že to je programovatelný středník připadá, že to vlastně ani není analogie. A té do-notaci to prostě sedí. Ty příšernosti s "\x -> a >>= ..." jsem fakt nechápal. IMO když se začne s tím, že to je monoid (tedy programovatelný středník, asociativní ideálně jako a >> (b >> c)) a pak se to rozšíří o to vysvětlení, jak se přenáší hodnota z jednoho kusu výpočtu, tak to nepoužívá analogie a je to jednoduché na pochopení. Ale možná jsem ztratil schopnost to vysvětlit....

Slovo "monoid" se tady na fóru nevyslovuje (pokud teda - podle některých - nejsi autista)