Má Haskell budoucnost?

Re:Má Haskell budoucnost?
« Odpověď #195 kdy: 15. 05. 2016, 22:19:15 »
Ze i v ciste pure svete ma teoreticke i prakticke (to jsou ty, kvuli kterym se nepouziva jenom lepsi lazy) dusledky (ne)striktnost
O tom přece není sporu. Ujasnili jsme si, že to má vliv na možnost zacyklení se na něčem, na čem by se výpočet zacyklit neměl. Ještě na něco jiného?

Minimalne jeste na runtime chyby (trebas nepovedeny pattern match). Mozna jeste neco, co ted nevidim.

(Z tech praktickych veci pak samozrejme vliv na spotrebu pameti a rychlost)


Re:Má Haskell budoucnost?
« Odpověď #196 kdy: 15. 05. 2016, 22:20:28 »
Minimalne jeste na runtime chyby (trebas nepovedeny pattern match). Mozna jeste neco, co ted nevidim.

(Z tech praktickych veci pak samozrejme vliv na spotrebu pameti a rychlost)
A co?

Můžu ten příklad klíďopíďo přepsat takhle:
Kód: [Vybrat]
let
 x = f (print "a")
in
 g (print "b") x
- v tomhle případě taky není pořadí definováno?
Presne tak.
Takže hodnota x před vyhodnocením g je teda jaká? Žádná, protože f zatím nebylo potřeba vyhodnotit? A tomu pořád říkáme "strict"?

andy

Re:Má Haskell budoucnost?
« Odpověď #197 kdy: 15. 05. 2016, 23:04:17 »
Tobě "do" syntaxe připadá složitá? Jediný, co potřebuješ pochopit, je rozdíl mezi pure a non-pure funkcí.
Žádné non-pure fce ale neexistují :)
No jasně, tak rozdíl mezi pure funkcí a IO akcí. Ale opakuju otázku - co je na IO monádu složitého? Ten monád je doslova (jak jsi psal) to, že pouští jeden "příkaz" za druhým. Žádné výhybky tam nejsou, žádné nedeterministické větvení, nic. Co na tom je složitého? Je to středník, který je naprogramovaný jako středník, takže "do" se chová tak, jak by člověk ve většině programovacích jazyků čekal ("return" na první pohled nevypadá jako šťastná volba, ale po několika kapitolách pure programování mě teda ani nenapadlo, že by to snad tu funkci mělo ukončit - to jsem fakt spíš bojoval s tím, kdy použít "let" a kdy "<-").

Taky se v tom začínám ztrácet, ale tak nějak ty tady v zásadě pořád říkáš, že laziness v zásadě způsobuje složitost haskellu a následně se takové věci jako řazení IO musí řešit přes monády. Já bych asi i souhlasil s tím, že to byl historický vývoj, ale dostali jsme se někam, kde se ukazuje, že to sice na začátku jako opičárna vypadala, ale vlastně to byl docela dobrý nápad.

- v pure výpočtech je laziness celkem putna, mnohdy je spíš lepší
- haskell je v zásadě celý pure včetně IO
- podle tebe je celé IO opičárna, ale mě nějak vůbec není jasné, co by mělo být lepší. Přestat si v IO hrát na pure programování, a pak když se rozhodneš, že místo IO použiješ nějaký Free, nebo to obalíš RWS, tak ten refaktoring bude znamenat přepisování do nějaké jiné syntaxe? Nebo že ti překladač bude automaticky detekovat, jestli je funkce v IO nebo ne a v nějaké syntaxi typu "f(print "a", print "b")" to bude nějak automaticky vyhodnocovat... a pak začneš řešit "ale co když to vyhodnotit nechci" a "v jakém pořadí se to má vyhodnotit".... není to trochu komplikace?

Re:Má Haskell budoucnost?
« Odpověď #198 kdy: 16. 05. 2016, 00:14:17 »
Ale opakuju otázku - co je na IO monádu složitého?
To se musíš ptát lidí, kteří mají problém to pochopit :)

kde se ukazuje, že to sice na začátku jako opičárna vypadala, ale vlastně to byl docela dobrý nápad.
Nemyslím si, že je opičárna ta volba pure-lazy. To je legitimní designové rozhodnutí, které ti lidi dělali určitě s dobrým vědomím a svědomím. Akorát to má prostě svoje důsledky, no. A jedním z těch důsledků je, že je ten jazyk pak těžko srozumitelný/použitelný pro BFP (běžný Franta programátor ;) ) To je celý, nic víc v těch mých příspěvcích nehledej :)

