Dědičnost dnes

[Jozko]

ty proklate objekty 

[Reklama]

[bob]

Nicméně v FP nic krom monád uvedený problém neřeší a aspoň osmnáctileté "dítě" je určitě schopno najít si k monádám

Ja teda nevim, ja puvodni otazku pochopil tak, ze jak se da zmenit stav, kdyz je vse immutable. Zmenou stavu rozumim, jak muzu napr. zmenit hodnotu ve formulari. Problem se resi tak, ze se stara hodnota zahodi a vytvori se nova a ta se zobrazi.

Na tohle snad monady nepotrebujete?

[JS]

Mozna blba otazka, ale ja jsem myslel, ze kdyz knihovna v Haskellu nevyexportuje konstruktor, tak se k tomu nikdo krome knihovny nedostane. To neni zapouzdreni?

To mas pravdu, to me nenapadlo. To se samozrejme da brat jako zapouzdreni a je to v poradku.

Ale je tady jeden zasadni rozdil - v OOP je to skryvani nutne, protoze objekty jsou mutabilni, a neni mozne dovolit ostatnim s nimi zevne nakladat. Ale hodnoty predavane v FP jsou imutabilni, tudiz v podstate neni duvod je takto skryvat (vyjma snad situaci, kde uvnitr kodu fakticky dochazi k poruseni referencni transparence, treba z duvodu efektivity).

[JS]

Těžko se k tomu hledá motivace. Monády řeší problém, který neexistuje.

Jesli znas treba funkci "flatMap" (napr. bere seznam, na kazdy prvek aplikuje funkci, ktera z nej dela seznam, a vysledny seznam spoji), tak vsechno, na co se da nejak aplikovat flatMap, je v podstate monada.

Nejde ani tak o to, ze monady resi nejaky konkretni problem; jsou spis popisem spolecnych vlastnosti mnoha ruznych veci (rika se tomu "abstrakce").

Na tohle snad monady nepotrebujete?

Viz vys - nepotrebujes vedet co jsou, ale monada se za tim najit da, konkretne monada funkci, co meni stav (stavova monada).

[v]

Mozna blba otazka, ale ja jsem myslel, ze kdyz knihovna v Haskellu nevyexportuje konstruktor, tak se k tomu nikdo krome knihovny nedostane. To neni zapouzdreni?

To mas pravdu, to me nenapadlo. To se samozrejme da brat jako zapouzdreni a je to v poradku.

Ale je tady jeden zasadni rozdil - v OOP je to skryvani nutne, protoze objekty jsou mutabilni, a neni mozne dovolit ostatnim s nimi zevne nakladat. Ale hodnoty predavane v FP jsou imutabilni, tudiz v podstate neni duvod je takto skryvat (vyjma snad situaci, kde uvnitr kodu fakticky dochazi k poruseni referencni transparence, treba z duvodu efektivity).

minimálně ještě jedna taková situace existuje (např. u Data.Map), kdy knihovní funkce předpokládají něco o hodnotách s nimiž pracují, tedy když typ umožňuje vytvořit (z nějakého pohledu) neplatnou hodnotu (a její kontrola není levná)

[Reklama]

[bob]

Viz vys - nepotrebujes vedet co jsou, ale monada se za tim najit da, konkretne monada funkci, co meni stav (stavova monada).

Ja s tim souhlasim, ale o co mi slo. Ze se nekdo zepta  (zacatecnik v FP), jak tedy FP meni stavy, kdyz je vse immutable. A dostane odpoved, ktera je 100 % sravna, ale nejslozitejsi a pro novacka naprosto nevhodna. Chtel jsem rict, ze zakladni princip je mnohem jednodussi. Misto toho se dozvim, ze 18 lety chovanec jedlickova ustavu je chytrejsi nez ja a mel bych nechat IT...

[SB]

V jiné diskuzi se řešila typová kontrola a vynucení implementace abstraktních metod. K tomu jsou metatřídy ideální.

Kurva, teď mě napadá: Nedalo by se úpravou metatřídy Objektu v Pythonu (či jak to má udělané) dodělat to chybějící zapouzdření???

