Rust vs. C++ (funkcionální vs. OOP)

[Mirek Prýmek]

Akorát že FP je abstraktnější a málokdo chápe formální aparát za ním.

To ani není nutný. Pro běžný použití stačí znát jazyk a chápat, že primární věc jsou data a že ta data jsou neměnná.

[Reklama]

[andy]

Akorát že FP je abstraktnější a málokdo chápe formální aparát za ním.

Což ale není překážka v tom programovat. Obdivuju lidi, kteří to celé jsou schopni formálně popsat a využívat - ale vůbec není problém se na to dívat prakticky a chápat to taky.

[Mirek Prýmek]

To zní zajímavě, ale pokud podívám na dnešní vývoj, tak tomu moc zapravdu nedává. V čem myslíš, že to je?

Vývoj čeho? Programovacích jazyků? Tam právě posun tímhle směrem je.

Ale jinak vím, že kočku i psa lze drbat, ale to mě samozřejmě u abstrakce tolik nebere jako třeba to, že jsou to v podstatě stejná zvířata. Detaily můžu mít pak v každé třídě, ne? Mně to přijde úplně normální. Mám auto a taky neřešim, jestli je sešroubavané a nebo z kovu, protože mě to až tak u auta nezajímá, ne?

Tak samozřejmě máš rozhraní/protokoly, které slučují věci, které tě zajímají. Jako třeba SaveableToXml a DrawableToPng. Důležitý je, že tahle rozhraní můžeš libovolně kombinovat, aniž bys z nich musel vytvářet hierarchii.

[Radek Miček]

Rust neznám, ale třeba tohle je docela hezký článek na téma dědičnost vs. haskell nebo elm.

https://github.com/Dobiasd/articles/blob/master/from_oop_to_fp_-_inheritance_and_the_expression_problem.md

Drobná vada je, že ten článek neukazuje, jak udělat dědičnost v Haskellu. Zejména neukazuje, jak vyřešit problém s typem this (je to argument a je kovariantní - což obyčejně nejde). Dále neukazuje otevřenou rekurzi.

[andy]

Rust neznám, ale třeba tohle je docela hezký článek na téma dědičnost vs. haskell nebo elm.

https://github.com/Dobiasd/articles/blob/master/from_oop_to_fp_-_inheritance_and_the_expression_problem.md

Drobná vada je, že ten článek neukazuje, jak udělat dědičnost v Haskellu. Zejména neukazuje, jak vyřešit problém s typem this (je to argument a je kovariantní - což obyčejně nejde). Dále neukazuje otevřenou rekurzi.

Ano, ten článek totiž přesně ukazuje, že pokud se na některé problému podíváme "jinak", tak z ničeho nic "this" nepotřebujeme. Což neznamená, že nikdy "this" nepotřebujeme - potom nám fakt nic jiného než OOP třeba nezbyde - ale velmi často stačí jiný pohled a najednou fakt, že tohle v haskellu nejde, není problém (ono přes Existentials to myslím plus minus jde, ale není to moc košer).

[Reklama]

[zboj]

Akorát že FP je abstraktnější a málokdo chápe formální aparát za ním.

Což ale není překážka v tom programovat. Obdivuju lidi, kteří to celé jsou schopni formálně popsat a využívat - ale vůbec není problém se na to dívat prakticky a chápat to taky.

To většinou platí, ale je lepší chápat to do hloubky.

[Radek Miček]

Rust neznám, ale třeba tohle je docela hezký článek na téma dědičnost vs. haskell nebo elm.

https://github.com/Dobiasd/articles/blob/master/from_oop_to_fp_-_inheritance_and_the_expression_problem.md

Drobná vada je, že ten článek neukazuje, jak udělat dědičnost v Haskellu. Zejména neukazuje, jak vyřešit problém s typem this (je to argument a je kovariantní - což obyčejně nejde). Dále neukazuje otevřenou rekurzi.

Ano, ten článek totiž přesně ukazuje, že pokud se na některé problému podíváme "jinak", tak z ničeho nic "this" nepotřebujeme.

Spíš mi přijde, že si autor vybral velmi jednoduchý příklad, čímž se těmto problémům vyhnul, než že by je vyřešil. Zajímavější by bylo, kdyby potomek nějaké metody zdědil (včetně implementace) od předka a byla tam i otevřená rekurze (tj. volání abstraktní metody, která bude definována až v podtřídě).

[Inkvizitor]

Spíš mi přijde, že si autor vybral velmi jednoduchý příklad, čímž se těmto problémům vyhnul, než že by je vyřešil. Zajímavější by bylo, kdyby potomek nějaké metody zdědil (včetně implementace) od předka a byla tam i otevřená rekurze (tj. volání abstraktní metody, která bude definována až v podtřídě).

Otázka zní, proč by to měl někdo zkoušet takto naimplementovat. OOP řeší v konkrétní aplikaci nějaký konkrétní problém. Pokud chceme přepsat v nějakém jiném jazyce tu samou aplikaci, bylo by logičtější se zeptat, jaký problém daná konstrukce v původní implementaci řeší a pak hledat idiom, který ten problém řeší v tom "novém" jazyce, ne?

