Má Haskell budoucnost?

Kit

Re:Má Haskell budoucnost?
« Odpověď #15 kdy: 14. 05. 2016, 13:36:40 »
Mně se na použití Haskellu nelíbí hlavně ty příšerně dlouhé názvy funkcí, které mnozí programátoři používají. Proč, když máme propracovaný systém namespaces?
??? Tomu nerozumím, to je problém Javy, ne Haskellu :) Kde jsi narazil na dlouhá jména funkcí?

Například zde: https://github.com/Ohlasy/web/blob/gh-pages/_bin/top-articles.hs. Ty názvy funkcí mi připadají jako utřiNosoČistoPlenou nebo zahrajNaKlapkoBřinkoStroj. Je však docela možné, že jsem prostě náhodou narazil na nevhodný zdroják.


Kit

Re:Má Haskell budoucnost?
« Odpověď #16 kdy: 14. 05. 2016, 13:38:34 »
Mně se na použití Haskellu nelíbí hlavně ty příšerně dlouhé názvy funkcí, které mnozí programátoři používají. Proč, když máme propracovaný systém namespaces?
??? Tomu nerozumím, to je problém Javy, ne Haskellu :) Kde jsi narazil na dlouhá jména funkcí?
Dlouhá jména funkcí nemusí být nevýhodou, v kombinaci s vhodně zvolenou konvencí nahrazují dokumentaci.

Dlouhá jména funkcí se blbě čtou, dokumentaci nenahradí a často se taková funkce ani nevejde na jeden řádek a musí se zalamovat.

v

Re:Má Haskell budoucnost?
« Odpověď #17 kdy: 14. 05. 2016, 13:39:02 »
A proč máte interpret jako typeclass?
dobrá otázka, psaní toho kódu už na mě bylo intelektuálně trochu moc (jsem přece jenom prostý programátor C/C++), takže moje odpověď je poněkud mlhavá - má to něco společného se skládáním více "jazyků", motivovaným korektností použití příkazů pro ukončení iterace (tj. break a continue může být jenom v cyklu, jinak to ghc nepustí)

Re:Má Haskell budoucnost?
« Odpověď #18 kdy: 14. 05. 2016, 13:42:31 »
Tohle je častý názor, a vůbec ho nechápu. Stačí se podívat třeba na to, jak to má purescript, který je naopak strict: https://pursuit.purescript.org/packages/purescript-maybe/0.3.5/docs/Data.Maybe. To má být jako lepší?
Tomuhle moc nerozumím - co jsi tím chtěl říct? Jak souvisí Maybe s lazy/strict eval? A jak se liší tenhle Maybe od toho haskellovského?

Radek Miček

Re:Má Haskell budoucnost?
« Odpověď #19 kdy: 14. 05. 2016, 14:07:50 »
Tohle je častý názor, a vůbec ho nechápu. Stačí se podívat třeba na to, jak to má purescript, který je naopak strict: https://pursuit.purescript.org/packages/purescript-maybe/0.3.5/docs/Data.Maybe. To má být jako lepší?

Přijde mi lepší explicitně říci, že se něco konkrétního nemá vyhodnocovat striktně, než naopak - osobně chci častěji vyhodnocovat hned než nevyhodnocovat. Pokud jde o to, že při každém volání fromMaybe' musím argument obalit funkcí, tak to jde vyřešit tím, že to udělá kompilátor na základě typu (například když typ parametru bude Lazy Int, tak to kompilátor zabalí automaticky - tj. argument se nebude vyhodnocovat).

Citace
Ano, problematika space-leaku v haskellu je, ale po prvotních "úspěších" se mi to ve standardním kódu stává extrémně zřídka (na druhou stranu, když se mi to stane, tak to stojí za to a hraničí to s chybou překladače).

Osobně mi přijde, že je takové chyby velmi těžké odhalit viz třeba Sometimes, the old ways are the best. Na druhou stranu v Haskellu už dlouhou dobu neprogramuji.

Citace
Když jsem s haskellem začínal, tak jsem si to myslel taky. Ale za posledních několik projektů si neuvědomuju, že bych vůbec uvažoval o tom něco takhle použít. Máte nějaký praktický příklad, kde to vadí?

Třeba u typové třídy Ord by mi to přišlo docela užitečné. Nebo třeba u monoidu se to musí obcházet pomocí newtype Sum a newtype Product. A nakonec se může stát, že dvě různé knihovny obsahují různé instance pro jeden typ, a pokud se nepletu, tak GHC program neslinkuje?

Citace
Připadá mi, že je to v současné době snad jediný jazyk, který má zároveň velmi silný typový systém a používá se poměrně hodně v praxi - tzn. nikoliv specializované projekty, ale naprosto normální "business".