- podle tebe je celé IO opičárna, ale mě nějak vůbec není jasné, co by mělo být lepší.
Nic. Pokud máš pure jazyk, tak asi nic lepšího než IO monádu nevymyslíš. Ještě by možná stálo za řeč FRP - jakože by program jenom transformoval vstupy na výstupy. Ale to se hodí jenom na něco.

zboj

  • *****
  • 1 507
    • Zobrazit profil
    • E-mail
Re:Má Haskell budoucnost?
« Odpověď #199 kdy: 16. 05. 2016, 00:15:44 »
Tobě "do" syntaxe připadá složitá? Jediný, co potřebuješ pochopit, je rozdíl mezi pure a non-pure funkcí.
Žádné non-pure fce ale neexistují :)
No jasně, tak rozdíl mezi pure funkcí a IO akcí. Ale opakuju otázku - co je na IO monádu složitého? Ten monád je doslova (jak jsi psal) to, že pouští jeden "příkaz" za druhým. Žádné výhybky tam nejsou, žádné nedeterministické větvení, nic. Co na tom je složitého? Je to středník, který je naprogramovaný jako středník, takže "do" se chová tak, jak by člověk ve většině programovacích jazyků čekal ("return" na první pohled nevypadá jako šťastná volba, ale po několika kapitolách pure programování mě teda ani nenapadlo, že by to snad tu funkci mělo ukončit - to jsem fakt spíš bojoval s tím, kdy použít "let" a kdy "<-").

Taky se v tom začínám ztrácet, ale tak nějak ty tady v zásadě pořád říkáš, že laziness v zásadě způsobuje složitost haskellu a následně se takové věci jako řazení IO musí řešit přes monády. Já bych asi i souhlasil s tím, že to byl historický vývoj, ale dostali jsme se někam, kde se ukazuje, že to sice na začátku jako opičárna vypadala, ale vlastně to byl docela dobrý nápad.

- v pure výpočtech je laziness celkem putna, mnohdy je spíš lepší
- haskell je v zásadě celý pure včetně IO
- podle tebe je celé IO opičárna, ale mě nějak vůbec není jasné, co by mělo být lepší. Přestat si v IO hrát na pure programování, a pak když se rozhodneš, že místo IO použiješ nějaký Free, nebo to obalíš RWS, tak ten refaktoring bude znamenat přepisování do nějaké jiné syntaxe? Nebo že ti překladač bude automaticky detekovat, jestli je funkce v IO nebo ne a v nějaké syntaxi typu "f(print "a", print "b")" to bude nějak automaticky vyhodnocovat... a pak začneš řešit "ale co když to vyhodnotit nechci" a "v jakém pořadí se to má vyhodnotit".... není to trochu komplikace?

Co takhle psát česky? Je to TA monáda, ne ten monád...


zboj

  • *****
  • 1 507
    • Zobrazit profil
    • E-mail
Re:Má Haskell budoucnost?
« Odpověď #200 kdy: 16. 05. 2016, 00:40:46 »
strict: před vyhodnocením funkce jsou vyhodnoceny její argumenty
V tom případě by IO monádu nepotřeboval, protože řazení IO by pak šlo triviálně udělat takhle:
Kód: [Vybrat]
f(print "b",g(print "a"))
- dle té definice by pořadí výpisu nutně bylo a,b. Funkce f a g můžou dělat cokoli, může to být klidně identita.
Jak už zmínili jiní, tohle správné (pevné) pořadí nezajistí, nicméně funkcionální by bylo něco jako

print("a")("b")("c")

což ovšem nebude fungovat s každým typovým systémem.

Re:Má Haskell budoucnost?
« Odpověď #201 kdy: 16. 05. 2016, 00:50:42 »
print("a")("b")("c")
Jasně, napsal jsem to blbě, měl jsem namysli tohle:
Kód: [Vybrat]
print(c,print(b,print(a)))
což je skoro stejnej princip jako to, co píšeš.

Tak jako tak to ale byla zcestná argumentace, protože když se teda bavíme o plně čistém jazyce, tak vynucení pořadí vyhodnocování stejně k ničemu nevede (co se týče IO).

eee

Re:Má Haskell budoucnost?
« Odpověď #202 kdy: 16. 05. 2016, 09:12:11 »
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
Naopak, ja jsem v praxi uzitecny, treba prave proto, ze nepouzivam haskell :-).