[SB]

Smalltalk je má taky https://en.wikipedia.org/wiki/Metaclass#In_Smalltalk-80. Umožňují jednoduchou implementaci nových vlastností jazyku a reflexivity, funkční polymorfismus na straně třídy, jednoduché ukládání do objektové DB... Přitom s nimi nemusí běžný vývojář přijít do styku.
Který jazyk to má?

Java

Nene. To je (nejspíš) jen omrdávkou, jak rozšířit třídy final. Asi to šlohli z Ckanálu. Žádná z výše uvedených věcí se tím realizovat nedá.

[SB]

to je něco úplně jiného.

Je to stejný výsledek bez metatříd. Tohle jsou tedy jen rozšiřující metody, ukládání do DB dělá třeba Hibernate, třídy lze měnit za běhu JVM přes ClassLoader. Nemá to tedy všechny schopnosti metatříd (třeba nejdou měnit již instancované objekty bez jejich znovuvytvoření, což jde přes ten Hibernate), ale ty zmíněné to umí.
...

Mluvíte o zcela něčem jiném. Mimoto ukládání (pouze!) stavů objektů přes Hibernate do RDB nemá s objektovou databází vůbec nic společného.

[ava]

Viz vys - nepotrebujes vedet co jsou, ale monada se za tim najit da, konkretne monada funkci, co meni stav (stavova monada).

Ja s tim souhlasim, ale o co mi slo. Ze se nekdo zepta  (zacatecnik v FP), jak tedy FP meni stavy, kdyz je vse immutable. A dostane odpoved, ktera je 100 % sravna, ale nejslozitejsi a pro novacka naprosto nevhodna. Chtel jsem rict, ze zakladni princip je mnohem jednodussi. Misto toho se dozvim, ze 18 lety chovanec jedlickova ustavu je chytrejsi nez ja a mel bych nechat IT...

Přesně tak, navíc je ta odpověď pro někoho, kdo FP nezná, zavádějící. Ani stavová monáda totiž stav nemění v tom smyslu, že by upravovala nějakou mutable strukturu, jak by mohlo někoho, kdo FP nezná, napadnout.

