Má Haskell budoucnost?

[Ondra Satai Nekola]

A to je v čem horší než stejný případ v Pascalu, když si pošleš do funkce data, která sis před tím nabořil?
Je to naopak lepší v tom, že potenciálně nabořená místa nutně znáš 


(jinak to, co popisuješ je problém, ale ne side effect. A všude jinde je ten problém horší. Nemluvě o tom strašáku budoucích prasat v haskellu.)

[Reklama]

[Logik]

Ohledně otázky, zdali je pro člověka přirozenější funkcionální nebo imperativní paradigma je myslím odpověď jasná. Stačí nebejt "provinční" a zvednout hlavu od monitoru.

V jaké formě je psaná každá kuchařka? Ve stylu:
= rozděl vejce na žloutek a bílek
= bílek utři na sníh
= přimíchej tam žloutek, cukr a mouku a olej
= nalejte do formy
= pečte hodinu při 200 stupních

Nebo stylem:
= bílek a žloutek získáte rozdělením vejce
= sníh získáte ušleháním bílku
= těsto na bábovku získáte smíšením sněhu, žloutku, cukru a mouky a oleje
= neupečenou bábovku získáte nalitím těsta do formy
= bábovku získáte hodinovým pečením neupečené bábovky při 200 stupních.
(ideálně ještě nikoliv tomto pořadí :-))
?

FP má nemálo výhod - ale rozhodně to není způsob, jak lidé přirozeně přemýšlí.

Co se týče vysvětlení monád, tak nejlepší text, co jsem našel, mi přijde tento:
https://wiki.haskell.org/IO_inside
(teda doufám, že monády chápu správně, v haskellu jsem dělal jen zkoušku na VŠ :-)

[zboj]

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.

Zajímavá úvaha, nicméně nepříliš relevantní řekl bych, v imperativním paradigmatu se také krátkodobá paměť dost napíná.
Jak je na tom z tohoto pohledu logické programování?

[v]

Ohledně otázky, zdali je pro člověka přirozenější funkcionální nebo imperativní paradigma je myslím odpověď jasná. Stačí nebejt "provinční" a zvednout hlavu od monitoru.

V jaké formě je psaná každá kuchařka? Ve stylu:
= rozděl vejce na žloutek a bílek
= bílek utři na sníh
= přimíchej tam žloutek, cukr a mouku a olej
= nalejte do formy
= pečte hodinu při 200 stupních

Nebo stylem:
= bílek a žloutek získáte rozdělením vejce
= sníh získáte ušleháním bílku
= těsto na bábovku získáte smíšením sněhu, žloutku, cukru a mouky a oleje
= neupečenou bábovku získáte nalitím těsta do formy
= bábovku získáte hodinovým pečením neupečené bábovky při 200 stupních.
(ideálně ještě nikoliv tomto pořadí :-))
?

FP má nemálo výhod - ale rozhodně to není způsob, jak lidé přirozeně přemýšlí.

a jak si vysvětlujete matematiku?

[Ivan Nový]

Logické programování ještě hůře, proto se neprosadilo skoro vůbec. To jsou vlastně už jen kolekce pravidel nesvázaných pořadím vykonávání. Rozhodnout pak, zda nějaký "jazyk" vstupních dat jim odpovídá, se už jen tak nedá. Pak to, zda program dělá to co má, je založeno už jen na víře.

Je to podobná situace jako v účetnictví, kdy v určitém momentu musíte věřit, že je to dobře zaúčtované, protože zkontrolovat to, znamená udělat ho celé znovu, s dalšími novými chybami.

Ostatně evoluce přijala podobný kompromis, imperativní paradigma, které se projevuje v tom, že realitu vnímáme skrze čas a ne v jejím celku, najednou.

[Reklama]

[zboj]

