Rychlost Haskell vs. C++

lopata

Re:Rychlost Haskell vs. C++
« Odpověď #270 kdy: 03. 09. 2018, 17:25:01 »
A napíšu to ještě jinak. Podle tebe je v korektní program Haskellu jen takový, kde máš vše dokonale ošetřeno typovým systémem. Musel bys tam mít typy pro datumy, integer čísla včetně nekonečna (výsledek dělení) apod... Jenomže to neplatí. Haskell umožňuje napsat korektní program i bez toho. Nemusíš mít vše řešeno definicí typů, i když je to tak třeba někdy lepší.

On je to totiž dost teoretický koncept. Chápu, jaké to dává záruky, ale taky to něco stojí. Vem si třeba to hloupé integer dělení, jako výsledek musíš definovat typ integer a k tomu plus mínus nekonečno. Teoreticky je to hezký koncept, ale prakticky to moc nikdo nechce, proto taky knihovní funkce div nic takového nemá.


andy

Re:Rychlost Haskell vs. C++
« Odpověď #271 kdy: 03. 09. 2018, 17:41:17 »
A napíšu to ještě jinak. Podle tebe je v korektní program Haskellu jen takový, kde máš vše dokonale ošetřeno typovým systémem
Korektní funkcionální program je takový, kde se požadované výrazy v průběhu běhu programu vyhodnotí na hodnotu (+splňuje požadavky zadání). Žádné "chování" neexistuje.
Korektní imperativní program je takový, který má definované chování. (+splňuje požadavky zadání) Žádné "hodnoty" neexistují.

Haskell je funkcionální jazyk....

Citace
Kdyby Haskell uměl zajistit, že argumenty funkcí budou jen v definičním oboru funkcí, třeba typovým systémem, možná bychom se mohli bavit o tom, co jsi napsal. Jenomže Haskell to zajistit NEUMÍ. To znamená, že nemáš žádné záruky
To je obecně vlastnost typových systémů, že zpravidla nejsou dostatečně dokonalé, aby nepropustily nekorektní program...už jsem to tady 3x opakoval...

Citace
Použil jsem knihovní funkci div, která ti žádné typové záruky nedává. Dělení nulou řeší jako výjimku. To je celé. Souhlasím, že design toho programu není dobrý. Ale to nebylo cílem. Cílem bylo ukázat, že program v Haskellu může záviset na strict vyhodnocení, což platí. Bez ohledu na nějaké hypotetické typové záruky, které v Haskellu nemáš.
No, zatím jsi ukázal, že při přechodu Lazy->Strict se může z vyhodnocování některých výrazů stát bottom, a že IO engine haskellu je schopen zachytit nekorektní stav vyhodnocování. Hmmm....

Jinak zpětně myslím, že ten příklad s přístupem na adresu 0 docela sedí. Prostě máš IO engine (>>=), který tak různě volá ty haskellové výrazy a provádí IO podle toho, na co se to vyhodnotí. No a tam se dá (přes catch) nastavit, že když to při tom vyhodnocování kixne, tak se něco zavolá. Podobná situace, jako když OS předává řízení programu, a když dojde k nějakému nekorektnímu stavu (přístup na adresu 0), tak je schopen zavolat signal handler SIGSEGV, který si před tím program nainstaloval.

Jinak díky, že jsi opět neodpověděl ani najeden dotaz, který jsem předtím položil. Prostě na to nemáš.

lopata

Re:Rychlost Haskell vs. C++
« Odpověď #272 kdy: 03. 09. 2018, 17:51:42 »
Podívej, tohle nemá cenu. Klidně si mysli, že korektní programy můžou být jen takové, kde je vše dokonale podchyceno typovým systémem. Pokud je tohle podle tebe definice korektního programu, tak prakticky žádné neexistují. Ale mně je to už celkem jedno. Odmítám diskutovat s akademikem, kterému něco řekli ve škole a on ty poučky naprosto chybně aplikuje v reálných případech.

Re:Rychlost Haskell vs. C++
« Odpověď #273 kdy: 03. 09. 2018, 17:59:58 »
Zatím jsi to ty, kdo tu aplikuje chybně prakticky všechno... :) Jinak gratuluji k 19. stránce.

lopata

Re:Rychlost Haskell vs. C++
« Odpověď #274 kdy: 03. 09. 2018, 18:03:10 »
Zatím jsi to ty, kdo tu aplikuje chybně prakticky všechno... :) Jinak gratuluji k 19. stránce.
Už ti došlo, jaký je rozdíl mezi undefined behavior a chytání výjimky?