Stavová monáda je jen (když to zjednoduším) sada funkcí a datových struktur, které jsou vhodné pro popis a kombinování immutable stavových automatů. Navíc  v jazycích se syntaktickou podporou pro monadické operace (haskell, scala) takové popisy vypadají skoro jako jako instrukce v imperativních programech (proto se taky monádám občas říká "programovatelný středník". I tady ale stále platí to, že při vykonávání programu se staré immutable stavy zahazují a vytvářejí se nové, jak tu někdo napsal přede mnou, a podle mě to opravdu nejlépe vystihuje, jak se v FP řeší stav.

[SB]

...Většina vědních oborů považuje jednoduchá řešení za elegantní a hledá právě jednoduchá řešení. SW inženýrství je výjimka. Vyžívá se v uměle složitých řešeních jednoduchých problémů. Proto je pro spoustu lidí jeho studium nepřístupné.

Nesouhlasím. V IT je mnoho krásných, geniálních, jednoduchých myšlenek, vhodným příkladem je zrovna původní, čisté OP. Klíčem je nepustit k jejich implementaci *uráky.

[SB]

A tuto pohádku znáte? http://web.archive.org/web/20160526012716/http://harmful.cat-v.org/software/OO_programming/why_oo_sucks

článek o spoluautora jazyka Erlang...

Tak jsem to pročetl... Je-li pan Armstrong spoluautorem Erlangu, je zarážející, že podstatu OOP naprosto, ale NAPROSTO nepochopil:

Objection 1: OOP oproti FP "data" a "funkce" spojuje z jednoduchého důvodu, a to, že data bez funkcí jsou k ničemu stejně tak jako funkce bez dat, přičemž funkce jsou vytvořeny pro daná data (to nevylučuje práci s obecnými daty jako v FP!). Myšlenka nutnosti nespojovat funkce a data jen z důvodu, že se jedná o jiné kategorie, je neopodstatněná (to ale neznamená, že to nejde).
Objection 2: Různé třídy (typy; či prototypy) pro různé časové údaje se používají v implementacích OOP naprosto běžně - tento bod je nadbytečný.
Objection 3: Všudypřítomné "typy" se realizují třídami či prototypy. Poslední věta fabuluje cosi o nutnosti dědění.
Objection 4: Objekty mají skryté stavy, ale nedávno mi tu pan Prýmek vysvětlil na Elixíru, že FP je má taky, akorát je jinak ukládá. Kde je potom rozdíl?

Závěr: Takhle teda ne.

[SB]

Tak zase abychom nekřivdili FP, každý, kdo používá seznam (v jakémkoliv jazyce), používá monády (i když to většina netuší). Jsou to prostě potvory všudypřítomné a myslím, že většinu lidí děsí jen ten termín, jinak je vesele používají všude možně. Navíc i v "čistém" FP se většinou používá syntaktický cukr, díky němuž kód vypadá celkem procedurálně.

A o tom to je: Problém nemusí vůbec být v monádách, ale ve vystižení jejich myšlenky. Měl jsem s tím problém na všech školách - jestliže přesně nevystihnul podstatu myšlenky (a to je přece smyslem), nefungovalo to.
Takže (nejen pro mě) by se hodilo uvést nějaký zdroj, který přesně vystihuje podstatu (jako neznalý jej nerozpoznám). Upozorňuju, že právě na Wikipedii jsou uvedeny příklady bez jakéhokoliv úvodu do syntaxe, takže jsou nečitelné. I na ten elixírový příklad jsem musel docela čumět, než jsem odhadnul, co by to asi tak mohlo dělat.

[javaman ()]

V jiné diskuzi se řešila typová kontrola a vynucení implementace abstraktních metod. K tomu jsou metatřídy ideální.

Kurva, teď mě napadá: Nedalo by se úpravou metatřídy Objektu v Pythonu (či jak to má udělané) dodělat to chybějící zapouzdření???

Samozřejmě dalo, ale máš pak z toho ještě větší sračku než na začátku. Prostě Python nechat lopatám a i bez zapouzdření.

A tuto pohádku znáte? http://web.archive.org/web/20160526012716/http://harmful.cat-v.org/software/OO_programming/why_oo_sucks

článek o spoluautora jazyka Erlang...

Tak jsem to pročetl... Je-li pan Armstrong spoluautorem Erlangu, je zarážející, že podstatu OOP naprosto, ale NAPROSTO nepochopil:

Objection 1: OOP oproti FP "data" a "funkce" spojuje z jednoduchého důvodu, a to, že data bez funkcí jsou k ničemu stejně tak jako funkce bez dat, přičemž funkce jsou vytvořeny pro daná data (to nevylučuje práci s obecnými daty jako v FP!). Myšlenka nutnosti nespojovat funkce a data jen z důvodu, že se jedná o jiné kategorie, je neopodstatněná (to ale neznamená, že to nejde).
Objection 2: Různé třídy (typy; či prototypy) pro různé časové údaje se používají v implementacích OOP naprosto běžně - tento bod je nadbytečný.
Objection 3: Všudypřítomné "typy" se realizují třídami či prototypy. Poslední věta fabuluje cosi o nutnosti dědění.
Objection 4: Objekty mají skryté stavy, ale nedávno mi tu pan Prýmek vysvětlil na Elixíru, že FP je má taky, akorát je jinak ukládá. Kde je potom rozdíl?

Závěr: Takhle teda ne.

+1

Pán tomu prostě moc nerozumí, ale keců má plno

[SB]

...Java hazi klacky pod nohy tim, ze chce mit vsude ty proklate objekty .

Právě že nechce a právě že je to chybou, protože v okamžiku, kdy zavedete do jazyku nový koncept, počet interakcí s jinými koncepty násobně roste, takže např. v okamžiku, kdy necháte v rádobyobjektovém jazyku primitiva, musíte s nimi pracovat jinak než s objekty a ještě se vám objeví interakce primitivum-objekt a naopak!