Má Haskell budoucnost?

[zboj]

To je ale trochu zjednodušující, seznam je taky monáda a takto vysvětlit nejde, ne?

byl jste rychlejší, dále např. identity, reader, state

a taky IO
prostě říct, že monáda je jako tamto kolejiště je jako říct, že monáda je jako burrito

Tak ty koleje vysvětlují celkem hezky (polopaticky) právě to Maybe, ale nic jiného kolem monád. Možná že každá konkrétní monáda vyžaduje svou metaforu.

[Reklama]

[v]

To je prostě jen jeden typ monády, Maybe nebo případně Error.
[/quote]
nebo Either nebo Except... zpracování chybových stavů tady ještě nikdo nezmínil jako problém haskellu

[v]

Tak ty koleje vysvětlují celkem hezky (polopaticky) právě to Maybe, ale nic jiného kolem monád. Možná že každá konkrétní monáda vyžaduje svou metaforu.

možná, že jeden z problémů je používání metafor

[zboj]

Tak ty koleje vysvětlují celkem hezky (polopaticky) právě to Maybe, ale nic jiného kolem monád. Možná že každá konkrétní monáda vyžaduje svou metaforu.

možná, že jeden z problémů je používání metafor

Nevím, mně přijdou taková porovnání celkem užitečná, i Einstein přece létal na paprsku světla (díky čemuž jsem kdysi dávno pochopil speciální teorii relativity)

[Mirek Prýmek]

To je prostě jen jeden typ monády, Maybe nebo případně Error.

Přesně tak, je to jedna instance obecného konceptu monády, kde se dá snadno ukázat, k čemu je to všechno dobré,  1. aniž by bylo potřeba napsat jedinou řádku kódu nebo jiného symbolického zápisu 2. aniž by to bylo zavádějící jako burritos.

[Reklama]

[Mirek Prýmek]

možná, že jeden z problémů je používání metafor

To ale de facto není metafora. Je to v podstatě jenom jiný zápis (jiná symbolická reprezentace), stejně jako třeba graf je jiný zápis tabulky čísel.

[zboj]

možná, že jeden z problémů je používání metafor

To ale de facto není metafora. Je to v podstatě jenom jiný zápis (jiná symbolická reprezentace), stejně jako třeba graf je jiný zápis tabulky čísel.

Když řeknu, že monáda jsou koleje, tak to metafora je

[Mirek Prýmek]

Když řeknu, že monáda jsou koleje, tak to metafora je

No... ne tak docela. Asi nebudeš rozporovat tvrzení

Monáda je

class Monad m where 
    return :: a -> m a 
 
    (>>=) :: m a -> (a -> m b) -> m b 
 
    (>>) :: m a -> m b -> m b 
    x >> y = x >>= \_ -> y 
 
    fail :: String -> m a 
    fail msg = error msg 

- takže co monáda je, jsem definoval pomocí nějaké posloupnosti symbolů.

...a každý ten řádek (řekněme "aspekt monády"?) můžeš zapsat právě pomocí toho "kolejového zápisu".

[zboj]

Když řeknu, že monáda jsou koleje, tak to metafora je

No... ne tak docela. Asi nebudeš rozporovat tvrzení

Monáda je

class Monad m where 
    return :: a -> m a 
 
    (>>=) :: m a -> (a -> m b) -> m b 
 
    (>>) :: m a -> m b -> m b 
    x >> y = x >>= \_ -> y 
 
    fail :: String -> m a 
    fail msg = error msg 

- takže co monáda je, jsem definoval pomocí nějaké posloupnosti symbolů.

...a každý ten řádek (řekněme "aspekt monády"?) můžeš zapsat právě pomocí toho "kolejového zápisu".

Tak lingvisticky to metafora je, ale nehodlám se hádat o slovíčka. Hlavní je, že omezíme-li se na ošetřování výjimek, je to celkem povedené vysvětlení. Ale co s jinými instancemi monád?

[Mirek Prýmek]

Ale co s jinými instancemi monád?

Jiné instance monád jde takhle vysvětlit/ilustrovat taky, ale už tam nebude taková hnedka zřejmá korespondence. Ale to není ani u toho klasického zápisu. Zkus někomu vysvětlit, že vytvoření singletonu x ->

• se jmenuje return

[zboj]

Ale co s jinými instancemi monád?

Jiné instance monád jde takhle vysvětlit/ilustrovat taky, ale už tam nebude taková hnedka zřejmá korespondence. Ale to není ani u toho klasického zápisu. Zkus někomu vysvětlit, že vytvoření singletonu x ->

• se jmenuje return

"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?

[v]