Takových jazyků příliš není, to je pravda. Dalo by se říci, že do téhle oblasti zasahuje ještě OCaml a Scala (resp. Dotty).


javaman

Re:Má Haskell budoucnost?
« Odpověď #20 kdy: 14. 05. 2016, 14:16:58 »
Mně se na použití Haskellu nelíbí hlavně ty příšerně dlouhé názvy funkcí, které mnozí programátoři používají. Proč, když máme propracovaný systém namespaces?
??? Tomu nerozumím, to je problém Javy, ne Haskellu :) Kde jsi narazil na dlouhá jména funkcí?
Dlouhá jména funkcí nemusí být nevýhodou, v kombinaci s vhodně zvolenou konvencí nahrazují dokumentaci.

Přesně tak, Java ví, jak se správně píše.

Re:Má Haskell budoucnost?
« Odpověď #21 kdy: 14. 05. 2016, 14:17:03 »
Citace z vlákna o pythonu, ať to tam nespamujem ;)

Na cvikach se to do nas snazili nejak nalit, kdyz zjistili, ze to nikdo nechape, ale bylo malo casu a musely se resit predepsane prakticke priklady. Ty prekvapive s vyucovanou teorii nemeli nic moc spolecneho (asi jsme to v tom jen nevideli, nevim, protoze snad ta teorie nebyla nanic?). Treba ty monady a do notaci jsem pochopil az mnohem pozdeji samostudiem pri praci na projektu. Jak jsem byl nastvany na prednasejiciho, ze takovou "nepodstatnou" vec mi zamlcel.
Mě začalo docela bavit koukat se, jakým způsobem různí lidi Haskell (a speciálně monády) vysvětlují. Přijde mi to jako hrozně zajímavé téma, protože to fakt není vůbec lehký vysvětlit dobře a tímpádem se na tom výborně ukazují pedagogické schopnosti. Skoro by se to hodilo jako test na vstupní pohovor pro vyučující (kdyby se něco takového dělalo, většinou nedělá).

Přijde mi totiž, že zrovna u monád se vůbec nevyplatí se odpíchnout od vysvětlování formalismu. V tom se drtivá většina lidí zasekne a dál se nedostane, takže v nich nezůstane vůbec nic, což je ta nejhorší možná varianta. Ono tam jde totiž vlastně o to, že úplně jednoduchý princip (skládání fcí) je z nějakých důvodů potřeba řešit poměrně komplikovaně a vychází to z ještě komplikovanějšího formálního aparátu. Takže jsem po dlouhých úvahách došel k tomu, že je potřeba člověku prvně nějak neformálně ukázat, proč to je a k čemu to vlastně slouží - a teprve potom, až má nějakou mlhavou představu, o čem je vlastně řeč, ukázat prvně buď příklad, nebo velice zlehounka ten formalismus.

Mně třeba největší aha moment přinesla nějaká prezentace, kde týpek vysvětloval monády jako větvení vlakových kolejí - když nedojde k chybě, jede vlak dál touhle cestou, a když dojde, přejede přes tuhle vyhýbku... Bohužel to teď asi nedohledám, ale tohle byla fakt první věc, na které jsem vůbec chytl, o co vlastně teda jde.

...a když tohle člověk chytne, tak už potom dá ty příklady - ale imho by jako první měl vidět příklad rozepsaný pomocí lambd, BEZ do notace a těch speciálních operátorů. Pokud to totiž uvidí napsané v do notaci, získá falešný dojem, že tomu rozumí ("jasně, to je jako v imperativních jazycích") a je úplně mimo, protože nepochopil vůbec nic.

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... Je to škoda. Zrovna tohle by si zasloužil znát každý mírně nadprůměrný programátor...

Jako chapu, ze ciste FP neni moc popularni. Ale vzhledem k tomu, jak se mu uspesne dari infiltrovat popularni jazyky, tak si myslim, ze minimalne jeden predmet v bakalari by si to zaslouzilo.
Určitě! Hele, upřímně, na Haskell jako takovej sere pes. Je to super obohacení, ale když ho nebudeš znát, nic moc se nestane. Co by ale každej měl znát (na škole minimálně "ochutnat"), je ten FP způsob myšlení - důraz na základní datové struktury a operace nad nimi, proudové zpracování, řetězení, atd. atd.

Ono totiž FP je úžasný způsob, jak si prakticky osahat ty datové struktury, o kterých se člověk učí v teorii...