andy

Re:Rychlost Haskell vs. C++
« Odpověď #275 kdy: 03. 09. 2018, 18:46:40 »
Podívej, tohle nemá cenu. Klidně si mysli, že korektní programy můžou být jen takové, kde je vše dokonale podchyceno typovým systémem.
Zvláštní, asi 4x už jsem tu napsal, že si tohle nemyslím...
Citace
Pokud je tohle podle tebe definice korektního programu, tak prakticky žádné neexistují.
Není.... napsal jsem ti, co považuji za korektní program a tohle to fakt není :) Tak co si ještě podle tebe myslím? Zabili Kennyho?

Citace
Ale mně je to už celkem jedno. Odmítám diskutovat s akademikem, kterému něco řekli ve škole a on ty poučky naprosto chybně aplikuje v reálných případech.
Ale ty nediskutuješ :) Položil jsem ti pár jednoduchých otázek a ty ses absolutně nenamáhal odpovědět.... S židlí se diskutovat nedá, židle jen trvá na svém... a pro takové fakt haskell není...

andy

Re:Rychlost Haskell vs. C++
« Odpověď #276 kdy: 03. 09. 2018, 18:51:24 »
Zatím jsi to ty, kdo tu aplikuje chybně prakticky všechno... :) Jinak gratuluji k 19. stránce.
Už ti došlo, jaký je rozdíl mezi undefined behavior a chytání výjimky?
No, a už jsi pochopil, že haskellový program nemá žádné "behaviour"? Protože je jako jeden z hodně mála jazyků opravdu čisté funkcionální?

lopata

Re:Rychlost Haskell vs. C++
« Odpověď #277 kdy: 03. 09. 2018, 21:22:10 »
Zatím jsi to ty, kdo tu aplikuje chybně prakticky všechno... :) Jinak gratuluji k 19. stránce.
Už ti došlo, jaký je rozdíl mezi undefined behavior a chytání výjimky?
No, a už jsi pochopil, že haskellový program nemá žádné "behaviour"? Protože je jako jeden z hodně mála jazyků opravdu čisté funkcionální?

Víš, tvůj probém je, že máš naučené teoretické poučky, které ale úplně špatně aplikuješ v praxi. Haskellovský program samozřejmě má "behavior", kdyby neměl, nikdo by nechtěl Haskellovské programy používat. Od programu se tak nějak z principu očekává, že bude něco dělat. Takové polopravdy a nesmysly uvádíš pořád.

I v Haskellu narazíš na undefined behavior: http://hackage.haskell.org/package/base-4.11.1.0/docs/Foreign-StablePtr.html
If the argument to deRefStablePtr has already been freed using freeStablePtr, the behaviour of deRefStablePtr is undefined.

Proto diskuze s tebou nemá smysl, žiješ svázaný teoriemi bez vazby na praxi.

andy

Re:Rychlost Haskell vs. C++
« Odpověď #278 kdy: 03. 09. 2018, 21:46:08 »
Víš, tvůj probém je, že máš naučené teoretické poučky, které ale úplně špatně aplikuješ v praxi. Haskellovský program samozřejmě má "behavior", kdyby neměl, nikdo by nechtěl Haskellovské programy používat. Od programu se tak nějak z principu očekává, že bude něco dělat. Takové polopravdy a nesmysly uvádíš pořád.
No vidíš, a od Haskellových programů se to neočekává. Víš jaký je výsledek vyhodnocení funkce main? IO (). To nic nedělá, to je prostě hodnota.

Když bychom haskellové programy omezili, že by nereagovaly na vstup, tak bychom nepotřebovali Monad, stačil by List. Takže by Haskellový program mohl vypadat třeba takhle:
Kód: [Vybrat]
data IO = UmazVejce Int | DejObsahPanveNaTalir | PostavTalirNaStul | NedelejNic
main :: [IO]
main = [ UsmazVejce (2 + 3), DejObsahPanveNaTalir, PostavTalirNaStul ]
Vidíš nějaké chování? Já ne, tohle je prostě seznam toho, co se má udělat. Ta monadická struktura je v podstatě totéž, akorát umožňuje zapsat reakce na vstupy.