Napsal jsem, ze haskell je bez podpory imperativniho programovani, chces to snad rozporovat, trotle? Nebo s cim mas problem? Tenhle jazyk je akademicky a proto neprakticky, to je cele. Prakticke jazyky se snazi byt uzitecne, jsou pragmaticke a to jim brani byt akademicky ciste.

Na polozeny dotaz ohledne budoucnosti haskellu je tak jednoducha odpoved.

andy

Re:Má Haskell budoucnost?
« Odpověď #203 kdy: 16. 05. 2016, 09:55:04 »
Napsal jsem, ze haskell je bez podpory imperativniho programovani, chces to snad rozporovat, trotle? Nebo s cim mas problem? Tenhle jazyk je akademicky a proto neprakticky, to je cele. Prakticke jazyky se snazi byt uzitecne, jsou pragmaticke a to jim brani byt akademicky ciste.
Co to znamená "bez podpory imperativního programování"? Fakt nevím, co je na "do" bloku neimperativního - tak "teoreticky" to je celé pure záležitost - ale v praxi to je normální imperativní procedura. Nikdo ti nebrání zapnout si Strict (měl jsem dojem, že to je už v 7.10.3, ale asi je to až ve verzi 8) a všechno dělat v IO přes "return". A jsi přesně tam, kde jsi u ostatních jazyků.

Ale ohledně praktičnosti - s výjimkou sem tam nějakého algoritmu, který závisí na mutability, bych řekl, že v haskellu v porovnání s "běžnými imperativními jazyky" - C, C++, C#, Java, Python - dokážu napsat totéž výrazně čistěji, se srovnatelnou výkonností a s méně chybami (there are obviously no errors vs. there are no obvious errors), a v případě refaktoringu to bude u haskellového kódu výrazně "neprůstřelnější".

gamer

Re:Má Haskell budoucnost?
« Odpověď #204 kdy: 16. 05. 2016, 10:12:56 »
Ale ohledně praktičnosti - s výjimkou sem tam nějakého algoritmu, který závisí na mutability, bych řekl, že v haskellu v porovnání s "běžnými imperativními jazyky" - C, C++, C#, Java, Python - dokážu napsat totéž výrazně čistěji, se srovnatelnou výkonností a s méně chybami (there are obviously no errors vs. there are no obvious errors), a v případě refaktoringu to bude u haskellového kódu výrazně "neprůstřelnější".

Tak tohle je výzva :). Já si kdysi zkoušel v Haskellu napsat  https://en.wikipedia.org/wiki/Collatz_conjecture, to je taková hezká matematická hříčka, která by se měla pro Haskell hodit, ale Haskell to oproti C(++) prohrál na celé čáře. Buď to bylo v Haskellu čitelné, ale oproti C(++) řádově pomalejší, nebo to bylo pomalejší jen asi 2x, ale naprosto nečitelné. Dokážeš to v Haskellu napsat srovnatelně rychlé a čitelné?

Re:Má Haskell budoucnost?
« Odpověď #205 kdy: 16. 05. 2016, 10:31:05 »
Buď to bylo v Haskellu čitelné, ale oproti C(++) řádově pomalejší, nebo to bylo pomalejší jen asi 2x, ale naprosto nečitelné.
To není nic divnýho, u algoritmicky jednoduchých problémů, kde máš vytuněné řešení v C, bude každý vysokoúrovňový jazyk vždycky pomalejší. Protože prostě C má blíž k hardware, takže na těhle problémech moc není jak ho porazit.

Problémy ze skutečného světa ale nebývají algoritmicky jednoduché a na reálný výkon mají vliv jiné věci než hrubá rychlost výpočtu.

I v těchto umělých příkladech má ale Haskell výkonově blízko k Javě, což mi přijde dost dobrej výsledek na to, jak daleko je ten jazyk od hardware (sémanticky) - viz http://benchmarksgame.alioth.debian.org/u64q/haskell.html

andy

Re:Má Haskell budoucnost?
« Odpověď #206 kdy: 16. 05. 2016, 10:46:58 »
Ale ohledně praktičnosti - s výjimkou sem tam nějakého algoritmu, který závisí na mutability, bych řekl, že v haskellu v porovnání s "běžnými imperativními jazyky" - C, C++, C#, Java, Python - dokážu napsat totéž výrazně čistěji, se srovnatelnou výkonností a s méně chybami (there are obviously no errors vs. there are no obvious errors), a v případě refaktoringu to bude u haskellového kódu výrazně "neprůstřelnější".

