Má Haskell budoucnost?

[Mirek Prýmek]

program v haskellu napsaný tak jako by haskell byl eager bude fungovat v lazy haskellu stejně jako v tom teoretickém eager

No ale co by to mělo dokazovat? Haskell je složitý, protože je lazy a ty lazy obraty by fungovaly i kdyby lazy nebyly?! No to dá rozum, na tom není nic zajímavého. Zajímavé je to, že ty obraty jsou složité, ABY mohly být lazy. Pokud jazyk lazy není, složité obraty nepotřebuje. To je odpověď na tu otázku "čemu vadí, že je lazy".

[Reklama]

[andy]

Nevím, co myslíš tím "monadická záležitost". Haskell prostě může cokoli vyhodnotit kdykoli, takže kdybych dal za sebe

Kód: [Vybrat]

print "a"
print "b"
tak mi to může vypsat "a\nb\n" i "b\na\n".

Nemůže. Protože to za sebe dáš akorát tak v IO monadu, jinde ne. Musíš trošičku pochopit IO monad (spíš rozdíl mezi pure a non-pure, kdy použít let a kdy <-). Lazy jsou pure výpočty, efekty jsou vždy explicitně řazeny. Takže IMO to prostě nemá vůbec žádný smysl řešit.

Tomu říkáš "co je na tom za komplikaci"?

Tak když vezmu třeba příklad, co tady byl dán:

Kód: [Vybrat]

foldl (+) 0 [1..1000000]
foldl' (+) 0 [1..1000000]


Takže faktem je, že v obou případech je potřeba, aby to pole byl vlastně Stream. Protože Haskell umí použít Fusion a to pole nealokovat. Takže v případě Strict jazyka nastává otázka, jestli tyhle věci mají být všechny Stream, nebo naopak všechny pole.

A k foldl tu máme ještě foldr - problém je, že foldl má smysl jenom strict a foldr zase typicky lazy. A to nemá nic společného s jazykem, ale spíš s tím, jak ty funkce pojmenovat. Z hlediska konzistence to takhle dává hodně smysl, z hlediska začátečníka to je trochu problém.... (možná by to chtělo udělat foldl depracated, aby aspoň varoval).

Takže ve výsledku je v haskellu všechno lazy s tím, že těch pár příkladů, kde to dává smysl, to můžeš snadno anotovat jako strict (např. maybe prostě striktně smysl nedává) vs. strict jazyky, kde vlastně na první pohled netušíš, jestli je funkce strict nebo lazy, nebo to máš poseté variantami funkcí a la Maybe v purescriptu.

No ale co by to mělo dokazovat? Haskell je složitý, protože je lazy a ty lazy obraty by fungovaly i kdyby lazy nebyly?! No to dá rozum, na tom není nic zajímavého. Zajímavé je to, že ty obraty jsou složité, ABY mohly být lazy. Pokud jazyk lazy není, složité obraty nepotřebuje. To je odpověď na tu otázku "čemu vadí, že je lazy".

No mě teda Maybe v haskellu připadne zcela triviální. Maybe v purescriptu má 2x tolik funkcí, aby obsloužilo totéž.

Hlavně ale myslel jsem to opačně: strict kód funguje jako lazy bez problémů (minus sem tam problém se stack overflow a space leaky), lazy kód ve strict prostředí fungovat vůbec nemusí (a performance taky může být problém, jen jinde). Takže člověk, který s tím jazykem začíná, prostě to, že to je lazy vůbec řešit nemusí. Může psát strict kód a chová se to přesně tak, jak by čekal. S foldl stack overflow jsem se nepotkal, s lazy modifyIORef ano a člověk se aspoň něco naučí Ale fakt se tohle přehání...

[Kit]

Co jsou monády?
...
    Monády jsou individua. Neexistují dvě stejné monády. Každá monáda, od té nejjednodušší k nejsložitější, má své nezaměnitelné místo, každá zrcadlí univerzum svým vlastním, jedinečným způsobem a každá je potenciálně, co do možnosti, zrcadlem univerza. Monády jsou individua také v tom smyslu, že jsou navenek uzavřeny – nemají žádná „okna“ – neovlivňují se.

Dalo by se z toho velmi zjednodušeně dovodit, že monády tvoří uzly, zatímco funkce tvoří hrany?

[Radek Miček]

Ve Scale by se to řešilo tak, že uděláte typovou třídu pro typ Int a pro typ Int @@ Hex - v záznamu pak použiji typ Int @@ Hex pro pole, která jsou hexadecimálně. Jelikož Int @@ Hex je podtyp Int, jde s ním pracovat stejně jako s Intem.