Logické programování ještě hůře, proto se neprosadilo skoro vůbec. To jsou vlastně už jen kolekce pravidel nesvázaných pořadím vykonávání. Rozhodnout pak, zda nějaký "jazyk" vstupních dat jim odpovídá, se už jen tak nedá. Pak to, zda program dělá to co má, je založeno už jen na víře.

Je to podobná situace jako v účetnictví, kdy v určitém momentu musíte věřit, že je to dobře zaúčtované, protože zkontrolovat to, znamená udělat ho celé znovu, s dalšími novými chybami.

Ostatně evoluce přijala podobný kompromis, imperativní paradigma, které se projevuje v tom, že realitu vnímáme skrze čas a ne v jejím celku, najednou.

To je princip deklarativních jazyků, že nazáleží na pořadí.

[Mirek Prýmek]

FP má nemálo výhod - ale rozhodně to není způsob, jak lidé přirozeně přemýšlí.

Haskell imho nebyl vymyšlen tak, aby se podobal způsobu, jak lidi myslí, ale způsobu, jak myslí matematici

Akorát bych byl trochu opatrnější se ztotožňováním FP s pure default-lazy jazykem. To je jenom podmnožina FP jazyků. A spíš menší: OCaml, Racket, F#, Erlang, Elixir - všechny jsou defaultně eager, čili by se tam normálně napsalo "vem vejce, rozklepni ho, utři ho"

[zboj]

FP má nemálo výhod - ale rozhodně to není způsob, jak lidé přirozeně přemýšlí.

Haskell imho nebyl vymyšlen tak, aby se podobal způsobu, jak lidi myslí, ale způsobu, jak myslí matematici

Akorát bych byl trochu opatrnější se ztotožňováním FP s pure default-lazy jazykem. To je jenom podmnožina FP jazyků. A spíš menší: OCaml, Racket, F#, Erlang, Elixir - všechny jsou defaultně eager, čili by se tam normálně napsalo "vem vejce, rozklepni ho, utři ho"

A matematici nejsou lidi? :/

Jinak zrovna matematikům je nějaké programování u ř**i, maximálně to může reflektovat, jak si nějaký programátor myslí, že se matematika dělá. Proto to taky vypadá, jak to vypadá, například ta příšerná syntax. Jazyky navržené matematiky jsou třeba HAL/S či Q systémy, případně i Prolog, ale do toho už kafrali informatici.

[v]

FP má nemálo výhod - ale rozhodně to není způsob, jak lidé přirozeně přemýšlí.

Haskell imho nebyl vymyšlen tak, aby se podobal způsobu, jak lidi myslí, ale způsobu, jak myslí matematici

Akorát bych byl trochu opatrnější se ztotožňováním FP s pure default-lazy jazykem. To je jenom podmnožina FP jazyků. A spíš menší: OCaml, Racket, F#, Erlang, Elixir - všechny jsou defaultně eager, čili by se tam normálně napsalo "vem vejce, rozklepni ho, utři ho"

main = do
    vem_vejce
    rozklepni_ho
    utři_ho
popř. main = vem_vejce >> rozklepni_ho >> utři_ho

[Mirek Prýmek]

main = do
    vem_vejce
    rozklepni_ho
    utři_ho
popř. main = vem_vejce >> rozklepni_ho >> utři_ho

No ano, za tím je ta bižuterie, která je u Haskellu nutně potřeba, aby se dalo psát v sousledných krocích. U jiných jazyků potřeba není. To jsem přece říkal.

[v]

main = do
    vem_vejce
    rozklepni_ho
    utři_ho
popř. main = vem_vejce >> rozklepni_ho >> utři_ho

No ano, za tím je ta bižuterie, která je u Haskellu nutně potřeba, aby se dalo psát v sousledných krocích. U jiných jazyků potřeba není. To jsem přece říkal.

takže v haskellu to jde stejně jako jinde, ale je to špatně, protože... proč? implementačními detaily se snad zabývat nemusíme, kdo si píše vlastní překladač?

[Mirek Prýmek]