Citace
I v Haskellu narazíš na undefined behavior: http://hackage.haskell.org/package/base-4.11.1.0/docs/Foreign-StablePtr.html
If the argument to deRefStablePtr has already been freed using freeStablePtr, the behaviour of deRefStablePtr is undefined.
Jojo, to je behaviour IO akce, nikoliv haskellového programu...

Citace
Proto diskuze s tebou nemá smysl, žiješ svázaný teoriemi bez vazby na praxi.
Jojo, mě se vždycky líbí, jak ti, kteří odmítnout odpovědět na jednoduché otázky, a začnou volat něco ve stylu "demagogie" a "akademický teoretik", "svázený teoriemi" a podobně. Přitom je strašně jednoduché ukázat, že jsem demagog nebo akademický teoretik: odpovědět. Ale to židle nezvládne. Židle trvá na svém. Mimochodem, já si udělám sbírku těchhle fází, znáš ještě nějaké? Ale ztrapňuješ se sám. Stačí odpovědět.

lopata

Re:Rychlost Haskell vs. C++
« Odpověď #279 kdy: 03. 09. 2018, 22:01:28 »
Aha, takže IO akce v Haskelovském programu není součástí Haskellovského programu... Co tam máš dál za perly, jaké další nesmyslné definice mimo realitu jsi ještě schopen vymyslet?

andy

Re:Rychlost Haskell vs. C++
« Odpověď #280 kdy: 03. 09. 2018, 23:03:59 »
Aha, takže IO akce v Haskelovském programu není součástí Haskellovského programu... Co tam máš dál za perly, jaké další nesmyslné definice mimo realitu jsi ještě schopen vymyslet?
Konkrétní chování IO akce není součástí Haskell jazyka. Je to součástí nějakých knihoven. Haskellový program (ve smyslu toho, co je napsáno ve zdrojáku, nikoliv výsledné binárky) vyprodukuje, co se asi tak má s těmi voláními provést - a to se pak provede.  Nebo snad někde v tom svém zdrojáku vidíš nějaké příkazy? Já tam vidím akorát monadické řetězení - což je jenom trošičku složitější stavění Listu.

U main funkce máš přímo napsaný typ: IO (). To je hodnota. Zkus to, jaké má "hodnota" chování? Třeba ten zdroják, kde bychom to zjednodušili:
Kód: [Vybrat]
main = take 1 [ UdelejPalacinku, UdelejPalacinku, UdelejPalacinku ]Jaké bude mít ten program chování? Žádné? Teprve když to něco začne vykonávat, tak se podívá do knihovny, najde co má udělat "UdelejPalacinku" a to provede? A k tomu undefined - tohle:
Kód: [Vybrat]
main = [UdelejPalacinku] ++ [**tohle je necitelne**..undefined] ++[PostavTalirNaStul]Když dostaneš takovýhle seznam úkolů, tak ho sice deterministicky můžeš vykonat (nečitelné věci prostě neuděláš), ale ten seznam prostě není korektní, protože tam nečitelné věci nemají co dělat. Už jen proto, že třeba nelze odpovědět na otázku "a bylo vše na seznamu vykonáno".

Je to trošičku jiné paradigma... Trošičku je to v tom stylu, jako bys měl generátor programů, které se teprve následně spouští. Ten generátor sám o sobě nic udělat neumí. Je zcela pure.

lopata

Re:Rychlost Haskell vs. C++
« Odpověď #281 kdy: 03. 09. 2018, 23:38:56 »
Ale tohle všichni vědí, to je přece jasné. Pointa je, že to uživatele vůbec nezajímá. On chce, aby program něco dělal, pro něj musí mít chování. Takže sice můžeš říct, že "polovina Haskell programu" jenom vyprodukuje, co se má udělat, ale reálně k tomu potřebuješ i tu "druhou polovinu", která to opravdu vykoná. Ty uvažuješ jenom o té první půlce, jenomže ta ti je bez té druhé úplně k ničemu. Taková hezká akademická úvaha, co se nám nehodí, to odsuneme jinam a nebudeme se tím zabývat. Reálně to v tom programu ale je. Musí být. Bez toho by nefungoval.

Úplně stejná analogie je s undefined behavior ve StablePtr. Uživatele vůbec nezajímá, že je to IO monáda a že to podle tebe nepatří do Haskell programu. Uživatele ale sakra bude zajímat, když to použiješ blbě a program mu spadne. Můžeš mu zkusit vysvětlit, že vlastně nespadl Haskell program, ale něco úplně jiného, co ty už neřešíš. Obávám se ale, že tě požene svinským krokem.

