Zobrazit příspěvky
Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.
Nevím, mně přijdou taková porovnání celkem užitečná, i Einstein přece létal na paprsku světla (díky čemuž jsem kdysi dávno pochopil speciální teorii relativity)Tak ty koleje vysvětlují celkem hezky (polopaticky) právě to Maybe, ale nic jiného kolem monád. Možná že každá konkrétní monáda vyžaduje svou metaforu.možná, že jeden z problémů je používání metafor
Tak ty koleje vysvětlují celkem hezky (polopaticky) právě to Maybe, ale nic jiného kolem monád. Možná že každá konkrétní monáda vyžaduje svou metaforu.a taky IOTo je ale trochu zjednodušující, seznam je taky monáda a takto vysvětlit nejde, ne?byl jste rychlejší, dále např. identity, reader, state
prostě říct, že monáda je jako tamto kolejiště je jako říct, že monáda je jako burrito
To je prostě jen jeden typ monády, Maybe nebo případně Error.[citation needed]Ty koleje vypadají dobře. Teď mi zbývá jen pochopit, co mají s těmi monádami společného...Ty koleje vyjadřují tvůj základní cíl: chceš skládat funkce, které při úspěchu vrací typ X a pokračují ve zpracování, zatímco při neúspěchu vraxí typ Y a dál nepokračují. To je přesně to, k čemu monády slouží a je to triviální.
To je ale trochu zjednodušující, seznam je taky monáda a takto vysvětlit nejde, ne?Ty koleje vypadají dobře. Teď mi zbývá jen pochopit, co mají s těmi monádami společného...Ty koleje vyjadřují tvůj základní cíl: chceš skládat funkce, které při úspěchu vrací typ X a pokračují ve zpracování, zatímco při neúspěchu vraxí typ Y a dál nepokračují. To je přesně to, k čemu monády slouží a je to triviální.
Potom další krok je, jak toho dosáhnout - no a dosáhneš toho vhodně zvolenými lambda funkcemi. To pořád ještě pochopí každý.
...no a pak teprve přichází ta magie: tenhle celý cirkus můžeš nadefinovat obecně, bez ohledu na konkrétní typy a tomu se říká monáda.
Snadný jak facka, ne?!
1) Tak aspoň jsou ty koleje názornější než burritos.Burritos jsou nesmysl, tohle je názorný, korektní vysvětlení přímo k jádru pudla.
A zase ty monoidyJasněMonády a jak je (ne)učit se tu už řešilo, ne?Ani ne. Minule jsme se bavili hlavně o tom, jestli je vůbec potřeba je znát k tomu, aby člověk mohl programovat IO v Haskellu.
A zase ty monoidyMně 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
Citace z vlákna o pythonu, ať to tam nespamujemMonády a jak je (ne)učit se tu už řešilo, ne? Vzhledem k tomu, že jsou začarované (jakmile je někdo pochopí, ztrácí tím automaticky schopnost je vysvětlovat, a něco na tom bude, normálně se mi celkem daří vysvětlovat lidem složitější koncepty jako entropii nebo modality apod., ale u monád mi to prostě nejde), to ani nemá moc smysl.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.
Dlouhá jména funkcí nemusí být nevýhodou, v kombinaci s vhodně zvolenou konvencí nahrazují dokumentaci.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
co máte na mysli, když píšete "budoucnost"? masové rozšíření? dlouhodobé přežívání?Nejspíš přežívání v akademické sféře.
Mít Prolog a FP v jednom předmětu je dost blbý nápad. Jinak FP je asi jeden z mála konceptů, co by se měl učit začínaje od teorie, protože z fleku se v tom rozumně psát fakt nedá (na rozdíl třeba i od toho Prologu, jenž je taky dost daleko od mainstreamu).Pattern matching treba ve Scale je hodne silny, defaultne umi i regexpy, ale lze si dodefinovat libovolny extractor. Celkem skoda, ze se podobne veci v popularnich jazycich prilis nevidi.Ono je obecně škoda, že se v populárních jazycích moc nevidí koncepty z FP. Možná si tvůrci jazyků myslí, že na běžného vývojáře je FP moc složité/abstraktní/matoucí... Přitom takové OOP většina také dost patlá...
Je stejne zajimave, jak dlouho trvalo OOP, nez se prosadilo. Pokud si to pamatuju spravne, tak byl potreba prechod na graficka uzivatelska rozhrani, kde OOP zazarilo, a az pak se opravdu masove zacalo pouzivat. Mozna stojime na podobnem prahu - jak roste pocet jader, ale ne vykon jadra, tak FP pristup zacina byt dost zajimavy.
PS: Je opravdu dost mozne, ze je to pouze zpusobeno pristupem skol, kdy se imperativni pristup uci prvni. A teda prijde me, ze i podstatne lepe, nez treba ten funkcionalni. V imperativnim jsme rovnou zacali patlat v C, u funkcionalniho jsme nejdriv museli prezit a nepochopit (nasprtat se) teorii a az pak, pri reseni projektu, zacit chapat, o cem ze ta teorie asi ze byla.
Já jsem se s haskellem setkal ve škole asi před 10-ti lety a nevzpomínám si, že by ho někdo ze spolužáků začal ihned používat v praxi. Víc než na škole záleží na vyspělosti ekosystému okolo. Ten je dneska úplně jinde. Naopak, dynamické jazyky jako ruby, php a js se nikdy nikde neučily a rozšířily se docela rychle.
No, ja se taky "setkal", ale ve srovnani s imperativnim pristupem, ktery se do nas tlacil vlastne neustale, setkani v ramci poloviny jednoho predmetu bylo opravdu slabe.
stredni (gympl):
- Pascal (nekteri spoluzaci z prumek znali trochu C, dost lidi neznalo nic)
bc:
- C (nekolik predmetu)
- ASM
- C++/Java (na vyber jedno)
- Python (myslim take nekolikrat na psani ukolu)
- cisty stary JavaScript
- Pascal+pseudo kod
mgr:
- C/C++ (nekolik predmetu, na projekty)
- Java/nejaky neznamy jazyk na IS
- 1x jazyk podle vlastniho vyberu (pouzil jsem Scalu)
- Ada+nejaky dalsi paralelni
- Haskell+Prolog (vcetne teorie k obema paradigmatum)
- 2x C#
- Python (zase ukoly, tusim sifrovani)
Asi jsem na neco zapomnel, ale funkcionalni bych si pamatoval. Kdyz to shrneme, tak mame za cele studium 0,5 predmetu venovanemu funkcionalnimu jazyku (jeste teda JavaScript, ale tomu nebyl take venovan cely predmet a FP jako takove se tam snad ani neresilo; navic JS podle nekterych definic ani nespada do funkcionalnich jazyku). Takze ne, nedivim se, ze nikdo z mych spoluzaku nebezel a nezacal pracovat v FP jazyce.
Je mozne, ze na vasi skole jste meli destiky predmetu vyucujici a vyuzivajici FP a funckionalni jazyky. Sice jsem znacne skepticky, ale co. Pokud je tomu opravdu tak, prosim podelte se o jmeno skoly (bych si treba i precetl jake predmety jste meli a tise zavidel).
Pattern matching treba ve Scale je hodne silny, defaultne umi i regexpy, ale lze si dodefinovat libovolny extractor. Celkem skoda, ze se podobne veci v popularnich jazycich prilis nevidi.Ono je obecně škoda, že se v populárních jazycích moc nevidí koncepty z FP. Možná si tvůrci jazyků myslí, že na běžného vývojáře je FP moc složité/abstraktní/matoucí... Přitom takové OOP většina také dost patlá...
Je stejne zajimave, jak dlouho trvalo OOP, nez se prosadilo. Pokud si to pamatuju spravne, tak byl potreba prechod na graficka uzivatelska rozhrani, kde OOP zazarilo, a az pak se opravdu masove zacalo pouzivat. Mozna stojime na podobnem prahu - jak roste pocet jader, ale ne vykon jadra, tak FP pristup zacina byt dost zajimavy.
PS: Je opravdu dost mozne, ze je to pouze zpusobeno pristupem skol, kdy se imperativni pristup uci prvni. A teda prijde me, ze i podstatne lepe, nez treba ten funkcionalni. V imperativnim jsme rovnou zacali patlat v C, u funkcionalniho jsme nejdriv museli prezit a nepochopit (nasprtat se) teorii a az pak, pri reseni projektu, zacit chapat, o cem ze ta teorie asi ze byla.
Pattern matching treba ve Scale je hodne silny, defaultne umi i regexpy, ale lze si dodefinovat libovolny extractor. Celkem skoda, ze se podobne veci v popularnich jazycich prilis nevidi.Ono je obecně škoda, že se v populárních jazycích moc nevidí koncepty z FP. Možná si tvůrci jazyků myslí, že na běžného vývojáře je FP moc složité/abstraktní/matoucí... Přitom takové OOP většina také dost patlá...
Jasně, mea culpa (proč sakra nemůžu editovat příspěvek??!!). S tím druhým taky v podstatě souhlasím, protože to, že pattern matching se ve Swiftu uvozuje slovem switch, o ničem moc nevypovídá.Pokud někdo použije Swift místo polymorfismu, tak je ňouma a měl by se nejdřív naučit programovat. Nicméně pattern matching je v podstatě jen zakamuflovaný switch, a k tomu s režií navíc, viz Swift.
S prvnim souhlas (po s/Swift/switch
Pokud někdo použije Swift místo polymorfismu, tak je ňouma a měl by se nejdřív naučit programovat. Nicméně pattern matching je v podstatě jen zakamuflovaný switch, a k tomu s režií navíc, viz Swift.Statickým metodám se úmyslně vyhýbám, proto mi tento detail unikl.
Tak to už máme boolean hodnoty, gettery/settery a statické metody v jediném vlákně. Které všechny konstrukce ještě považujete za naprosto zbytečné? Upřímně mě to zajímá.
Abych nezapomněl, tak jsem vyloučil konstrukce "else" a "elseif". Také jsem zrušil používání "break" uvitř konstrukce "switch". Aplikace to docela významně zkrátí, zjednoduší a zpřehlední.
Některé jazyky mají "else" jako součást ternárního operátoru. Tam ho samozřejmě používám.
Proc nezrusit i cely switch? Krome nekolika malo pripadu (ale fakt malo) je to jen chapa nahrada za spatne navrzenou hierarchii trid (vetsinou se da nahradit polymorfismem a v lepsich!!! jazycich pattern matchingem).
Root.cz (www.root.cz), informace nejen ze světa Linuxu. ISSN 1212-8309
Copyright © 1998 – 2023 Internet Info, s.r.o. Všechna práva vyhrazena. Powered by Linux.