No, jenže co když mám podstrukturu, kterou jednou chci deserializovat jako Hex, jednou jako decimal? Jde to @@Hex s hodnotou, nebo je to vázané na strukturu? Možná je to nějak vymyšlené, ale numím si to úplně představit.

Je to vázané na strukturu. V tomto případě tedy lze udělat dvě instance typové třídy pro daný typ a vždy si zajistit, aby v implicit scope byla ta správná.

[eee]

Je to akademický jazyk bez podpory imperativního programování, je to dobré na hraní si, ale v praxi je k ničemu.

[Reklama]

[čumil]

Je to akademický jazyk bez podpory imperativního programování, je to dobré na hraní si, ale v praxi je k ničemu.

Ty si taky v praxi k ničemu ... je to "pure" FP jazyk, co by tam mělo co dělat imperativní paradigma trotle? BTW ono tam skutečně je díky IO monádě, proto jsem to pure dal do uvozovek ... A tebe by taky chtělo dát do uvozovek

[Ivan Nový]

Je to akademický jazyk bez podpory imperativního programování, je to dobré na hraní si, ale v praxi je k ničemu.

Ty si taky v praxi k ničemu ... je to "pure" FP jazyk, co by tam mělo co dělat imperativní paradigma trotle? BTW ono tam skutečně je díky IO monádě, proto jsem to pure dal do uvozovek ... A tebe by taky chtělo dát do uvozovek

FP bude mít smysl, až někdo vymyslí rozumnou notaci, přijatelnou má zatím jen clojure, ale i tak je to trochu znásilňování univerzální lispovské formy.

Jinak je problém, že v hlavě máte tuším, že cca 7 paměťových registrů, což na impertivní paradigma stačí, na FP ne, protože v něm pracujete se soubory pravidel, které se vzájemně mohou ovlivňovat, takže odvodit si chování části reálného programu je nemožné, budou vám v hlavě chybět registry, nebudete mít možnost to porovnat najednou.

viz toto:

x := z + 1

kde kontext je schovaný v z, takže výraz je představitelný najednou, jen za z si dosazujete různé hodnoty, mozek výraz nemusí číst znovu, udržuje ho v pracovních registrech, proces dosazování řídí mozek, vytváří si vlastní asociace na základě předchozího čtení programu. Což je přirozený a z hlediska mozku optimalizovaný proces, odpovídající i běžnému vnímání.

oproti tomuto:

f =
     a > 100: x := 200
     a < 100: x := 100
     a = 80: x := 20

kde kontext je vyjádřen explicitně a výraz jako celek je nepředstavitelný, pokud s ním pracujete, musíte porovnávat několikrát jednotlivé řádky a v hlavě přesouvat informace do a z pracovních "registrů", kterých se vám nedostává (nejste schopen si představit jednu entitu na dvou místech zároveň), celý proces je navíc řízen textem programu, takže mozek ho musí číst a analyzovat opakovaně, což unavuje, protože nemůže využívat vlastních optimalizovaných asociací.

FP má budoucnost, ale až v době, kdy se stroje budou programovat samy.

Narazil jsem na zajímavou věc, kdy někdo považuje identifikátor x z výrazu int x := 1 za proměnnou a nikoliv za pojmenování místa v paměti počítače a x nechápe jako stav, kterým tudíž je, ale jako hodnotu.

[andy]

Jinak je problém, že v hlavě máte tuším, že cca 7 paměťových registrů, což na impertivní paradigma stačí, na FP ne, protože v něm pracujete se soubory pravidel, které se vzájemně mohou ovlivňovat, takže odvodit si chování části reálného programu je nemožné, budou vám v hlavě chybět registry, nebudete mít možnost to porovnat najednou.

Sakra u vás je taky problém poznat, že si děláte srandu 

[Ivan Nový]

Jinak je problém, že v hlavě máte tuším, že cca 7 paměťových registrů, což na impertivní paradigma stačí, na FP ne, protože v něm pracujete se soubory pravidel, které se vzájemně mohou ovlivňovat, takže odvodit si chování části reálného programu je nemožné, budou vám v hlavě chybět registry, nebudete mít možnost to porovnat najednou.

Sakra u vás je taky problém poznat, že si děláte srandu 

No on je to legrace jen napůl, viz wikipedie, krátkodobá paměť:

Krátkodobá paměť

Krátkodobá paměť, (nebo také paměť pracovní, operativní) je vědomá aktivní část paměti, ve které se odehrává většina psychických procesů (např. řešení aktuálních problémů). Zpracovávají se v ní informace dodané senzorickou pamětí a informace vyvolané z paměti dlouhodobé, která není dostupná vědomě. Krátkodobá paměť dokáže uchovat vjemy smyslových orgánů a emoce pomocí přeměny (kódování) v mentální reprezentace. Ty může paměť dále zpracovávat a uchovávat.