andy

Re:Rychlost Haskell vs. C++
« Odpověď #282 kdy: 04. 09. 2018, 00:37:41 »
Ale tohle všichni vědí, to je přece jasné. Pointa je, že to uživatele vůbec nezajímá. On chce, aby program něco dělal, pro něj musí mít chování. Takže sice můžeš říct, že "polovina Haskell programu" jenom vyprodukuje, co se má udělat, ale reálně k tomu potřebuješ i tu "druhou polovinu", která to opravdu vykoná. Ty uvažuješ jenom o té první půlce, jenomže ta ti je bez té druhé úplně k ničemu. Taková hezká akademická úvaha, co se nám nehodí, to odsuneme jinam a nebudeme se tím zabývat. Reálně to v tom programu ale je. Musí být. Bez toho by nefungoval.
Ta druhá půlka není tvůj haskellový program. A ta druhá půlka očekává, že vyhodnocení tvého haskellového programu té druhé půlce dá poměrně jasnou specifikaci, co má ta druhá půlka dělat. A specifikace "undefined" je jaksi poněkud nekorektní.

Citace
Úplně stejná analogie je s undefined behavior ve StablePtr. Uživatele vůbec nezajímá, že je to IO monáda a že to podle tebe nepatří do Haskell programu. Uživatele ale sakra bude zajímat, když to použiješ blbě a program mu spadne. Můžeš mu zkusit vysvětlit, že vlastně nespadl Haskell program, ale něco úplně jiného, co ty už neřešíš. Obávám se ale, že tě požene svinským krokem.
Ale to jsme se přesně dostali do té imperativní části, která je ta jediná, kterou znáš. Jenomže ta pointa je, že ten tvůj program může být nekorektní i navzdory tomu, že z té "druhé poloviny" používáš jenom IO akce s definovaným chováním.

Ten tvůj program vygeneruje specifikaci, kterou pak nějaký "IO interpret" vykonává. Ty klidně můžeš vyměnit "IO" za nějaký tvůj vlastní Monad, vytvořit si nějakou simulaci IO a výsledek si odsimulovat. To se mimochodem používá v unit testech. Jenomže v tvém programu nemůžeš - protože ta specifikace není korektní. IO monad je schopen zachytit "null pointer exception". Jiný interpret monadické struktury toho schopen není. Takže kdybych tvůj kód transformoval do pure unit testu (v podstatě jenom výměnou IO za nějakou typeclassu), tak prostě v XStrict slítne a není vůbec žádná šance to  uchodit.

Ono se dá říct, že ten tvůj program je "implementation dependent". Protože IO je svým způsobem jenom knihovna a to, že je schopna tohle odchytit je na úrovni toho, že zrovna IO umí odchytit SIGSEGV. Magic. Občas se hodí mít možnost SIGSEGV chytit. Ale program, který to háže fakt není korektní.

lopata

Re:Rychlost Haskell vs. C++
« Odpověď #283 kdy: 04. 09. 2018, 01:00:10 »
Zase píšeš úplné nesmysly. Ten program není implementation dependent. Je naprosto jasné, kde a jak a kde se ta výjimka dá chytit. Všechno máš specifikované tady: http://hackage.haskell.org/package/base-4.11.1.0/docs/Control-Exception.html
Už mě to s tebou fakt nebaví. Máš nějakou specifikaci chování výjimek v Haskellu, ale ty ji vůbec neznáš. Proč si to nejdřív nepřečteš, než začneš generovat nějaká rádoby moudra?

andy

Re:Rychlost Haskell vs. C++
« Odpověď #284 kdy: 04. 09. 2018, 01:19:52 »
Zase píšeš úplné nesmysly. Ten program není implementation dependent. Je naprosto jasné, kde a jak a kde se ta výjimka dá chytit. Všechno máš specifikované tady: http://hackage.haskell.org/package/base-4.11.1.0/docs/Control-Exception.html
Už mě to s tebou fakt nebaví. Máš nějakou specifikaci chování výjimek v Haskellu, ale ty ji vůbec neznáš. Proč si to nejdřív nepřečteš, než začneš generovat nějaká rádoby moudra?
Jasně, a teď prosím ukaž, jak budeš chytat undefined v non-IO monadu. Exceptiony normálně chytat jdou a je to pure:

Viz např: http://hackage.haskell.org/package/exceptions-0.10.0/docs/Control-Monad-Catch.html.

Jsem jedno velké ucho...