[andy]

Akorát že FP je abstraktnější a málokdo chápe formální aparát za ním.

Což ale není překážka v tom programovat. Obdivuju lidi, kteří to celé jsou schopni formálně popsat a využívat - ale vůbec není problém se na to dívat prakticky a chápat to taky.

To většinou platí, ale je lepší chápat to do hloubky.

Pokud nehodláš psát další Lens knihovnu nebo implementovat nějakou TypeInType extension v GHC, tak bych řek, že je to úplně jedno.

[Radek Miček]

Spíš mi přijde, že si autor vybral velmi jednoduchý příklad, čímž se těmto problémům vyhnul, než že by je vyřešil. Zajímavější by bylo, kdyby potomek nějaké metody zdědil (včetně implementace) od předka a byla tam i otevřená rekurze (tj. volání abstraktní metody, která bude definována až v podtřídě).

Otázka zní, proč by to měl někdo zkoušet takto naimplementovat.

Protože podle titulku se článek zabývá dědičností - tj. čekal bych příklad s dědičností, jenže příklad v článku žádnou dědičnost nepotřebuje (potřebuje určitou formu podtypového polymorfismu, ale ne dědičnost).

[zboj]

Akorát že FP je abstraktnější a málokdo chápe formální aparát za ním.

Což ale není překážka v tom programovat. Obdivuju lidi, kteří to celé jsou schopni formálně popsat a využívat - ale vůbec není problém se na to dívat prakticky a chápat to taky.

To většinou platí, ale je lepší chápat to do hloubky.

Pokud nehodláš psát další Lens knihovnu nebo implementovat nějakou TypeInType extension v GHC, tak bych řek, že je to úplně jedno.

Takový přístup odlišuje profíka od patlala.

[andy]

Protože podle titulku se článek zabývá dědičností - tj. čekal bych příklad s dědičností, jenže příklad v článku žádnou dědičnost nepotřebuje (potřebuje určitou formu podtypového polymorfismu, ale ne dědičnost).

Ne, podle titulku autor potřebuje implementovat nějaké UI rozhraní, které má v současné době implementované formou dědičnosti. Otázka zní, zda je dědičnost opravdu nutná pro implementaci toho, co autor potřebuje, nebo se to dá řešit nějak jinak. Konkrétně psal:

Evidentně dědičnost nějak rozumně nahradit nejde a jestli ano, tak za cenu flexibility => ve výsledku nemá cenu na něco se složitým datovým modelem používat funkcionální jazyk tohohle typu. Souhlasíte?

A moje odpověď je, že to dost záleží - dědičnost typicky není jediná možnost, jak něco implementovat, jiný pohled na problém často vede k diamtrálně jinému řešení, které vůbec nemusí být méně flexibilní. Ale je potřeba se na to podívat úplně jinak, způsoby řešení typické pro OOP jsou v FP spíše anti-pattern.

[andy]

Pokud nehodláš psát další Lens knihovnu nebo implementovat nějakou TypeInType extension v GHC, tak bych řek, že je to úplně jedno.

Takový přístup odlišuje profíka od patlala.

Hádám, že máš category theory v malíčku, viď?

[Inkvizitor]

Otázka zní, proč by to měl někdo zkoušet takto naimplementovat.

Protože podle titulku se článek zabývá dědičností - tj. čekal bych příklad s dědičností, jenže příklad v článku žádnou dědičnost nepotřebuje (potřebuje určitou formu podtypového polymorfismu, ale ne dědičnost).

Spíš se primárně zabývá "expression problemem" a vychází z C++ a jeho typicky OOP přístupu.

[Radek Miček]

Protože podle titulku se článek zabývá dědičností - tj. čekal bych příklad s dědičností, jenže příklad v článku žádnou dědičnost nepotřebuje (potřebuje určitou formu podtypového polymorfismu, ale ne dědičnost).

Ne, podle titulku autor potřebuje implementovat nějaké UI rozhraní, které má v současné době implementované formou dědičnosti. Otázka zní, zda je dědičnost opravdu nutná pro implementaci toho, co autor potřebuje, nebo se to dá řešit nějak jinak. Konkrétně psal:

Evidentně dědičnost nějak rozumně nahradit nejde a jestli ano, tak za cenu flexibility => ve výsledku nemá cenu na něco se složitým datovým modelem používat funkcionální jazyk tohohle typu. Souhlasíte?

A moje odpověď je, že to dost záleží - dědičnost typicky není jediná možnost, jak něco implementovat, jiný pohled na problém často vede k diamtrálně jinému řešení, které vůbec nemusí být méně flexibilní. Ale je potřeba se na to podívat úplně jinak, způsoby řešení typické pro OOP jsou v FP spíše anti-pattern.

Myslel jsem titulek vámi odkazovaného článku, nikoliv titulek této diskuze.