Tak tohle je výzva :). Já si kdysi zkoušel v Haskellu napsat  https://en.wikipedia.org/wiki/Collatz_conjecture, to je taková hezká matematická hříčka, která by se měla pro Haskell hodit, ale Haskell to oproti C(++) prohrál na celé čáře. Buď to bylo v Haskellu čitelné, ale oproti C(++) řádově pomalejší, nebo to bylo pomalejší jen asi 2x, ale naprosto nečitelné. Dokážeš to v Haskellu napsat srovnatelně rychlé a čitelné?
Ach jo. Bavím se tady o PRAKTIČNOSTI haskellu, explicitně řeknu, že to opravdu na některé algoritmy, které vyžadují mutabilitu nefunguje a ty přijdeš s nějakým výpočtem, který se ti v C++ patrně vejde do cache a v haskellu třeba ne. Ano, jednoduché výpočetní algoritmy v těchhle jazycích fakt budou vypadat líp, počínaje quicksortem. Haskell má obrovské možnosti abstrakce, problém na 2 řádky opravdu není něco, na čem bys ten aparát haskellu mohl jakkoliv využít. Tohle je problém, který by byl přehledný i v assembleru.

Ale jen tak ze srandy bych si to zkusil, je zadání v long long nebo v arbitrary integer?

gamer

Re:Má Haskell budoucnost?
« Odpověď #207 kdy: 16. 05. 2016, 10:50:27 »
To není nic divnýho, u algoritmicky jednoduchých problémů, kde máš vytuněné řešení v C, bude každý vysokoúrovňový jazyk vždycky pomalejší. Protože prostě C má blíž k hardware, takže na těhle problémech moc není jak ho porazit.
Na tom není celkem co tunit, ten algoritmus je asi na 3 řádky. Ano je to algoritmicky jednoduché, ale když Haskell nedrží krok ani v jednoduchých čistě matematických nemutable algoritmech, proč bych měl věřit tomu, že to bude v něčem vysokoúrovňovém lepší? Jednoduché algoritmy jsou pomalé, ale složité budou rychlé? Nemyslím si to.

Re:Má Haskell budoucnost?
« Odpověď #208 kdy: 16. 05. 2016, 10:54:11 »
Na tom není celkem co tunit, ten algoritmus je asi na 3 řádky.
No tím "vytuněný" jsem myslel, že ten C kód se přeloží do nějakého optimálního strojáku. Tak je asi zřejmé, že nějaký "optimálnější než optimální" stroják asi těžko můžeš z jakéhokoliv jazyka dostat.

Ano je to algoritmicky jednoduché, ale když Haskell nedrží krok ani v jednoduchých čistě matematických nemutable algoritmech, proč bych měl věřit tomu, že to bude v něčem vysokoúrovňovém lepší? Jednoduché algoritmy jsou pomalé, ale složité budou rychlé? Nemyslím si to.
Nikdo tě nenutí si to myslet. Když tě Haskell neoslovuje a nevěříš mu, tak ho nepoužívej, co na tom chceš řešit? :)

gamer

Re:Má Haskell budoucnost?
« Odpověď #209 kdy: 16. 05. 2016, 10:55:19 »
Ach jo. Bavím se tady o PRAKTIČNOSTI haskellu, explicitně řeknu, že to opravdu na některé algoritmy, které vyžadují mutabilitu nefunguje a ty přijdeš s nějakým výpočtem, který se ti v C++ patrně vejde do cache a v haskellu třeba ne.
Collatz conjecture mutabilitu nepotřebuje. Do cache se to vejde v pohodě, pokud v Haskellu ne, je to problém Haskellu.

Ano, jednoduché výpočetní algoritmy v těchhle jazycích fakt budou vypadat líp, počínaje quicksortem.
V Haskellu se to taky dá napsat hezky a přehledně, jenom je to potom hrozně pomalé...

Haskell má obrovské možnosti abstrakce, problém na 2 řádky opravdu není něco, na čem bys ten aparát haskellu mohl jakkoliv využít. Tohle je problém, který by byl přehledný i v assembleru.
To je divný argument, Haskell má obrovské možnosti, a proto se na jednoduché věci nehodí? C++ má taky obrovské možnosti a hodí se i na jednoduché věci.

Ale jen tak ze srandy bych si to zkusil, je zadání v long long nebo v arbitrary integer?
To je celkem jedno, ale Int64 bude lepší.