takže v haskellu to jde stejně jako jinde, ale je to špatně, protože... proč? implementačními detaily se snad zabývat nemusíme, kdo si píše vlastní překladač?

Nejde to stejně jako jinde. V Haskellu se dá pomocí relativně složitého aparátu (monády) dosáhnout toho chování, které je v jiných FP jazycích defaultní. Ani jedno není vyloženě dobře nebo špatně. Prostě když si zvolím čistotu, tak mi to způsobuje komplikace. Udivuje mě, že je kolem toho tolik řečí, mně to přijde jako zjevná věc.

Jinak zrovna matematikům je nějaké programování u ř**i

Lambda calculus vymyslel matematik

[v]

takže v haskellu to jde stejně jako jinde, ale je to špatně, protože... proč? implementačními detaily se snad zabývat nemusíme, kdo si píše vlastní překladač?

Nejde to stejně jako jinde. V Haskellu se dá pomocí relativně složitého aparátu (monády) dosáhnout toho chování, které je v jiných FP jazycích defaultní.

a to má být výhoda těch jiných jazyků?

[zboj]

takže v haskellu to jde stejně jako jinde, ale je to špatně, protože... proč? implementačními detaily se snad zabývat nemusíme, kdo si píše vlastní překladač?

Nejde to stejně jako jinde. V Haskellu se dá pomocí relativně složitého aparátu (monády) dosáhnout toho chování, které je v jiných FP jazycích defaultní. Ani jedno není vyloženě dobře nebo špatně. Prostě když si zvolím čistotu, tak mi to způsobuje komplikace. Udivuje mě, že je kolem toho tolik řečí, mně to přijde jako zjevná věc.

Jinak zrovna matematikům je nějaké programování u ř**i

Lambda calculus vymyslel matematik

1) Monády jsou složitý aparát? Dvě funkce a dvě rovnice, která musí splňovat, to mi přijde jako celkem málo.
2) Lambda kalkulus ale není programovací jazyk, right? I do Lispu při vší jeho jednoduchosti naplácali informatici různé ptákoviny (z matematického pohledu).

[Mirek Prýmek]

a to má být výhoda těch jiných jazyků?

1. Tohle téma se odpíchlo od Andyho otázky "Já fakt nechápu, co je za komplikace v default-lazy jazyku."
2. Někdo (třeba já) to za výhodu může považovat, protože si může myslet, že programování pomocí sousledných kroků je přirozenější lidskému myšlení a tudíž to chceme jako default a pomocí bižuterie chceme dosahovat lazyness, ne opačně.

Btw, když jsme nakousli to "Proč Haskell vznikl?", koukám na zajímavej paper http://haskell.cs.yale.edu/wp-content/uploads/2011/02/history.pdf a tam je jedna zajímavá informace v podobném duchu:

An anonymous reviewer supplied the following: “An interesting
sidelight is that the Friedman and Wise paper inspired Sussman and
Steele to examine lazy evaluation in Scheme, and for a time they
weighed whether to make the revised version of Scheme call-byname
or call-by-value. They eventually chose to retain the original
call-by-value design, reasoning that it seemed to be much easier to
simulate call-by-name in a call-by-value language (using lambdaexpressions
as thunks) than to simulate call-by-value in a call-byname
language (which requires a separate evaluation-forcing mechanism).
Whatever we might think of that reasoning, we can only
speculate on how different the academic programming-language
landscape might be today had they made the opposite decision.”

Dobrá perlička

1) Monády jsou složitý aparát? Dvě funkce a dvě rovnice, která musí splňovat, to mi přijde jako celkem málo.

No jo no, ale vidíš, jak se na tom lidi zasekávaj

2) Lambda kalkulus ale není programovací jazyk, right? I do Lispu při vší jeho jednoduchosti naplácali informatici různé ptákoviny (z matematického pohledu).

Ale matematici za to všechno můžou jako prvotní příčina!