Rozhodne nerazim nazor "Vsude ciste FP!". Treba prave ta Scala neni ani omylem cista (Haskellisti se na ni myslim celkem casto divaji shora) a FP se na nektere veci hodi mnohem vice, na jine naopak vice vynika imperativni pristup a OOP.
Myslím, že je úžasný koukat na to, jak Haskell razí principielní přístup bez výjimek a způsobuje si tím zpoustu problémů, které se nedají řešit jinak než relativně komplikovaně. A vedle něj jsou pragmatičtější jazyky, které jdou trochu "špinavější" cestou, ztrácí tím některé prima vlastnosti Haskellu, ale zase nemají ty jeho problémy a tímpádem se dají lehčeji naučit a líp se kombinují s tím, co člověk zná odjinud.

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.
« Poslední změna: 14. 05. 2016, 14:21:35 od Mirek Prýmek »

javaman

Re:Má Haskell budoucnost?
« Odpověď #22 kdy: 14. 05. 2016, 14:18:04 »
Mně se na použití Haskellu nelíbí hlavně ty příšerně dlouhé názvy funkcí, které mnozí programátoři používají. Proč, když máme propracovaný systém namespaces?
??? Tomu nerozumím, to je problém Javy, ne Haskellu :) Kde jsi narazil na dlouhá jména funkcí?

Například zde: https://github.com/Ohlasy/web/blob/gh-pages/_bin/top-articles.hs. Ty názvy funkcí mi připadají jako utřiNosoČistoPlenou nebo zahrajNaKlapkoBřinkoStroj. Je však docela možné, že jsem prostě náhodou narazil na nevhodný zdroják.

OMG, to by byl hnus i v Javě :D Takhle je to trochu moc, no.

andy

Re:Má Haskell budoucnost?
« Odpověď #23 kdy: 14. 05. 2016, 14:22:43 »
A proč máte interpret jako typeclass?
dobrá otázka, psaní toho kódu už na mě bylo intelektuálně trochu moc (jsem přece jenom prostý programátor C/C++), takže moje odpověď je poněkud mlhavá - má to něco společného se skládáním více "jazyků", motivovaným korektností použití příkazů pro ukončení iterace (tj. break a continue může být jenom v cyklu, jinak to ghc nepustí)
Mno... já teda mám zkušenost spíš s Operational, ale pořád to tak nějak nechápu... interpret je přece normální funkce, která má vstupem "Free a" (tzn. "data") a výstupem je cokoliv. Nějak nerozumím, proč by se nad čímkoliv (včetně té "instrukce") měla dělat jakákoliv typeclas...ale to už je asi otázka toho konkrétního kódu :)

Kit

Re:Má Haskell budoucnost?
« Odpověď #24 kdy: 14. 05. 2016, 14:28:23 »
Mně se na použití Haskellu nelíbí hlavně ty příšerně dlouhé názvy funkcí, které mnozí programátoři používají. Proč, když máme propracovaný systém namespaces?
??? Tomu nerozumím, to je problém Javy, ne Haskellu :) Kde jsi narazil na dlouhá jména funkcí?

Například zde: https://github.com/Ohlasy/web/blob/gh-pages/_bin/top-articles.hs. Ty názvy funkcí mi připadají jako utřiNosoČistoPlenou nebo zahrajNaKlapkoBřinkoStroj. Je však docela možné, že jsem prostě náhodou narazil na nevhodný zdroják.

OMG, to by byl hnus i v Javě :D Takhle je to trochu moc, no.

I v Javě jsou dlouhé názvy zbytečné. Vždyť má namespaces.

Re:Má Haskell budoucnost?
« Odpověď #25 kdy: 14. 05. 2016, 14:29:39 »
Mně třeba největší aha moment přinesla nějaká prezentace, kde týpek vysvětloval monády jako větvení vlakových kolejí -
Ten samý princip je použitý tady: http://www.zohaib.me/yet-another-what-is-a-monad-post/ Ale není to ten článek, co mi tenkrát přinesl ten aha moment :)

javaman

Re:Má Haskell budoucnost?
« Odpověď #26 kdy: 14. 05. 2016, 14:32:50 »
Mně se na použití Haskellu nelíbí hlavně ty příšerně dlouhé názvy funkcí, které mnozí programátoři používají. Proč, když máme propracovaný systém namespaces?
??? Tomu nerozumím, to je problém Javy, ne Haskellu :) Kde jsi narazil na dlouhá jména funkcí?

Například zde: https://github.com/Ohlasy/web/blob/gh-pages/_bin/top-articles.hs. Ty názvy funkcí mi připadají jako utřiNosoČistoPlenou nebo zahrajNaKlapkoBřinkoStroj. Je však docela možné, že jsem prostě náhodou narazil na nevhodný zdroják.

OMG, to by byl hnus i v Javě :D Takhle je to trochu moc, no.

I v Javě jsou dlouhé názvy zbytečné. Vždyť má namespaces.

Proto se tam nedělají. Máš tam normální názvy a nepotřebuješ tak často psát dokumentaci.

v