Krátkodobá paměť je omezena na 5–9 prvků (tzv. magické číslo 7±2), které při zamezení opakování uchová na 15–20 sekund. Kapacitu lze zvýšit spojováním prvků do logických celků (např. mnemotechnické pomůcky). Pro zachování informace v krátkodobé paměti je třeba si informaci opakovat (tzv. fonologická smyčka), jinak je paměťová stopa nenávratně ztracena.

Tříjednotkový model krátkodobé paměti udává 3 mechanismy zpracování:

    fonologická smyčka – dočasně ukládá zvukové a řečové informace
    vizuoprostorový náčrtník – dočasně ukládá vizuálně prostorové informace
    centrální výkonnostní smyčka – třídí a specifikuje krátkodobé informace

[andy]

No on je to legrace jen napůl, viz wikipedie, krátkodobá paměť:

Tak pochopil jsem, že si děláte srandu v tom zbytku Ale co ti chudáci, co s FP nikdy nepřišli do styku? Ti by tomu skoro mohli věřit...

[Ivan Nový]

No on je to legrace jen napůl, viz wikipedie, krátkodobá paměť:

Tak pochopil jsem, že si děláte srandu v tom zbytku Ale co ti chudáci, co s FP nikdy nepřišli do styku? Ti by tomu skoro mohli věřit...

Zde máte příklad z Haskellu: (bohužel na GitHubu jsem nenarazil na reálnou aplikaci, jen školometské příklady)

zipWith' :: (a -> b -> c) -> [a] -> -> [c]
zipWith' _ [] _ = []
zipWith' _ _ [] = []
zipWith' f (x:xs) (y:ys) = f x y : zipWith' f xs ys

Při jeho analýze setrváváte neustále ve fonologické smyčce. Detailněji viz zde https://cs.wikipedia.org/wiki/Baddeleyho_model_pracovn%C3%AD_pam%C4%9Bti

Imperativní program zvládnete analyzovat po řádku, jen s kontextem ze střednědobé paměti, který se vybavuje automaticky. Proto je taky imperativní paradigma oblíbenější.

[Ondra Satai Nekola]

Už tu zas Ivan s vážnou tváří tvrdí, že je snazší uvažovat o kódu se side effecty?

[Ivan Nový]

Už tu zas Ivan s vážnou tváří tvrdí, že je snazší uvažovat o kódu se side effecty?

Známé nebezpečí si dovedete pohlídat, takže side efektům se dá vyhnout, nebo s nimi počítat. Jinak side effecty máte i v FP, jen v trochu jíné formě, například zde:

f =
     a > 100: x := 200
     a < 100: x := 100
     a = 80: x := 20

Bude-li těch pravidel více, snadno přehlédnete, že první dvě pokrývají celý rozsah, ale třetí je výjimka z tohoto pravidla. Pokud to nebude v rámci jednoho příkazu, může dojít k vyhodnocení podmínek v různém pořadí a to povede na těžko odhalitelné chyby s podobným chováním jako side effect.

Jinak proti FP nic nemám, jen mi nevyhovuje jeho notace, s tím by se mělo něco udělat. Je na tom vidět, že jde o znásilňování principů z filosoficky odlišného imperativního paradigmatu.

A to, že lidský mozek nativně pracuje s kontextem a tudíž i se side effecty je fakt. Výhoda FP je právě v tom, že je to koncept, který je jiný, nekopíruje lidské myšlení, jde spíše proti němu, sází na formalizaci, která usnadňuje dokazování, ale znesnadňuje čtení a rychlé pochopení. Ono nikdy není nic zadarmo.

[Ondra Satai Nekola]

Ten kus kódu, co jsi pastnul, ti přijde jako funkcionální?

[Ivan Nový]

Ten kus kódu, co jsi pastnul, ti přijde jako funkcionální?

Je to z praxe v Haskellu. tak to bude vypadat, když se masově rozšíří. A pravidla jsou jen na tři řádky (tučně), v praxi budou třeba na 100 řádků (daňová pravidla)

funkcionálně můj předchozí příklad

list = map(lambda x: 200 if x > 100 else x, map(lambda x: 100 if x < 100 else x, list))

a někde v programu před předchozí sekvencí

list = map(lambda x: 200 if x = 80 else x, list)

a ve výsledku se budete divit, že vám někde mizí hodnoty 80, obdoba implicitního side effectu jako vyšitá.