Ale co s jinými instancemi monád?

Jiné instance monád jde takhle vysvětlit/ilustrovat taky, ale už tam nebude taková hnedka zřejmá korespondence. Ale to není ani u toho klasického zápisu. Zkus někomu vysvětlit, že vytvoření singletonu x ->

• se jmenuje return

"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?

return IMHO vznikl kvůli "do" notaci, jinak Monad je applicative functor, takže k dispozice je funkce "pure"

[Mirek Prýmek]

"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í

[noef]

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 .

Prostě, mám pocit, že tohle téma může dobře vysvětlit jenom člověk, kterej nemá potřebu dělat chytrýho, ale naopak se rád sníží k "dětinským" příkladům, aby studenty látku efektivně naučil. A takových učitelů je bohužel na našich VŠ asi dost málo...

Tesat do kamene. Na VUT FIT v Brne jsme meli hodne ucitelu, kteri vucovani moc nezvladali (casto matematiky a ty silne teoreticke predmety; ale nebudu jmenovat, protoze tam byla alespon ta snaha). Bylo to neprijmne, protoze nejen, ze latka byla velmi narocna, navic nebyla vysvetlena moc dobre. No, a pak tam bylo nekolik presne takovych prednasejicich, o kterych pises (a shodou [?] okolnosti zrovna i ten FP predmet) - namachrovani, nikdy si neodpusti studenta shodit, otevrene davaji najevo (nekteri to i na rovinu rekli), jak vsichni studenti jsou flakaci a oni prednasi, jen aby meli penize na svuj vyzkum, at je tedy moc neotravujeme (mezi takove patrili pan Hruska a pan Kolar).

Je to škoda. Zrovna tohle by si zasloužil znát každý mírně nadprůměrný programátor...

Bych sel klidne i dal, kazdy prumerny by to mohl znat. Jako takove ty nejjednodussi veci typu operace nad kolekcemi si myslim nikomu neublizi a mohou hodne pomoci. I pokud jde o prumerneho programatora (coz neberu jako nic spatneho, sam se asi radim do teto kategorie, protoze z te teorie znam opravdu malo), ktery bude vyvojarit v Java/C#/JavaScriptu/PHP, tak snad vsude jsou dostupne budto primo v jazyku nebo pomoci externich knihoven nastroje umoznujici nejaky zakladni FP pristup (Java s verzi 8, C# ma ty divne metody ala SQL, JS treba Lodash, pro PHP jsem vygooglil functional-php).

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...

FP určitě do mainstreamu pronikat bude (už se to masově děje), ale řekl bych, že spíš v takové té pragmatičtější formě - jako volitelná součást, použitelná, pokud programátor chce, ale nesvazující ho tam, kde nechce.

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.

Prave treba ta Scala, si myslim, je to pragrmaticke vyusteni - hybrid mezi OOP a FP. Pro lidi prechazejici z Javy lze psat skoro stejnym stylem ve Scale, jak byli zvykli v Jave (jsou tu vyjimky, treba pouze jeden hlavni konstruktor a ostatni musi pouzivat ten hlavni - to pro me byl ze zacatku maly sok). Ale postupne muzou zacit experimentovat s FP stylem s kolekcemi, ktere maji opravdu spoustu uzitecnych funkci, a jit jen tak daleko s FP, jak oni (nebo jejich tym) budou chtit.

[andy]

Aha, ok. Na link jsem se předtím zběžně koukl, ale netušil jsem, co chceš říct, tak jsem nevěděl, co tam mám hledat

Máš pravdu, je to komplikace. Ale když máš default-lazy jazyk, tak je těch komplikací víc a jsou hlubší. Tohle je lahoda.

Navíc místo dvou funkcí můžeš použít (jak říká Radek) nějakou obálku typu future apod. Pořád je to řádově jednodušší než tanečky s IO monádou

Já fakt nechápu, co je za komplikace v default-lazy jazyku. Ano, když píšeš multithreadované programy s inter-thread komunikací, tak si pravděpodobně velmi rychle naběhneš na to, že je rozumné dělat strict datové struktury a na IORefy a spol budeš používat výhradně strict funkce. A... pokud tohle uděláš, tak v podstatě komplikace zmizely.  Tak proč se zatěžovat nějakýma obálkama apod.? Fakt mi přijde, že v tomhle se z komára dělá velbloud. 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.

Ale mě to přijde jako naprosto zbytečná komplikace - stejně jako v případě toho Maybe. Vůbec netuším, co tím získám (v případě Purescriptu vím, co tím získám - to, že výsledný kód je čitelný javascript, ale to mě v případě haskellu nezajímá).