Re:Má Haskell budoucnost?
« Odpověď #27 kdy: 14. 05. 2016, 14:32:57 »
A proč máte interpret jako typeclass?
dobrá otázka, psaní toho kódu už na mě bylo intelektuálně trochu moc (jsem přece jenom prostý programátor C/C++), takže moje odpověď je poněkud mlhavá - má to něco společného se skládáním více "jazyků", motivovaným korektností použití příkazů pro ukončení iterace (tj. break a continue může být jenom v cyklu, jinak to ghc nepustí)
Mno... já teda mám zkušenost spíš s Operational, ale pořád to tak nějak nechápu... interpret je přece normální funkce, která má vstupem "Free a" (tzn. "data") a výstupem je cokoliv. Nějak nerozumím, proč by se nad čímkoliv (včetně té "instrukce") měla dělat jakákoliv typeclas...ale to už je asi otázka toho konkrétního kódu :)
problém nastal, když jsem začal skládat dva jazyky, jeden "normální", druhý (tvořený příkazy break a continue) povolený jen v těle iterace jako součet s oním "normálním", pak je nutné použít stejnou interpretační funkci na dva různý typy
jestli to zní zmateně, tak to může být i tím, že já sám jsem

andy

Re:Má Haskell budoucnost?
« Odpověď #28 kdy: 14. 05. 2016, 14:48:06 »
Tomuhle moc nerozumím - co jsi tím chtěl říct? Jak souvisí Maybe s lazy/strict eval? A jak se liší tenhle Maybe od toho haskellovského?
Kouknul jsi se na ten link? Kvůli maybe potřebuješ dvojnásobek funkcí, protože jak je to strikt, tak musíš řešit, že by se třeba ten druhý parametr musel vyhodnocovat dlouho. Takže oproti zcela triviální implimentaci Maybe v haskellu to je docela prohra.

Citace: Radek Míček
Přijde mi lepší explicitně říci, že se něco konkrétního nemá vyhodnocovat striktně, než naopak - osobně chci častěji vyhodnocovat hned než nevyhodnocovat. Pokud jde o to, že při každém volání fromMaybe' musím argument obalit funkcí, tak to jde vyřešit tím, že to udělá kompilátor na základě typu (například když typ parametru bude Lazy Int, tak to kompilátor zabalí automaticky - tj. argument se nebude vyhodnocovat).
No mě to taky připadá lepší, když je něco explicitně - takže automatické obalování v žádném případě ne.

Ale jinak: Pro ty, kteří opravdu bazírují na výkonnosti tu máme https://ghc.haskell.org/trac/ghc/wiki/StrictPragma. Stačí to dát na začátek modulu (nebo do Cabalu) a jede se... ale osobně kromě snad nějakého výpočetního důvodu to fakt nemám důvod použít.

Citace
Třeba u typové třídy Ord by mi to přišlo docela užitečné. Nebo třeba u monoidu se to musí obcházet pomocí newtype Sum a newtype Product. A nakonec se může stát, že dvě různé knihovny obsahují různé instance pro jeden typ, a pokud se nepletu, tak GHC program neslinkuje?
Tak to je dobře (GoodThing), že to neslinkuje :) Proto taky GHC varuje před OrphanInstances a když jsou v knihovně OrphanInstances tak to je BadThing. On na první pohled ten newtype vypadá "kostrbatě", ale mě třeba připadá, že jinak to stejně nejde - nebylo by to "composable".

Třeba jsem řešil, že chci ve FromJSON struktuře deserializovat něco jinak, než je v default typeclass - třeba některá čísla tam jsou hexadecimálně ve stringu. A nevím, jak by se tohle řešilo - přiřadit typeclass konkrétní položce v recordu? A pak ta hodnota bude i s tou typeclass někde cestovat?

Citace: Mirek Prýmek
Myslím, že je úžasný koukat na to, jak Haskell razí principielní přístup bez výjimek a způsobuje si tím zpoustu problémů, které se nedají řešit jinak než relativně komplikovaně.
Nevím, mě to přijde tak trochu ve stylu "počítače pomáhají řešit problémy, které by bez nich neexistovaly". Spousta problémů, které se v Haskellu řeší, v jiných jazycích neexistují, protože se tam vůbec něco takového nedá vyjádřit.

andy

Re:Má Haskell budoucnost?
« Odpověď #29 kdy: 14. 05. 2016, 14:50:12 »
problém nastal, když jsem začal skládat dva jazyky, jeden "normální", druhý (tvořený příkazy break a continue) povolený jen v těle iterace jako součet s oním "normálním", pak je nutné použít stejnou interpretační funkci na dva různý typy
jestli to zní zmateně, tak to může být i tím, že já sám jsem
Aniž bych viděl kód - někdo tu linkoval http://www.cs.ru.nl/~W.Swierstra/Publications/DataTypesALaCarte.pdf - vypadá to jako dost podobné tomu, co děláš :)