Fórum Root.cz

Hlavní témata => Vývoj => Téma založeno: bjarne 12. 03. 2016, 12:08:15

Název: Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: bjarne 12. 03. 2016, 12:08:15
Tak jsem přemýšlel, jak bych mohl svoji aplikaci v C++ přepsat do Rustu a došel jsem k závěru, že to nepůjde. Rust se mi líbí, ale ta absence OOP (třídy, dědičnost) se prostě nedá nějak normálně nahradit. Rust a podobné jazyky jsou asi skvělé pro aplikace s jednoduchým datovým modelem, ale pro složitější model, zejména když je přirozené uvažovat značně ve smyslu dědičnosti a strom dědičnosti je poměrně hluboký, tak tam nastáva u jazyků jako Rust dost problém. Pamatuju se na podobnou diskuzi, kde někdo psal, že OOP není přirozené pro naše myšlení, ale já jsem opačného názoru. Když přemýšlím nad tím, jak vytvořit abstrakci něčeho, tak přemýšlím nad chováním a nad vlastnostmi - v řeči OOP je to něco třída,  chování vyjádřeno metodami a vlastnosti pomocí datových členů.

Dám případ ze svoji aplikace:

Mám třády ApplicationElement, UIElement, GenericStack, PartStack, kdy následující třída vždy dědí z předchozí.
V C++ žádný problém, ale v Rustu bych musel vše řešit buď kompozicí nebo traity.
U kompozice bych pak musel psát něco jako partStack.genericStack.uiElement.applicationElement pokud bych chtěl volat něco z implementace ApplicationElement a traitu je zase šílenost pro každou strukturu imlementovat všechny ty traity.

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?


Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: uetoyo 12. 03. 2016, 13:37:07
Přečti si něco o FP: http://bartoszmilewski.com/
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: zboj 12. 03. 2016, 14:20:35
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?
Nahradit nejde, ale s flexibilitou to nijak nesouvisí. Lepší je používat protokoly a je implementující třídy nebo struktury (podobně jako v Go nebo Swiftu). Rust podrobně neznám, tak nevím, nakolik umožňuje podobné paradigma.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: Radek Miček 12. 03. 2016, 14:51:21
když je přirozené uvažovat značně ve smyslu dědičnosti a strom dědičnosti je poměrně hluboký, tak tam nastáva u jazyků jako Rust dost problém.

Ano, absence dědičnosti nebo podobného mechanismu je problém.

Před 18 dny bylo nicméně přijato RFC: impl specialization #1210 (https://github.com/rust-lang/rfcs/pull/1210), jenž tento problém pomůže vyřešit (http://aturon.github.io/blog/2015/09/18/reuse/).
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: G 12. 03. 2016, 15:02:10
Do rust jazyka bych nic neprepisoval, prvni stabilni verze se objevila v teprve v minulem roce a nezda se ze si je autor jisty co vlastne chce. Je velke riziko, ze se jazyk bude jeste menit a tvoje otazky chapu. Neni to zkratka domyslene ...

Na druhou stranu c++ neni oop jazyk, je implementovana pouze omezena podmnozina oop. Treba clos v common lispu je mnohem silnejsi ... oop podle me nesouvisi jestli je jazyk imperativni nebo funkcionalni.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: Radek Miček 12. 03. 2016, 16:14:52
Citace
Je velke riziko, ze se jazyk bude jeste menit a tvoje otazky chapu. Neni to zkratka domyslene ...

Většina nových verzí obsahuje zpětně nekompatibilní změny.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: tomaszav 13. 03. 2016, 09:41:18
Dedicnost je zlo. Vetsina pouziti vychazi z toho ze se ti tsk nekdo proste naucil.

Pokud nekdo podedi vic nez jednou, mel by se nad sebou vazne zamyslet.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: bjarne 13. 03. 2016, 10:34:08
Dedicnost je zlo. Vetsina pouziti vychazi z toho ze se ti tsk nekdo proste naucil.

Pokud nekdo podedi vic nez jednou, mel by se nad sebou vazne zamyslet.

To je pěkná kravina.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: bjarne 13. 03. 2016, 10:34:33
když je přirozené uvažovat značně ve smyslu dědičnosti a strom dědičnosti je poměrně hluboký, tak tam nastáva u jazyků jako Rust dost problém.

Ano, absence dědičnosti nebo podobného mechanismu je problém.

Před 18 dny bylo nicméně přijato RFC: impl specialization #1210 (https://github.com/rust-lang/rfcs/pull/1210), jenž tento problém pomůže vyřešit (http://aturon.github.io/blog/2015/09/18/reuse/).

super, kouknu na to, díky
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: pavlix 13. 03. 2016, 11:33:42
Rust neumím. Ale píšu dost věcí v céčku a když se bavám s vývojáři, co používají C++, tak mi přijde, že mají tendenci jeho vlastnosti přeceňovat. Céčko je maximálně flexibilní a udělá se v něm cokoliv, na co je v C++ syntaktický cukr, i na co není. Předpokládám, že to v Rustu půjde zrovnatak, ale není mi úplně jasné, co všechno půjde dělat bezpečným způsobem. Takže bude potřeba neporovnávat schopnosti jazyků, ale spíše vlastnosti best practices těch jazyků. Další věc je, že mnozí céčkaři zvládají normálně psát kód a přitom udržovat kompatibilitu API/ABI, zatímco v C++ nevím o nikom, kdo by vůbec vědě, jak se to dělá. Taky v C++ projektech (například squid) narážím na velmi kryptické chyby týkající se volání destruktorů.

http://www.abclinuxu.cz/blog/pavlix/2016/2/abi-kompatibilita
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: bjarne 13. 03. 2016, 12:25:19
Rust neumím. Ale píšu dost věcí v céčku a když se bavám s vývojáři, co používají C++, tak mi přijde, že mají tendenci jeho vlastnosti přeceňovat. Céčko je maximálně flexibilní a udělá se v něm cokoliv, na co je v C++ syntaktický cukr, i na co není. Předpokládám, že to v Rustu půjde zrovnatak, ale není mi úplně jasné, co všechno půjde dělat bezpečným způsobem. Takže bude potřeba neporovnávat schopnosti jazyků, ale spíše vlastnosti best practices těch jazyků. Další věc je, že mnozí céčkaři zvládají normálně psát kód a přitom udržovat kompatibilitu API/ABI, zatímco v C++ nevím o nikom, kdo by vůbec vědě, jak se to dělá. Taky v C++ projektech (například squid) narážím na velmi kryptické chyby týkající se volání destruktorů.

http://www.abclinuxu.cz/blog/pavlix/2016/2/abi-kompatibilita

Jo tak v C++ je těch problému s ABI kompatibilitou daleko víc a je to hlavně kvůli virtuálním metodám. Např. přidám novou virtuální metodu do rodičovské třídy a už jsem v zadeli, protože se mi změní indexy virtuálních metod v TVM.
Taková funny věc v C++ je třeba to, že když člověk volá virtuální metodu v konstruktoru, tak to může, ale i nemusí fungovat, podle toho jestli už je nastaven správný ukazatel na TVM. Kvůli takovým věcem by se vyplatilo switchnout na jiný jazyk kompilovaný do nativního kódu a nemající GC (v podstatě asi jediná možnost je právě Rust).
Já mám ale problém s tím, za jakou cenu budu nahrazovat tu dědičnost pomocí jiných vlastností nějakého jazyka. Řekl bych, že je tady prostor pro jazyk typu něco mezi C++ a Rustem.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: javaman 13. 03. 2016, 12:40:44
Přesně tak, je čas na Javu.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: bjarne 13. 03. 2016, 13:41:43
Přesně tak, je čas na Javu.

Klidně, jen kdyby tam nebyl GC a overhead s voláním C funkcí. Jazyk jako takový se mi líbí.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: fedorac 13. 03. 2016, 13:44:04
uz je nove tisicileti.
Golang
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: Radek Miček 13. 03. 2016, 13:59:35
uz je nove tisicileti.
Golang

Go nemá generika (nebo šablony) - patří spíše do minulého tisíciletí. V tomto ohledu bylo C++ dál než Go už v roce 1990.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: Kit 13. 03. 2016, 14:26:45
Mám třády ApplicationElement, UIElement, GenericStack, PartStack, kdy následující třída vždy dědí z předchozí.

Nejsem si jist, zda je te dědičnost uvělána správně. UIElement může být speciálním případem ApplicationElement, ale GenericStack určitě není specializací UIElement. Spíš bych se odvážil tvrdit, že UIElement bude komponentou GenericStack.

Tedy v případě vztahu GenericStack a UIElement nemá být použita dědičnost, ale kompozice.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: javaman 13. 03. 2016, 14:43:41
Přesně tak, je čas na Javu.

Klidně, jen kdyby tam nebyl GC a overhead s voláním C funkcí. Jazyk jako takový se mi líbí.

Můžeš si ho vypnout :D Ale jinak GC je asi nejlepší.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: hawran diskuse 13. 03. 2016, 15:06:07
...Taková funny věc v C++ je třeba to, že když člověk volá virtuální metodu v konstruktoru, tak to může, ale i nemusí fungovat, podle toho jestli už je nastaven správný ukazatel na TVM. ...

Já jsem to věděl, že si to ještě pamatuju:
https://isocpp.org/wiki/faq/strange-inheritance#calling-virtuals-from-ctors (https://isocpp.org/wiki/faq/strange-inheritance#calling-virtuals-from-ctors)
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: bjarne 13. 03. 2016, 15:12:22
Mám třády ApplicationElement, UIElement, GenericStack, PartStack, kdy následující třída vždy dědí z předchozí.

Nejsem si jist, zda je te dědičnost uvělána správně. UIElement může být speciálním případem ApplicationElement, ale GenericStack určitě není specializací UIElement. Spíš bych se odvážil tvrdit, že UIElement bude komponentou GenericStack.

Tedy v případě vztahu GenericStack a UIElement nemá být použita dědičnost, ale kompozice.

GenericStack je genericka abstraktni trida dedici z UIElement a slouzici jako predek pro vsechny UIElementy, ktere obsahuji dalsi UIElementy, ale vzdy zobrazuji v dany cas jen jeden a nejakou navigaci pro aktivaci tech ostatnich. Jsem presvedcen, ze takhle je to navrzene spravne.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: uetoyo 13. 03. 2016, 15:19:47
Bez pohledu do zdrojáku se dá těžko rozhodnout, jestli je ta hierarchie správně, ale podmenované to je divně.
`UIElement <-- GenericStack`?

Citace
There are only two hard things in Computer Science: cache invalidation and naming things.
-- Phil Karlton
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: bjarne 13. 03. 2016, 15:22:15
...Taková funny věc v C++ je třeba to, že když člověk volá virtuální metodu v konstruktoru, tak to může, ale i nemusí fungovat, podle toho jestli už je nastaven správný ukazatel na TVM. ...

Já jsem to věděl, že si to ještě pamatuju:
https://isocpp.org/wiki/faq/strange-inheritance#calling-virtuals-from-ctors (https://isocpp.org/wiki/faq/strange-inheritance#calling-virtuals-from-ctors)

Jj ono to dava smysl, ze to nejde. Tenhle problem je v podstate ve vsech jazycich, kde je ten koncept konstruktorů a virtualnich metod, takze treba i v Jave. Vlastne jsem na to jednou v Jave narazil, tam se totiz ta virtualni metoda potomka zavola, ale proste datove cleny potomku, u kterych jeste nebyl vyvolan konstruktor, jsou inicializovane na svoje defaultni hodnoty. Tenkrat jsem se tim pekne strelil do haksny.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: bjarne 13. 03. 2016, 15:29:49
Bez pohledu do zdrojáku se dá těžko rozhodnout, jestli je ta hierarchie správně, ale podmenované to je divně.
`UIElement <-- GenericStack`?

Citace
There are only two hard things in Computer Science: cache invalidation and naming things.
-- Phil Karlton

A co je na tom divného, že třída GenericStack dědí ze třídy UIElement? To nějak nechápu, co vadí. GenericStack je UIElement.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: uetoyo 13. 03. 2016, 15:41:08
Můžeš se hádat s Kitem (a on se bude hádat .), jestli to má být dědičnost nebo kompozice, ale bez pohledu do zdrojáku se hůře argumentuje. Jinak GenericStack mi evokuje datovou strukturu, neříkám, že to nemůže být nějaký UI element/kontejner, ale je to matoucí (osobní názor).
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: zboj 13. 03. 2016, 15:55:38
Rust neumím. Ale píšu dost věcí v céčku a když se bavám s vývojáři, co používají C++, tak mi přijde, že mají tendenci jeho vlastnosti přeceňovat. Céčko je maximálně flexibilní a udělá se v něm cokoliv, na co je v C++ syntaktický cukr, i na co není. Předpokládám, že to v Rustu půjde zrovnatak, ale není mi úplně jasné, co všechno půjde dělat bezpečným způsobem. Takže bude potřeba neporovnávat schopnosti jazyků, ale spíše vlastnosti best practices těch jazyků. Další věc je, že mnozí céčkaři zvládají normálně psát kód a přitom udržovat kompatibilitu API/ABI, zatímco v C++ nevím o nikom, kdo by vůbec vědě, jak se to dělá. Taky v C++ projektech (například squid) narážím na velmi kryptické chyby týkající se volání destruktorů.

http://www.abclinuxu.cz/blog/pavlix/2016/2/abi-kompatibilita

Jo tak v C++ je těch problému s ABI kompatibilitou daleko víc a je to hlavně kvůli virtuálním metodám. Např. přidám novou virtuální metodu do rodičovské třídy a už jsem v zadeli, protože se mi změní indexy virtuálních metod v TVM.
Taková funny věc v C++ je třeba to, že když člověk volá virtuální metodu v konstruktoru, tak to může, ale i nemusí fungovat, podle toho jestli už je nastaven správný ukazatel na TVM. Kvůli takovým věcem by se vyplatilo switchnout na jiný jazyk kompilovaný do nativního kódu a nemající GC (v podstatě asi jediná možnost je právě Rust).
Já mám ale problém s tím, za jakou cenu budu nahrazovat tu dědičnost pomocí jiných vlastností nějakého jazyka. Řekl bych, že je tady prostor pro jazyk typu něco mezi C++ a Rustem.
Druhá možnost je Swift, má dědičnost a nemá GC. Nicméně stabilní ABI plánují až od verze 3 (teď je na Linuxu aktuální 2.2).
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: Radek Miček 13. 03. 2016, 15:58:49
GenericStack mi evokuje datovou strukturu, neříkám, že to nemůže být nějaký UI element/kontejner, ale je to matoucí (osobní názor).

IMO Stack je celkem normální název pro UI elementy - viz třeba GtkStack (https://developer.gnome.org/gtk3/stable/GtkStack.html), QStackedLayout (http://doc.qt.io/qt-4.8/qstackedlayout.html) případně WPF StackPanel (https://msdn.microsoft.com/en-us/library/system.windows.controls.stackpanel%28v=vs.110%29.aspx).
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: uetoyo 13. 03. 2016, 16:06:44
Už mi svitlo.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: Radek Miček 13. 03. 2016, 16:15:03
Rust neumím. Ale píšu dost věcí v céčku a když se bavám s vývojáři, co používají C++, tak mi přijde, že mají tendenci jeho vlastnosti přeceňovat. Céčko je maximálně flexibilní a udělá se v něm cokoliv, na co je v C++ syntaktický cukr, i na co není. Předpokládám, že to v Rustu půjde zrovnatak, ale není mi úplně jasné, co všechno půjde dělat bezpečným způsobem. Takže bude potřeba neporovnávat schopnosti jazyků, ale spíše vlastnosti best practices těch jazyků. Další věc je, že mnozí céčkaři zvládají normálně psát kód a přitom udržovat kompatibilitu API/ABI, zatímco v C++ nevím o nikom, kdo by vůbec vědě, jak se to dělá. Taky v C++ projektech (například squid) narážím na velmi kryptické chyby týkající se volání destruktorů.

http://www.abclinuxu.cz/blog/pavlix/2016/2/abi-kompatibilita

Jo tak v C++ je těch problému s ABI kompatibilitou daleko víc a je to hlavně kvůli virtuálním metodám. Např. přidám novou virtuální metodu do rodičovské třídy a už jsem v zadeli, protože se mi změní indexy virtuálních metod v TVM.
Taková funny věc v C++ je třeba to, že když člověk volá virtuální metodu v konstruktoru, tak to může, ale i nemusí fungovat, podle toho jestli už je nastaven správný ukazatel na TVM. Kvůli takovým věcem by se vyplatilo switchnout na jiný jazyk kompilovaný do nativního kódu a nemající GC (v podstatě asi jediná možnost je právě Rust).
Já mám ale problém s tím, za jakou cenu budu nahrazovat tu dědičnost pomocí jiných vlastností nějakého jazyka. Řekl bych, že je tady prostor pro jazyk typu něco mezi C++ a Rustem.
Druhá možnost je Swift, má dědičnost a nemá GC. Nicméně stabilní ABI plánují až od verze 3 (teď je na Linuxu aktuální 2.2).

Jaká je situace s knihovnami a vývojovými prostředími na Linuxu? Případně na Windows?
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: zboj 13. 03. 2016, 16:20:46
Rust neumím. Ale píšu dost věcí v céčku a když se bavám s vývojáři, co používají C++, tak mi přijde, že mají tendenci jeho vlastnosti přeceňovat. Céčko je maximálně flexibilní a udělá se v něm cokoliv, na co je v C++ syntaktický cukr, i na co není. Předpokládám, že to v Rustu půjde zrovnatak, ale není mi úplně jasné, co všechno půjde dělat bezpečným způsobem. Takže bude potřeba neporovnávat schopnosti jazyků, ale spíše vlastnosti best practices těch jazyků. Další věc je, že mnozí céčkaři zvládají normálně psát kód a přitom udržovat kompatibilitu API/ABI, zatímco v C++ nevím o nikom, kdo by vůbec vědě, jak se to dělá. Taky v C++ projektech (například squid) narážím na velmi kryptické chyby týkající se volání destruktorů.

http://www.abclinuxu.cz/blog/pavlix/2016/2/abi-kompatibilita

Jo tak v C++ je těch problému s ABI kompatibilitou daleko víc a je to hlavně kvůli virtuálním metodám. Např. přidám novou virtuální metodu do rodičovské třídy a už jsem v zadeli, protože se mi změní indexy virtuálních metod v TVM.
Taková funny věc v C++ je třeba to, že když člověk volá virtuální metodu v konstruktoru, tak to může, ale i nemusí fungovat, podle toho jestli už je nastaven správný ukazatel na TVM. Kvůli takovým věcem by se vyplatilo switchnout na jiný jazyk kompilovaný do nativního kódu a nemající GC (v podstatě asi jediná možnost je právě Rust).
Já mám ale problém s tím, za jakou cenu budu nahrazovat tu dědičnost pomocí jiných vlastností nějakého jazyka. Řekl bych, že je tady prostor pro jazyk typu něco mezi C++ a Rustem.
Druhá možnost je Swift, má dědičnost a nemá GC. Nicméně stabilní ABI plánují až od verze 3 (teď je na Linuxu aktuální 2.2).

Jaká je situace s knihovnami a vývojovými prostředími na Linuxu? Případně na Windows?
Swift může přímo volat kód (knihovny) v C (podobně jako Go), takže stačí dynamicky linkovat. IDE nepoužívám, tak nevím, vi to jistí.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: Radek Miček 13. 03. 2016, 16:25:54
Rust neumím. Ale píšu dost věcí v céčku a když se bavám s vývojáři, co používají C++, tak mi přijde, že mají tendenci jeho vlastnosti přeceňovat. Céčko je maximálně flexibilní a udělá se v něm cokoliv, na co je v C++ syntaktický cukr, i na co není. Předpokládám, že to v Rustu půjde zrovnatak, ale není mi úplně jasné, co všechno půjde dělat bezpečným způsobem. Takže bude potřeba neporovnávat schopnosti jazyků, ale spíše vlastnosti best practices těch jazyků. Další věc je, že mnozí céčkaři zvládají normálně psát kód a přitom udržovat kompatibilitu API/ABI, zatímco v C++ nevím o nikom, kdo by vůbec vědě, jak se to dělá. Taky v C++ projektech (například squid) narážím na velmi kryptické chyby týkající se volání destruktorů.

http://www.abclinuxu.cz/blog/pavlix/2016/2/abi-kompatibilita

Jo tak v C++ je těch problému s ABI kompatibilitou daleko víc a je to hlavně kvůli virtuálním metodám. Např. přidám novou virtuální metodu do rodičovské třídy a už jsem v zadeli, protože se mi změní indexy virtuálních metod v TVM.
Taková funny věc v C++ je třeba to, že když člověk volá virtuální metodu v konstruktoru, tak to může, ale i nemusí fungovat, podle toho jestli už je nastaven správný ukazatel na TVM. Kvůli takovým věcem by se vyplatilo switchnout na jiný jazyk kompilovaný do nativního kódu a nemající GC (v podstatě asi jediná možnost je právě Rust).
Já mám ale problém s tím, za jakou cenu budu nahrazovat tu dědičnost pomocí jiných vlastností nějakého jazyka. Řekl bych, že je tady prostor pro jazyk typu něco mezi C++ a Rustem.
Druhá možnost je Swift, má dědičnost a nemá GC. Nicméně stabilní ABI plánují až od verze 3 (teď je na Linuxu aktuální 2.2).

Jaká je situace s knihovnami a vývojovými prostředími na Linuxu? Případně na Windows?
Swift může přímo volat kód (knihovny) v C (podobně jako Go), takže stačí dynamicky linkovat. IDE nepoužívám, tak nevím, vi to jistí.

Díky. Spíše jsem ale myslel, jaké knihovny bude Apple portovat na tyto platformy?
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: zboj 13. 03. 2016, 16:32:37
Rust neumím. Ale píšu dost věcí v céčku a když se bavám s vývojáři, co používají C++, tak mi přijde, že mají tendenci jeho vlastnosti přeceňovat. Céčko je maximálně flexibilní a udělá se v něm cokoliv, na co je v C++ syntaktický cukr, i na co není. Předpokládám, že to v Rustu půjde zrovnatak, ale není mi úplně jasné, co všechno půjde dělat bezpečným způsobem. Takže bude potřeba neporovnávat schopnosti jazyků, ale spíše vlastnosti best practices těch jazyků. Další věc je, že mnozí céčkaři zvládají normálně psát kód a přitom udržovat kompatibilitu API/ABI, zatímco v C++ nevím o nikom, kdo by vůbec vědě, jak se to dělá. Taky v C++ projektech (například squid) narážím na velmi kryptické chyby týkající se volání destruktorů.

http://www.abclinuxu.cz/blog/pavlix/2016/2/abi-kompatibilita

Jo tak v C++ je těch problému s ABI kompatibilitou daleko víc a je to hlavně kvůli virtuálním metodám. Např. přidám novou virtuální metodu do rodičovské třídy a už jsem v zadeli, protože se mi změní indexy virtuálních metod v TVM.
Taková funny věc v C++ je třeba to, že když člověk volá virtuální metodu v konstruktoru, tak to může, ale i nemusí fungovat, podle toho jestli už je nastaven správný ukazatel na TVM. Kvůli takovým věcem by se vyplatilo switchnout na jiný jazyk kompilovaný do nativního kódu a nemající GC (v podstatě asi jediná možnost je právě Rust).
Já mám ale problém s tím, za jakou cenu budu nahrazovat tu dědičnost pomocí jiných vlastností nějakého jazyka. Řekl bych, že je tady prostor pro jazyk typu něco mezi C++ a Rustem.
Druhá možnost je Swift, má dědičnost a nemá GC. Nicméně stabilní ABI plánují až od verze 3 (teď je na Linuxu aktuální 2.2).

Jaká je situace s knihovnami a vývojovými prostředími na Linuxu? Případně na Windows?
Swift může přímo volat kód (knihovny) v C (podobně jako Go), takže stačí dynamicky linkovat. IDE nepoužívám, tak nevím, vi to jistí.

Díky. Spíše jsem ale myslel, jaké knihovny bude Apple portovat na tyto platformy?
Swift má svou "standard library" a Apple portuje na Linux Foundation (přepisuje ji z ObjC, ale ještě tam pár věci chybí, myslím, že cíl je mít úplný port v 3.0).
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: vim 13. 03. 2016, 16:49:36
IDE nepoužívám, tak nevím, vi to jistí.

To myslíš vážně? Kite, vidíš to? Doufám, že nevyvíjíš i něco pro zákazníky, protože to bych jim nepřál :D
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: Rejpal 13. 03. 2016, 16:57:51
Tak ono to prý některým opravdu stačí. Mně to vždycky zní, jako kdyby někdo jezdil na koloběžce, protože na co motorka, vždyť jemu to takhle stačí. Ale když jim to tak vyhovuje, tak proč jim do toho kecat, hlavně že to tak nemusím dělat já. 8)
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: Kit 13. 03. 2016, 17:08:44
IDE nepoužívám, tak nevím, vi to jistí.

To myslíš vážně? Kite, vidíš to? Doufám, že nevyvíjíš i něco pro zákazníky, protože to bych jim nepřál :D

No a? Myslel sis snad, že jsem jediný, kdo vyvíví i pro zákazníky ve Vimu? Mám v něm vše potřebné - tak jak obyčejní vývojáři ve svém IDE.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: vim 13. 03. 2016, 17:28:50
Myslel jsem, že není tolik patlalů na jednom fóru. Viděl jsem už hodně, takže jsem zvyklý. Ale Vim je taková stálice. Plus ještě Python jako dobrý jazyk na velké věci :D
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: čumil 13. 03. 2016, 17:36:15
Rust a funkcionální ? EEHE? Nejblíž FP je dneska Haskell a Elm. A mimochodem, když ti chybí dědičnost, tak asi ani nechápeš o čem je FP a neměl by ses do něj srát. Každé paradigma má vlastní způsoby řešení problémů. FP a OOP jsou opravdu ale opravdu diametrálně odlišné. A ne na vše se hodí, někde je FP nejlepší volba a jindy je zas FP na skok z okna.

BTW, u nás v práci jsou lidi který používaj VIM k vývoji ... já mezi ně nepatřím, ale to je otázka preferencí
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: čumil 13. 03. 2016, 17:38:30
A k tomu pythonu. Je to sračka jazyk ale budeš se divit, jsou v něm velký projekty. A jsou stejně nečitelný jako v jakémkoli jiném jazyku, jen takovej rejp pro vzývače hada.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: vim 13. 03. 2016, 17:45:43
Divit se nebudu, protože jsem je viděl a bylo to tak na vyhození. Jenže dneska je to moderní. Přijdeš do cool startupu, tam jsou děti a milují Python. Když jim řekneš, že je to sračka, tak se budou divně dívat a nebude tě mít moc rádi :D Nejsou stejně nečitelný jako u jiných. Ukaž mi nějaký refactoring u projektu nad milion řádků ve Vimu. Jak ho budeš mít hotový, tak bych moc rád viděl debug složitějšího problému :D
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: blub 13. 03. 2016, 18:29:17
jestli on neni for prave v tom, ze v Pythonu nepotrebujes milion radku na velkej projekt ;)
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: vim 13. 03. 2016, 18:38:57
:D Taky známé. V Pythonu jsou totiž i ty největší bankovní aplikace na 150 řádcích :D Pak si dovedu představit ten Vim i refactoring.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: pavlix 13. 03. 2016, 18:49:48
Při troše sebezapření by mi asi nějaké to IDE stačilo, ale proč se trápit, když můžu psát normálně ve vimu.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: vim 13. 03. 2016, 18:52:07
Psát tam jde parádně, ale s programováním je to horší.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: andy 13. 03. 2016, 20:03:41
Mám třády ApplicationElement, UIElement, GenericStack, PartStack, kdy následující třída vždy dědí z předchozí.
V C++ žádný problém, ale v Rustu bych musel vše řešit buď kompozicí nebo traity.
U kompozice bych pak musel psát něco jako partStack.genericStack.uiElement.applicationElement pokud bych chtěl volat něco z implementace ApplicationElement a traitu je zase šílenost pro každou strukturu imlementovat všechny ty traity.

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?
Pokud chceš používat FP, musíš se na problém "podívat jinak".  Často tě pak ten jiný pohled zavede směrem, kdy máš pocit, že dědičnost vůbec nepotřebuješ. Docela často nejde třeba o dědičnost, ale spíše o "Interface", a to už se dá implementovat docela jednoduše. 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
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: Mirek Prýmek 13. 03. 2016, 20:10:06
Pamatuju se na podobnou diskuzi, kde někdo psal, že OOP není přirozené pro naše myšlení, ale já jsem opačného názoru. Když přemýšlím nad tím, jak vytvořit abstrakci něčeho, tak přemýšlím nad chováním a nad vlastnostmi - v řeči OOP je to něco třída,  chování vyjádřeno metodami a vlastnosti pomocí datových členů.
To jsem byl možná já. Jo, nad chováním a nad vlastnostmi přemýšlíš, ale vytvářet z nich hierarchie je spíš záležitost školní než něco z reálného života. Víš, že psa i kočku můžeš drbat, ale nevytváříš si nějaký mentální model abstraktní skupiny Drbable :)

A pokud s nějakými vlastnostmi pracujeme jako s konstituenty nějakých množin, tak z nich nevytváříme hierarchie. Spíš vnímáme, že určité úplně rozdílné (nesouvisející) věci mají nějaké společné vlastnosti, jako třeba že ta věc je sešroubovaná šroubky, takže se dá otevřít pomocí šroubováku. A zároveň máš úplně jinou množinu věcí, které jsou třeba kovové. Obě vlastnosti konstituují nějakou abstraktní množinu (Šroubable a RedThings), ale nevytvářejí žádnou hierarchii a ani tu hierarchii nemůžeš vytvořit i kdybys chtěl.

Proto si myslím, že je daleko přirozenější pracovat s volně kombinovatelnými rozhraními/protokoly než s hierarchiemi tříd. Jediné, kde se s hierarchiemi extenzivně pracuje, je biologie: strunatci => savci => ... V normálním životě se to ale obvykle nedělá.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: zboj 13. 03. 2016, 20:15:48
Mám třády ApplicationElement, UIElement, GenericStack, PartStack, kdy následující třída vždy dědí z předchozí.
V C++ žádný problém, ale v Rustu bych musel vše řešit buď kompozicí nebo traity.
U kompozice bych pak musel psát něco jako partStack.genericStack.uiElement.applicationElement pokud bych chtěl volat něco z implementace ApplicationElement a traitu je zase šílenost pro každou strukturu imlementovat všechny ty traity.

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?
Pokud chceš používat FP, musíš se na problém "podívat jinak".  Často tě pak ten jiný pohled zavede směrem, kdy máš pocit, že dědičnost vůbec nepotřebuješ. Docela často nejde třeba o dědičnost, ale spíše o "Interface", a to už se dá implementovat docela jednoduše. 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
Akorát že FP je abstraktnější a málokdo chápe formální aparát za ním.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: vim 13. 03. 2016, 20:19:40

To jsem byl možná já.

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?

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?

Ten tvůj pohled se mi líbí, ale nemyslím, že je to až tak reálné. Nemáš nějaký lepší příklad?
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: Mirek Prýmek 13. 03. 2016, 20:20:49
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á.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: andy 13. 03. 2016, 20:23:19
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.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: Mirek Prýmek 13. 03. 2016, 20:24:52
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.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: Radek Miček 13. 03. 2016, 20:31:14
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.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: andy 13. 03. 2016, 20:42:18
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).
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: zboj 13. 03. 2016, 21:16:19
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.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: Radek Miček 13. 03. 2016, 21:42:16
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ě).
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: Inkvizitor 13. 03. 2016, 22:23:40
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?
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: andy 13. 03. 2016, 22:27:39
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.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: Radek Miček 13. 03. 2016, 22:53:49
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).
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: zboj 13. 03. 2016, 23:06:17
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.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: andy 13. 03. 2016, 23:44:18

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:
Citace
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.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: andy 13. 03. 2016, 23:48:41
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ď?
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: Inkvizitor 13. 03. 2016, 23:55:21
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.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: Radek Miček 14. 03. 2016, 00:08:59

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:
Citace
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.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: Radek Miček 14. 03. 2016, 00:11:31
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.

Pak je ovšem otázkou, k čemu je článek tazateli užitečný, když se dědičností nezabývá (a proč ji má ve svém názvu).
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: andy 14. 03. 2016, 00:36:04
Myslel jsem titulek vámi odkazovaného článku, nikoliv titulek této diskuze.
Tak nějak od začátku tadu píšu, že mnoho problémů, které se v OOP řeší dědičností, lze řešit jinak, a v FP je vhodné je řešit jinak. Odkážu na článek, který názorně ukazuje jeden z takových případů. A vy si stěžujete, že na to dědičnost nebyla potřeba. Správně, nebyla. Proto jsem na ten článek odkazoval, kromě toho, že mi to na první pohled přišlo vcelku blízké tomu, co psal autor diskuze. Teď jen nechápu, co vlastně chcete říct?
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: Viky 14. 03. 2016, 01:50:41

A jéje. Zas jeden co si o sobě myslí, že je mistr světa a všechno ví a umí líp. A přitom podle toho, jak se projevuje, je zřejmé, že ještě ani neví, co všechno neví, a polovinu toho co ví, ví blbě. Ale známe takových dost. Přesně kvůli takovým vzniklo rčení "mluviti stříbro, mlčeti zlato".
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: Radek Miček 14. 03. 2016, 07:05:06
Myslel jsem titulek vámi odkazovaného článku, nikoliv titulek této diskuze.
Tak nějak od začátku tadu píšu, že mnoho problémů, které se v OOP řeší dědičností, lze řešit jinak, a v FP je vhodné je řešit jinak. Odkážu na článek, který názorně ukazuje jeden z takových případů.

Stěžuji si, že článek žádný takový případ neukazuje. Kód v C++, který autor převádí do Haskellu, dědičnost nepoužívá - článek tedy neukazuje, jak se problém, který se v OOP řeší dědičností, vyřeší v FP jinak.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: andy 14. 03. 2016, 07:11:18

Stěžuji si, že článek žádný takový případ neukazuje. Kód v C++, který autor převádí do Haskellu, dědičnost nepoužívá - článek tedy neukazuje, jak se problém, který se v OOP řeší dědičností, vyřeší v FP jinak.

Kód: [Vybrat]
class Base
{
    public:
        virtual ~Base() {}
        virtual void step(int delta) = 0;
        virtual std::string display() const = 0;
};
class Foo : public Base
{
    public:
        Foo(const int i) : intVal_(i) {}
        // Add delta to internal state.
        void step(int delta) override { intVal_ += delta; }
        std::string display() const override { return std::to_string(intVal_); }
    private:
        int intVal_;
};
To myslíte vážně?
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: Radek Miček 14. 03. 2016, 07:23:57

Stěžuji si, že článek žádný takový případ neukazuje. Kód v C++, který autor převádí do Haskellu, dědičnost nepoužívá - článek tedy neukazuje, jak se problém, který se v OOP řeší dědičností, vyřeší v FP jinak.

Kód: [Vybrat]
class Base
{
    public:
        virtual ~Base() {}
        virtual void step(int delta) = 0;
        virtual std::string display() const = 0;
};
class Foo : public Base
{
    public:
        Foo(const int i) : intVal_(i) {}
        // Add delta to internal state.
        void step(int delta) override { intVal_ += delta; }
        std::string display() const override { return std::to_string(intVal_); }
    private:
        int intVal_;
};
To myslíte vážně?

Ano. Od Base se nedědí vůbec nic. V příkladu jde jen o to, aby ukazatele (reference) na Foo šlo bezpečně použít tam, kde jsou očekávány ukazatele (reference) na Base - jde jen o podtypový polymorfismus - dědičnost je něco jiného.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: andy 14. 03. 2016, 07:50:13
Ano. Od Base se nedědí vůbec nic. V příkladu jde jen o to, aby ukazatele (reference) na Foo šlo bezpečně použít tam, kde jsou očekávány ukazatele (reference) na Base - jde jen o podtypový polymorfismus - dědičnost je něco jiného.
Mě to teda připadá jako typový polymorfismus, který se v C++ řeší dědičností. Vám ne?
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: zboj 14. 03. 2016, 10:56:27
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ď?
Mám.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: andy 14. 03. 2016, 12:58:54
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ď?
Mám.
Supr. Takže mi zajisté vysvětlíš, které části category theory (oproti tomu, co ví člověk po studiu standardních knížek o haskellu) potřebuješ třeba na implementaci tohoto: https://hackage.haskell.org/package/aeson , případně, proč je toto konkrétně práce patlala, pokud budeš mít pocit, že je (a možná i oprávněně, protože autor se tváří, že zrovna teorií moc neoplývá), a jak bys to udělal nějak výrazně lépe a hlavně, jak by ti při tom pomohla znalost category theory.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: uetoyo 14. 03. 2016, 16:48:21

Stěžuji si, že článek žádný takový případ neukazuje. Kód v C++, který autor převádí do Haskellu, dědičnost nepoužívá - článek tedy neukazuje, jak se problém, který se v OOP řeší dědičností, vyřeší v FP jinak.

Kód: [Vybrat]
class Base
{
    public:
        virtual ~Base() {}
        virtual void step(int delta) = 0;
        virtual std::string display() const = 0;
};
class Foo : public Base
{
    public:
        Foo(const int i) : intVal_(i) {}
        // Add delta to internal state.
        void step(int delta) override { intVal_ += delta; }
        std::string display() const override { return std::to_string(intVal_); }
    private:
        int intVal_;
};
To myslíte vážně?

Ano. Od Base se nedědí vůbec nic. V příkladu jde jen o to, aby ukazatele (reference) na Foo šlo bezpečně použít tam, kde jsou očekávány ukazatele (reference) na Base - jde jen o podtypový polymorfismus - dědičnost je něco jiného.

Jak je to tedy přesne s tím (pod)typovým polymorfismes v C++; tedy není implementován dědičností? Děkuji.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: zboj 14. 03. 2016, 17:20:40

Stěžuji si, že článek žádný takový případ neukazuje. Kód v C++, který autor převádí do Haskellu, dědičnost nepoužívá - článek tedy neukazuje, jak se problém, který se v OOP řeší dědičností, vyřeší v FP jinak.

Kód: [Vybrat]
class Base
{
    public:
        virtual ~Base() {}
        virtual void step(int delta) = 0;
        virtual std::string display() const = 0;
};
class Foo : public Base
{
    public:
        Foo(const int i) : intVal_(i) {}
        // Add delta to internal state.
        void step(int delta) override { intVal_ += delta; }
        std::string display() const override { return std::to_string(intVal_); }
    private:
        int intVal_;
};
To myslíte vážně?

Ano. Od Base se nedědí vůbec nic. V příkladu jde jen o to, aby ukazatele (reference) na Foo šlo bezpečně použít tam, kde jsou očekávány ukazatele (reference) na Base - jde jen o podtypový polymorfismus - dědičnost je něco jiného.

Jak je to tedy přesne s tím (pod)typovým polymorfismes v C++; tedy není implementován dědičností? Děkuji.
Když Base nemá vlastnosti a všechny metody jsou virtuální, tak se nic nedědí a jde vlastně o rozhraní/protokol (jež C++ explicitně nemá).
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: Mirek Prýmek 14. 03. 2016, 17:33:18
Supr. Takže mi zajisté vysvětlíš, které části category theory (oproti tomu, co ví člověk po studiu standardních knížek o haskellu) potřebuješ třeba na implementaci tohoto: https://hackage.haskell.org/package/aeson , případně, proč je toto konkrétně práce patlala, pokud budeš mít pocit, že je (a možná i oprávněně, protože autor se tváří, že zrovna teorií moc neoplývá), a jak bys to udělal nějak výrazně lépe a hlavně, jak by ti při tom pomohla znalost category theory.
To je celkem zbytečná otázka, protože zboj může kdykoli (bez důkazu) tvrdit, že díky (jakékoliv) znalosti může pracovat efektivněji, čistěji, produkovat rychlejší kód atd. atd. atd. A jestli je to skutečně tak, se stejně nedozvíš, čili informační hodnota nula. A to ani nemluvím o čistém honění si trika "kdo to neumí, je opice".

Mně přijde, že ty teoretičtější znalosti se občas hodí na to, abys nevymetal některé slepé uličky. A zvlášť to platí u věcí, které běžný programátor nedělá - jako třeba návrh toho samotného jazyka. Pokud se to postaví na dobrý základ, tak je možná menší šance, že se časem zabředne do něčeho, co nikdo předem neočekával. Ale i tak se do něčeho zabředne... Na Haskellu je to celkem dobře vidět: má suprsolidní základ, motají se kolem něj supervzdělaní lidi, některé věci vyřešil velice elegantně, ale jiné jsou stejně pořád opruz ;)

Už jenom takové ty úplné základy algebry ti můžou pomoct se občas nějakému problému vyhnout - když v nějaké datové struktuře uvidíš strom, hnedka se zeptáš, jestli to stojí za ty komplikace, které s tím budou a jestli by se to radši nedalo implementovat jako nějaké pole, se kterým se bude snadněji pracovat, líp se to bude paralelizovat a skládat. Takže si díky té znalosti a jí podpořené intuici ušetříš nějaký ten opruz v budoucnu...

Myslím, že tady nikdo netvrdí, že nějaká znalost je úplně k ničemu, spíš je spor o to, jestli se vložená námaha v praxi vrátí nebo ne - a to nevyřešíš, zejména ne se zbojem...
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: JSH 14. 03. 2016, 18:27:10
Ano. Od Base se nedědí vůbec nic. V příkladu jde jen o to, aby ukazatele (reference) na Foo šlo bezpečně použít tam, kde jsou očekávány ukazatele (reference) na Base - jde jen o podtypový polymorfismus - dědičnost je něco jiného.
Mě to teda připadá jako typový polymorfismus, který se v C++ řeší dědičností. Vám ne?
Tak pokud si odmyslím abstraktní rozhraní, tak je dědičnost potřebná jednou za uherský rok. Navíc ani v jazycích, které neumí přeposílat zprávy nebo generovat nějaké trampolíny, se dá dědičnost nahradit pomocí kompozice a abstraktních rozhraní bez nějaké bolesti.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: Radek Miček 14. 03. 2016, 19:04:12
Ano. Od Base se nedědí vůbec nic. V příkladu jde jen o to, aby ukazatele (reference) na Foo šlo bezpečně použít tam, kde jsou očekávány ukazatele (reference) na Base - jde jen o podtypový polymorfismus - dědičnost je něco jiného.
Mě to teda připadá jako typový polymorfismus, který se v C++ řeší dědičností. Vám ne?

Podle standardu C++ máte pravdu. Standard C++ nezná pojem podtyp - zná pouze dědičnost. Ve skutečnosti však nejde o dědičnost, ale o podtypový polymorfismus.

Obecně jsou to úplně nezávislé věci (dědičností můžete vytvořit podtřídu, jenž není podtyp, a naopak můžete mít podtyp, aniž byste použil dědičnost). A v tomto konkrétním příkladě žádnou dědičnost nepotřebujete - neboť, jak psal zboj, Base neobsahuje nic, co by mělo smysl dědit - Base nijak neobohatí svou podtřídu.

Relevantní je následující charakteristika dědičnosti:

Citace
So, knowing that c* inherits from c tells us nothing about the behavior of its objects, but only about the means by which the class is defined. Inheritance carries no semantic significance, but is only a record of the history of how a class is defined.

Převzato z Practical Foundations for Programming Languages, 2. edice (https://www.cs.cmu.edu/~rwh/plbook/2nded.pdf#269), strana 251.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: andy 14. 03. 2016, 23:00:59
Citace: Mirek Prymek
Myslím, že tady nikdo netvrdí, že nějaká znalost je úplně k ničemu, spíš je spor o to, jestli se vložená námaha v praxi vrátí nebo ne - a to nevyřešíš, zejména ne se zbojem...
To je jedna věc - ale já reagoval spíš na to, že aby člověk programoval na nějaké profi úrovni FP, tak musí umět nejspíš category theory, jinak je to patlal. Přičemž ale IMO na 90% kódu knihoven, které člověk v haskellu používá, nepotřebuje znát v podstatě žádnou category theory (resp. potřebuje znát, jak to funguje prakticky, nikoliv tu teorii za tím).

Citace: Radek Miček
Podle standardu C++ máte pravdu. Standard C++ nezná pojem podtyp - zná pouze dědičnost. Ve skutečnosti však nejde o dědičnost, ale o podtypový polymorfismus.
Já s tím naprosto souhlasím. Jenomže výsledkem je, že velké množství problémů je tím pádem možné namodelovat bez využití dědičnosti, pokud se na to člověk podívá z trochu jiného úhlu pohledu. QuickSort ve funkcionálních jazycích je taky obecně tragédie, takže si můžete zoufat, jak jsou funkcionální jazyky pomalé a nepraktické - a pak použijete tuším merge sort a najednou se to chová lépe. Některé problémy se prostě v FP řeší diametrálně odlišně, některé vyřešit elegantně nedají v FP, jiné v OOP.
Ano, v jazycích typu Haskell je dědičnost poněkud problém, jenomže těch problémů, kdy je dědičnost jediná rozumná cesta, je poměrně málo.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: Mirek Prýmek 15. 03. 2016, 03:08:31
aby člověk programoval na nějaké profi úrovni FP, tak musí umět nejspíš category theory, jinak je to patlal. Přičemž ale IMO na 90% kódu knihoven, které člověk v haskellu používá, nepotřebuje znát v podstatě žádnou category theory (resp. potřebuje znát, jak to funguje prakticky, nikoliv tu teorii za tím).
To si jenom zboj opět honí triko, můžeš to s klidem ignorovat :)
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: patlal 15. 03. 2016, 12:43:25
aby člověk programoval na nějaké profi úrovni FP, tak musí umět nejspíš category theory, jinak je to patlal. Přičemž ale IMO na 90% kódu knihoven, které člověk v haskellu používá, nepotřebuje znát v podstatě žádnou category theory (resp. potřebuje znát, jak to funguje prakticky, nikoliv tu teorii za tím).
To si jenom zboj opět honí triko, můžeš to s klidem ignorovat :)

Hlavně neexistuje ani nějaká studie na podobné věci. Učte se matiku, budete lépe programovat.

Ale z pozorování a hloupého českého školství se dá poměrně dobře usuzovat, že znalosti jsou u nás pořád docela ceněné. Takže kdo neumí Babičku nazpaměť, ten nikdy nebude umět programovat. A nebo cokoli dalšího, co se jen někdo naučil nazpaměť a pak to cpe na fórech jako jedinou možnou cestu. Nesouvisející věci ale prostě souviset nemůžou, tak ani létání s letadlem moc nevylepší styl architektury člověka programujícího v Haskell.

Chápu, že pro některé je patlal prostě ten, co neumí nazpaměť to stejné co on. Říká to ale docela dost o autorovi, pokud si samozřejmě nedělá jen srandu.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: zboj 15. 03. 2016, 13:35:20
aby člověk programoval na nějaké profi úrovni FP, tak musí umět nejspíš category theory, jinak je to patlal. Přičemž ale IMO na 90% kódu knihoven, které člověk v haskellu používá, nepotřebuje znát v podstatě žádnou category theory (resp. potřebuje znát, jak to funguje prakticky, nikoliv tu teorii za tím).
To si jenom zboj opět honí triko, můžeš to s klidem ignorovat :)

Hlavně neexistuje ani nějaká studie na podobné věci. Učte se matiku, budete lépe programovat.

Ale z pozorování a hloupého českého školství se dá poměrně dobře usuzovat, že znalosti jsou u nás pořád docela ceněné. Takže kdo neumí Babičku nazpaměť, ten nikdy nebude umět programovat. A nebo cokoli dalšího, co se jen někdo naučil nazpaměť a pak to cpe na fórech jako jedinou možnou cestu. Nesouvisející věci ale prostě souviset nemůžou, tak ani létání s letadlem moc nevylepší styl architektury člověka programujícího v Haskell.

Chápu, že pro některé je patlal prostě ten, co neumí nazpaměť to stejné co on. Říká to ale docela dost o autorovi, pokud si samozřejmě nedělá jen srandu.
Rozlišuj mezi "učit se nazpaměť" a "pochopit do hloubky". Pak třeba přijde osvícení ;) Jinak sranda patří k životu ;)
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: patlal 15. 03. 2016, 13:38:49
Matika je typicky o učení nazpaměť. Reálné projekty v IT jsou typicky o hlubokém pochopení. Ty preferuješ to první a píšeš jako kdybys opravdu preferoval to první. Podle mě je to docela jasné a Mirek to několikrát naznačoval. Ale s trollením souhlasím, jen je problém, že ty se pak na něj vždy můžeš vymluvit. Že jsi vlastně tak nemyslel a tak. Kdo ví, jak to vlastně je...
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: zboj 15. 03. 2016, 13:45:11
Matika je typicky o učení nazpaměť. Reálné projekty v IT jsou typicky o hlubokém pochopení. Ty preferuješ to první a píšeš jako kdybys opravdu preferoval to první. Podle mě je to docela jasné a Mirek to několikrát naznačoval. Ale s trollením souhlasím, jen je problém, že ty se pak na něj vždy můžeš vymluvit. Že jsi vlastně tak nemyslel a tak. Kdo ví, jak to vlastně je...
Matika je o abstraktních strukturách a vztazích mezi nimi. Zkus se ponořit třeba do té zmíněné teorie kategorií, je to docela zajímavé a otvírá to nové obzory ;)
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: Ondra Satai Nekola 15. 03. 2016, 13:51:48
Matika je typicky o učení nazpaměť.
WTF?
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: hu 15. 03. 2016, 13:59:07
Matika je typicky o učení nazpaměť.
WTF?
No jo, když ona má spousta lidí pouze školskou zkušenost s matikou, kde je to opravdu často o memorování goniometrickejch identit a k abstrakci to má asi tak stejně blízko jako dějepis. Pak jsou schopni tvrdit podobný nesmysly, ale v zásadě to není chyba jejich, ale vzdělávacího systému.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: Mirek Prýmek 15. 03. 2016, 14:01:40
Nesouvisející věci ale prostě souviset nemůžou, tak ani létání s letadlem moc nevylepší styl architektury člověka programujícího v Haskell.
Teorie kategorií ale s Haskellem souvisí docela úzce. Ale je obecnější a těžší. K běžnému programování v Haskellu stačí pochopit běžné programování v Haskellu. TK k tomu potřeba není. Že člověk uvidí různé haskelloviny v novém světle a s širšími souvislostmi je pravda, ale nutné to není. Ani není pravda, že kdo TK nezná, je patlal. To je krávovina.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: zboj 15. 03. 2016, 14:10:24
Matika je typicky o učení nazpaměť.
WTF?
No jo, když ona má spousta lidí pouze školskou zkušenost s matikou, kde je to opravdu často o memorování goniometrickejch identit a k abstrakci to má asi tak stejně blízko jako dějepis. Pak jsou schopni tvrdit podobný nesmysly, ale v zásadě to není chyba jejich, ale vzdělávacího systému.
No jo, ale tady se snad nebavíme o matice na úrovni základní školy...
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: uetoyo 15. 03. 2016, 15:11:21
On autor dotazu dělá nějakou GUI knihovnu a jak sem procházel odkazy (R. Miček) často jsou to hodně košaté vztahy (OOP dedičnost) -- takže asi kopíruje OOP model, který viděl jinde... Tedy co byla původní otázka? Jestli Rust bez dědičnosti, jak ji nabízí C++ je méně flexibilní pro návrh GUI knihovny než C++?

https://lwn.net/Articles/548560/
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: Viky 15. 03. 2016, 15:41:17
Matika je typicky o učení nazpaměť.

Pokud jsi schopen napsat takovouto kravinu, tak je zřejmé, že jsi hluboce nepochopil, o čem je matematika. Jak chceš teď někoho přesvědčit o tom, že jsi schopen pochopit složitější věci, když tvé intelektuální schopnosti jsou natolik omezené, že ti neumožňují ani pochopení takto jednoduché věci?

Takže jsi jen sám na sobě demonstroval, že na implikaci nechápe matematiku => nebude schopen pochopit ani reálný IT projekt opravdu něco je.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: Mirek Prýmek 15. 03. 2016, 16:06:50
Pokud jsi schopen napsat takovouto kravinu, tak je zřejmé, že jsi hluboce nepochopil, o čem je matematika.
Což může být (a často je) chyba učitele.

Ale fakt bych nerozjížděl další nekonečné vlákno na tohle téma...
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: JSH 15. 03. 2016, 16:41:43
On autor dotazu dělá nějakou GUI knihovnu a jak sem procházel odkazy (R. Miček) často jsou to hodně košaté vztahy (OOP dedičnost) -- takže asi kopíruje OOP model, který viděl jinde... Tedy co byla původní otázka? Jestli Rust bez dědičnosti, jak ji nabízí C++ je méně flexibilní pro návrh GUI knihovny než C++?
Pravda. Třeba ten vztah "je", který se dědičnosti často připisuje, odpovídá spíš podtypům než potomkům. Dědičnost moc neumí přidávat omezení a z toho lezou problémy jako že elipsa je kružnice, ale dědí se to blbě. A rozhraní (nebo třeba Haskellovské classy) na to pasujou daleko líp.

Jako příklad, kdy dědičnost těžce kulhá, bych dal visitor. Ve chvíli kdy člověk uvažuje o visitoru opravdu stojí za zvážení, jestli nepoužít nějaký jazyk který umí součtové typy.

Dědičnost je prostředek jazyka. Ne něco, čeho chci dosáhnout. Otázka "jak nahradit dědičnost" je principielně blbě. Správná otázka je něco jako "jak udělat abc, které se často dělá pomocí dědění". Dědičnost dělá trochu rozhraní, trochu kompozici a ani jedno pořádně.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: Mirek Prýmek 15. 03. 2016, 17:39:17
Dědičnost je prostředek jazyka. Ne něco, čeho chci dosáhnout. Otázka "jak nahradit dědičnost" je principielně blbě. Správná otázka je něco jako "jak udělat abc, které se často dělá pomocí dědění". Dědičnost dělá trochu rozhraní, trochu kompozici a ani jedno pořádně.
Navíc se z dědičnosti stal strašný fetiš. Dědičnost se přefoukla a na posílání zpráv se zapomnělo. Když už, bylo by lepší, kdyby to bylo naopak. Dneska když se řekne OOP, každý pořád mele o dědičnosti. Úplně zbytečně.

BTW, podobně jako třídy v Haskellu fungují i protokoly v Elixiru: http://elixir-lang.org/getting-started/protocols.html Je to silný nástroj a pracuje se s tím krásně. Blbý je, že to jsou tak trochu "C++/C#/Java třídy naruby", takže pro většinu programátorů je to velkej mindtwist a musí se naučit, jak to vlastně využívat.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: JSH 15. 03. 2016, 18:05:05
Navíc se z dědičnosti stal strašný fetiš. Dědičnost se přefoukla a na posílání zpráv se zapomnělo. Když už, bylo by lepší, kdyby to bylo naopak. Dneska když se řekne OOP, každý pořád mele o dědičnosti. Úplně zbytečně.
Ono se IMO přefouklo i to OOP. Už ten pojem samotný je strašně neurčitý.

K původní myšlence OOP mi ani ten název "objekt" nesedí. U většiny objektů z reálného světa mě ani nenapadne, abych po nich něco chtěl (a posílal jim nějakou zprávu, aby to udělaly). Daleko přesněji by to vystihoval třeba actor, nebo služba. Možná ta roztříštěnost dnešního OOP plyne trochu i z toho, že je těžké ten pojem nějak uchopit bez předchozího vysvětlení. Objekt je nějaká věc, o které toho nic moc dalšího nevíme.

Ale to je jenom takové bezvýznamné skuhrání a hra se slovy :)
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: patlal 15. 03. 2016, 18:05:59
Matika je typicky o učení nazpaměť.

Pokud jsi schopen napsat takovouto kravinu, tak je zřejmé, že jsi hluboce nepochopil, o čem je matematika.

Vtipné na tom je, že já to právě pochopil. Ale ostatní jako zboj a třeba ty my dokazujete, že matematiku jen umíte, ale nechápete. Na VŠ se učí normálně tupým stylem, abyste prošli a stačilo vám ji jen umět. Takže fakt to neházej na mě. Proč si myslíš, že si tu musíte honit triko se znalostmi? Proč tu někdo neukázal nějaké chápání souvislostí? Proč asi :)
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: zboj 15. 03. 2016, 18:13:14
Matika je typicky o učení nazpaměť.

Pokud jsi schopen napsat takovouto kravinu, tak je zřejmé, že jsi hluboce nepochopil, o čem je matematika.

Vtipné na tom je, že já to právě pochopil. Ale ostatní jako zboj a třeba ty my dokazujete, že matematiku jen umíte, ale nechápete. Na VŠ se učí normálně tupým stylem, abyste prošli a stačilo vám ji jen umět. Takže fakt to neházej na mě. Proč si myslíš, že si tu musíte honit triko se znalostmi? Proč tu někdo neukázal nějaké chápání souvislostí? Proč asi :)
Nejdřív se nauč pravopis a pak piš o matematice a VŠ ;)
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: patlal 15. 03. 2016, 18:16:08
To je přesně ono. Znalosti a mistr zboj. Dík. Ale znalosti tě daleko nedovedou, kámo.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: zboj 15. 03. 2016, 18:16:30
Navíc se z dědičnosti stal strašný fetiš. Dědičnost se přefoukla a na posílání zpráv se zapomnělo. Když už, bylo by lepší, kdyby to bylo naopak. Dneska když se řekne OOP, každý pořád mele o dědičnosti. Úplně zbytečně.
Ono se IMO přefouklo i to OOP. Už ten pojem samotný je strašně neurčitý.

K původní myšlence OOP mi ani ten název "objekt" nesedí. U většiny objektů z reálného světa mě ani nenapadne, abych po nich něco chtěl (a posílal jim nějakou zprávu, aby to udělaly). Daleko přesněji by to vystihoval třeba actor, nebo služba. Možná ta roztříštěnost dnešního OOP plyne trochu i z toho, že je těžké ten pojem nějak uchopit bez předchozího vysvětlení. Objekt je nějaká věc, o které toho nic moc dalšího nevíme.

Ale to je jenom takové bezvýznamné skuhrání a hra se slovy :)
Celkem výstižně řečeno, objekt je prostě "něco, co má nějaké vlastnosti a něco dělá", podobně jako množina v temnu je "nějaká kolekce něčeho mající rozumné (=ne moc hnusné) vlastnosti". V diskusi by se vždy mělo upřesnit, jaké paradigma se vlastně zmiňuje, pak z toho plyne jen nedorozumění.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: Mirek Prýmek 15. 03. 2016, 18:19:23
Daleko přesněji by to vystihoval třeba actor, nebo služba.
No však taky actor je hodně blízko tomu, co původně objekt měl být, dokud to C++ nezprasilo :)

Ale to je jenom takové bezvýznamné skuhrání a hra se slovy :)
Já myslím že ne. Zasadit si ty programátorské pojmy a koncepty do širšího kontextu "filosofického" mi přijde možná stejně důležité jako ten teoretický background. Ono se totiž operuje se spoustou věcí jako by to byly danosti a přitom to jsou jenom víceméně historicky dané koncepty :)
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: Ivan Nový 16. 03. 2016, 09:26:22
Daleko přesněji by to vystihoval třeba actor, nebo služba.
No však taky actor je hodně blízko tomu, co původně objekt měl být, dokud to C++ nezprasilo :)

Ale to je jenom takové bezvýznamné skuhrání a hra se slovy :)
Já myslím že ne. Zasadit si ty programátorské pojmy a koncepty do širšího kontextu "filosofického" mi přijde možná stejně důležité jako ten teoretický background. Ono se totiž operuje se spoustou věcí jako by to byly danosti a přitom to jsou jenom víceméně historicky dané koncepty :)
Někomu, kdo nemyslí "fraktálně", a nevidí stejné principy na různých úrovních, je stejně OOP i FP na nic. Každou činnost bude otrocky popisovat stále znovu a znovu bez špetky zobecnění. Práce mu ale půjde rychle od ruky, údržba výsledku bude sice pracná, ale nenáročná na vědomosti a pochopení vytvořeného programu. A teď babo raď :-)
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: Ivan Nový 16. 03. 2016, 09:38:35
Jinak představa modulů a objektů je odvozena z HW, kdy počítače byly rozděleny do mnoha desek s elektronikou a když něco nefungovalo, nejdříve bylo třeba určit modul, kde se nachází porucha a ten na jednom místě opravit. A z toho podvědomě u programátorů vznikla snaha dělit i SW do modulů, či objektů(OOP), nebo neměnných částí dat (FP), aby bylo možno chybu snáze najít a stačilo ji opravit jen na jednom místě (odtud například požadavek dědičnosti). Jenže s miniaturizací moduly z HW zmizely a modulární představa SW visí tak trochu ve vzduchu a zapomělo se, z čeho vlastně vznikla.

OOP je defacto do softwaru převedená modulární architektura hardware mainframu ze 70. let (hw moduly, co si po sběrnici posílají zprávy).
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: Inkvizitor 16. 03. 2016, 09:45:00

Už tě někdo poslal v tomto vlákně do háje i s tvými mimoňskými trollposty, nebo to čeká na mě?
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: hawran diskuse 16. 03. 2016, 09:48:33
Jinak představa modulů a objektů je odvozena z HW, kdy počítače byly rozděleny do mnoha desek s elektronikou a když něco nefungovalo, nejdříve bylo třeba určit modul, kde se nachází porucha a ten na jednom místě opravit. A z toho podvědomě u programátorů vznikla snaha dělit i SW do modulů, či objektů(OOP), nebo neměnných částí dat (FP), aby bylo možno chybu snáze najít a stačilo ji opravit jen na jednom místě (odtud například požadavek dědičnosti). Jenže s miniaturizací moduly z HW zmizely a modulární představa SW visí tak trochu ve vzduchu a zapomělo se, z čeho vlastně vznikla.

OOP je defacto do softwaru převedená modulární architektura hardware mainframu ze 70. let (hw moduly, co si po sběrnici posílají zprávy).

 :o
A kde je neviditelná ruka trhu?
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: JSH 16. 03. 2016, 09:54:26
Jenže s miniaturizací moduly z HW zmizely a modulární představa SW visí tak trochu ve vzduchu a zapomělo se, z čeho vlastně vznikla.
Cože? Jako že moderní HW se neskládá hierarchicky z komponent? Že je to na jednom kusu křemíku neznamená, že tam ty komponenty nejsou.

Modulární architektura nevychází primárně  z HW, ale z našeho mozku. Člověk udrží v hlavě jen +-10 věcí najednou. Cokoliv navržené člověkem bude hierarchická skládačka a na každé úrovni bude jen omezený počet nějakých přiměřeně uzavřených kousků.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: Mirek Prýmek 16. 03. 2016, 09:58:28
Cokoliv navržené člověkem bude hierarchická skládačka a na každé úrovni bude jen omezený počet nějakých přiměřeně uzavřených kousků.
Viděl jsem i systémy bez hierarchie, s desítkami součástí, kde každá potenciálně komunikovala s každou. Je pravda, že to nikdo v hlavě neudržel. A že ten, kdo to navrhoval, nebyl člověk, to jsem si myslel celou dobu, takže to by tvé teorii taky odpovídalo ;)
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: Ivan Nový 16. 03. 2016, 10:11:19
Jenže s miniaturizací moduly z HW zmizely a modulární představa SW visí tak trochu ve vzduchu a zapomělo se, z čeho vlastně vznikla.
Cože? Jako že moderní HW se neskládá hierarchicky z komponent? Že je to na jednom kusu křemíku neznamená, že tam ty komponenty nejsou.

Modulární architektura nevychází primárně  z HW, ale z našeho mozku. Člověk udrží v hlavě jen +-10 věcí najednou. Cokoliv navržené člověkem bude hierarchická skládačka a na každé úrovni bude jen omezený počet nějakých přiměřeně uzavřených kousků.

Ano i to může být jeden ze zdrojů. HW moduly už nejsou tak na očích, takže tato prapůvodní analogie dnešní programátory ani nenapadne. Dříve se poruchy hw a jejich hledání řešily stále. Střední doba mezi poruchami byla krátká.

Modulů je obvykle více, než 10. SW není přirozeně uzavřený. SW produkty, které nejsou modulární, ale popisné, se šíří snadněji, protože jim nemusíte rozumět, stačí najít místa, která jsou třeba upravit.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: Ivan Nový 16. 03. 2016, 10:16:14
Cokoliv navržené člověkem bude hierarchická skládačka a na každé úrovni bude jen omezený počet nějakých přiměřeně uzavřených kousků.
Viděl jsem i systémy bez hierarchie, s desítkami součástí, kde každá potenciálně komunikovala s každou. Je pravda, že to nikdo v hlavě neudržel. A že ten, kdo to navrhoval, nebyl člověk, to jsem si myslel celou dobu, takže to by tvé teorii taky odpovídalo ;)
Tak běžnému člověku je bližší špagetový kód, který vazby na okolí a nějaký nadhled nad systémem vůbec neřeší. Modulárnímu myšlení se musí učit.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: JSH 16. 03. 2016, 10:16:53
Ano i to může být jeden ze zdrojů. HW moduly už nejsou tak na očích, takže tato prapůvodní analogie dnešní programátory ani nenapadne. Dříve se poruchy hw a jejich hledání řešily stále. Střední doba mezi poruchami byla krátká.

Modulů je obvykle více, než 10. SW není přirozeně uzavřený. SW produkty, které nejsou modulární, ale popisné, se šíří snadněji, protože jim nemusíte rozumět, stačí najít místa, která jsou třeba upravit.
WTF??? Tohle nedává smysl. Ani trochu.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: Lol Phirae 16. 03. 2016, 10:21:36
WTF??? Tohle nedává smysl. Ani trochu.

To je u kolegy Nového běžný stav. Zhoršuje se to, když vysadí prášky.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: Ivan Nový 16. 03. 2016, 10:22:24
Ano i to může být jeden ze zdrojů. HW moduly už nejsou tak na očích, takže tato prapůvodní analogie dnešní programátory ani nenapadne. Dříve se poruchy hw a jejich hledání řešily stále. Střední doba mezi poruchami byla krátká.

Modulů je obvykle více, než 10. SW není přirozeně uzavřený. SW produkty, které nejsou modulární, ale popisné, se šíří snadněji, protože jim nemusíte rozumět, stačí najít místa, která jsou třeba upravit.
WTF??? Tohle nedává smysl. Ani trochu.
Smysl to nedává, ale praxe to často potvrzuje. Třeba v oblasti open source  řešení a jejich šíření a oblíbenosti. Wordpress, OpenCart.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: zboj 16. 03. 2016, 16:55:13
Jenže s miniaturizací moduly z HW zmizely a modulární představa SW visí tak trochu ve vzduchu a zapomělo se, z čeho vlastně vznikla.
Modulární architektura nevychází primárně  z HW, ale z našeho mozku. Člověk udrží v hlavě jen +-10 věcí najednou. Cokoliv navržené člověkem bude hierarchická skládačka a na každé úrovni bude jen omezený počet nějakých přiměřeně uzavřených kousků.
Ano, toto je experimentálně ověřeno kognitivní vědou, ale neznamená to, že "nemodulární" systémy neexistují, jen je pak vnímáme (opět kognitivně) jako "bordel".
Jinak s HW to opravdu nemá vůbec nic společného.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: Ivan Nový 16. 03. 2016, 20:08:45
Jenže s miniaturizací moduly z HW zmizely a modulární představa SW visí tak trochu ve vzduchu a zapomělo se, z čeho vlastně vznikla.
Modulární architektura nevychází primárně  z HW, ale z našeho mozku. Člověk udrží v hlavě jen +-10 věcí najednou. Cokoliv navržené člověkem bude hierarchická skládačka a na každé úrovni bude jen omezený počet nějakých přiměřeně uzavřených kousků.
Ano, toto je experimentálně ověřeno kognitivní vědou, ale neznamená to, že "nemodulární" systémy neexistují, jen je pak vnímáme (opět kognitivně) jako "bordel".
Jinak s HW to opravdu nemá vůbec nic společného.
V době kdy vznikalo "modulární" programování, tak kongitivní věda vlastně neexistovala. Inspirace musela přijít odjinud. Dnes "modulární" objektové programování je vnímáno jako bordel, vzájemně provázaných objektů je už příliš.

A jak vysvětlíte to, že většina neškolených lidí produkuje špageti kód? Proč se chovají nepřirozeně a proti přirozenosti svého mozku?
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: JSH 16. 03. 2016, 20:43:47
V době kdy vznikalo "modulární" programování, tak kongitivní věda vlastně neexistovala. Inspirace musela přijít odjinud. Dnes "modulární" objektové programování je vnímáno jako bordel, vzájemně provázaných objektů je už příliš.
Ta inspirace ale nepřišla od kognitivních věd. Ty jen popsaly důvody. Co vnímáme jako dobrý návrh a co jako bordel na existenci kognitivních věd nezávisí. Jestli je ten který návrh bordel nebo ne, je právě otázka toho dobrého návrhu.
Citace
A jak vysvětlíte to, že většina neškolených lidí produkuje špageti kód? Proč se chovají nepřirozeně a proti přirozenosti svého mozku?
Fakt je třeba vysvětlovat, že většina neškolených lidí produkuje spatné výsledky, když dělají něco co neumí? :o
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: Ivan Nový 16. 03. 2016, 20:48:49
V době kdy vznikalo "modulární" programování, tak kongitivní věda vlastně neexistovala. Inspirace musela přijít odjinud. Dnes "modulární" objektové programování je vnímáno jako bordel, vzájemně provázaných objektů je už příliš.
Ta inspirace ale nepřišla od kognitivních věd. Ty jen popsaly důvody. Co vnímáme jako dobrý návrh a co jako bordel na existenci kognitivních věd nezávisí. Jestli je ten který návrh bordel nebo ne, je právě otázka toho dobrého návrhu.
Citace
A jak vysvětlíte to, že většina neškolených lidí produkuje špageti kód? Proč se chovají nepřirozeně a proti přirozenosti svého mozku?
Fakt je třeba vysvětlovat, že většina neškolených lidí produkuje spatné výsledky, když dělají něco co neumí? :o
Ano samozřejmě je to třeba vysvětlit, pokud tvrdíte, že "modulární" programování je přirozené, pak se ho není třeba učit a neškolený programátor bude myslet "modulárně", bez učení.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: JSH 16. 03. 2016, 21:36:49
Ano samozřejmě je to třeba vysvětlit, pokud tvrdíte, že "modulární" programování je přirozené, pak se ho není třeba učit a neškolený programátor bude myslet "modulárně", bez učení.
Ale já netvrdil, že modulární programování je přirozené. Já tvrdil, že  dobré návrhy (ať už objektové, nebo jiné) budou mít společné to, že na každé úrovni detailu bude jen přiměřený počet různých druhů entit. Pokud jich je moc, tak je výsledek binec a tohle že vychází z lidské přirozenosti.

Mirek Prýmek mi tu správně vytkl, že jsem to napsal jako že špatné návrhy neexistují. Samo že existují. Ale to, že by byl dobrý návrh pro člověka přirozený jsem tam fakt nepsal.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: Ivan Nový 16. 03. 2016, 22:16:18
Ano samozřejmě je to třeba vysvětlit, pokud tvrdíte, že "modulární" programování je přirozené, pak se ho není třeba učit a neškolený programátor bude myslet "modulárně", bez učení.
Ale já netvrdil, že modulární programování je přirozené. Já tvrdil, že  dobré návrhy (ať už objektové, nebo jiné) budou mít společné to, že na každé úrovni detailu bude jen přiměřený počet různých druhů entit. Pokud jich je moc, tak je výsledek binec a tohle že vychází z lidské přirozenosti.

Mirek Prýmek mi tu správně vytkl, že jsem to napsal jako že špatné návrhy neexistují. Samo že existují. Ale to, že by byl dobrý návrh pro člověka přirozený jsem tam fakt nepsal.
OK, to beru
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: atarist 17. 03. 2016, 00:20:37
Jinak představa modulů a objektů je odvozena z HW, kdy počítače byly rozděleny do mnoha desek s elektronikou a když něco nefungovalo, nejdříve bylo třeba určit modul, kde se nachází porucha a ten na jednom místě opravit. A z toho podvědomě u programátorů vznikla snaha dělit i SW do modulů, či objektů(OOP), nebo neměnných částí dat (FP), aby bylo možno chybu snáze najít a stačilo ji opravit jen na jednom místě (odtud například požadavek dědičnosti). Jenže s miniaturizací moduly z HW zmizely a modulární představa SW visí tak trochu ve vzduchu a zapomělo se, z čeho vlastně vznikla.

OOP je defacto do softwaru převedená modulární architektura hardware mainframu ze 70. let (hw moduly, co si po sběrnici posílají zprávy).

Mno nevím, načteno toho mám například od Wirtha dost, ale tento důvod nebo inspiraci nikdy nezmiňoval, on vlastně vůbec moc neřešil HW. U FP samozřejmě nemáš pravdu, tam je historie vzniku jasně popsaná a vůbec nesouvisela s HW, spíš naopak. Jdou ty tvrzení něčím podložit nebo je to takové to JPP nebo doměnky ve stylu "modul jako modul"?
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: Ivan Nový 17. 03. 2016, 05:55:59
Jinak představa modulů a objektů je odvozena z HW, kdy počítače byly rozděleny do mnoha desek s elektronikou a když něco nefungovalo, nejdříve bylo třeba určit modul, kde se nachází porucha a ten na jednom místě opravit. A z toho podvědomě u programátorů vznikla snaha dělit i SW do modulů, či objektů(OOP), nebo neměnných částí dat (FP), aby bylo možno chybu snáze najít a stačilo ji opravit jen na jednom místě (odtud například požadavek dědičnosti). Jenže s miniaturizací moduly z HW zmizely a modulární představa SW visí tak trochu ve vzduchu a zapomělo se, z čeho vlastně vznikla.

OOP je defacto do softwaru převedená modulární architektura hardware mainframu ze 70. let (hw moduly, co si po sběrnici posílají zprávy).

Mno nevím, načteno toho mám například od Wirtha dost, ale tento důvod nebo inspiraci nikdy nezmiňoval, on vlastně vůbec moc neřešil HW. U FP samozřejmě nemáš pravdu, tam je historie vzniku jasně popsaná a vůbec nesouvisela s HW, spíš naopak. Jdou ty tvrzení něčím podložit nebo je to takové to JPP nebo doměnky ve stylu "modul jako modul"?

Mluvím-li o modulu, mám na mysli abstraktní modul, tedy v podstatě jakýkoliv objekt s převažující lokální komunikací.

V době Wirtha to sice byly dva oddělené světy programátorů a techniků, ale denně se stýkali, tehdy hlavním nástrojem programátora byla tužka, guma a stoh papíru s binárním výpisem paměti :-) Strojový čas byl velmi drahý, takže každý měl omezenýna čas na ladění, takže program spustil třeba jen jednou za den, aby ho otestoval a vyzkoušel co dělá, zbytek se řešil na papíře a v hlavě :-) Inspiraci si člověk ne vždy uvědomí, takže je irelevantní zda o tom Wirth píše či ne.

Jinak s tím HW u Wirtha nemáte tak docela pravdu, pracoval i na tomto https://en.wikipedia.org/wiki/Lola_%28computing%29, na jazyku pro statický popis HW.

Dobře popsaná inspirace je u inkoustových tiskáren, techniky, kteří to vymysleli inspiroval automat na kávu, pohled na to, jak do hrníčku tryskají kapky kávy :-)
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: JSH 17. 03. 2016, 09:43:07
Mluvím-li o modulu, mám na mysli abstraktní modul, tedy v podstatě jakýkoliv objekt s převažující lokální komunikací.
Tak tohle je imo jedna z horších definic toho, co to je modul. Nejmíň u poloviny modulů, co jsem kdy napsal nebo použil tu převažující lokální komunikaci fakt nevidím.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: zboj 17. 03. 2016, 10:02:50
Mluvím-li o modulu, mám na mysli abstraktní modul, tedy v podstatě jakýkoliv objekt s převažující lokální komunikací.
Tak tohle je imo jedna z horších definic toho, co to je modul. Nejmíň u poloviny modulů, co jsem kdy napsal nebo použil tu převažující lokální komunikaci fakt nevidím.
Nebere se to spíš jako blackbox bez ohledu na vnitřnosti?
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: Ivan Nový 17. 03. 2016, 10:21:54
Mluvím-li o modulu, mám na mysli abstraktní modul, tedy v podstatě jakýkoliv objekt s převažující lokální komunikací.
Tak tohle je imo jedna z horších definic toho, co to je modul. Nejmíň u poloviny modulů, co jsem kdy napsal nebo použil tu převažující lokální komunikaci fakt nevidím.
Tak záleží jak tu komunikaci definujete, komunikaci si můžete představit jako fyzické doručení balíčku na nějakou adresu a nebo taky jako změnu svého jednání na základě nějaké informace, kterou jste přijal. Modul tedy až na přesně popsané výjimky, používá ke změně svého stavu lokální informace.

Pokud tedy píšete průchozí moduly, vnější závislosti jsou tak silné, že můžete od modulu abstrahovat a musíte se spíše zabývat vztahy mezi moduly, které propojuje, než průchozím modulem samotným. Modul degraduje na komunikační kanál, takže vás přestane zajímat co s informací dělá, ale zda je průchozí. A tak k němu budete přistupovat i při testování.

Výhoda modulu se pak ztrácí, protože mu intuitivně dáváte menší váhu a snadněji přehlédnete jeho špatnou funkci, ve své hlavě ho nahradíte abstrakcí, která vám zastře jeho reálné chování a stane se to zdrojem těžko odhalitelných chyb.

Imutable objekty v FP je vlastně taky snaha o lokalizaci informací a de facto modularizaci výpočtu, nikoliv programu jako takového. Funkce během výpočtu nekomunikuje s okolím, mění stav jen lokálně, pozorování okolí skrze jiné funkce během výpočtu není komunikace, protože to nemění stav jiných probíhajících výpočtů.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: JSH 17. 03. 2016, 13:21:38
Tak záleží jak tu komunikaci definujete, komunikaci si můžete představit jako fyzické doručení balíčku na nějakou adresu a nebo taky jako změnu svého jednání na základě nějaké informace, kterou jste přijal. Modul tedy až na přesně popsané výjimky, používá ke změně svého stavu lokální informace.
Jeden z důvodů, proč se moduly používají, je to aby člověk nemusel nějakou vnitřní komunikaci vůbec řešit. Co moduly, co žádný vnitřní stav nemají? Co moduly, co nijak nejednají? Nebo si mám kromě pojmu komunikace předefinovat i stav a jednání?
Citace
Pokud tedy píšete průchozí moduly, vnější závislosti jsou tak silné, že můžete od modulu abstrahovat a musíte se spíše zabývat vztahy mezi moduly, které propojuje, než průchozím modulem samotným. Modul degraduje na komunikační kanál, takže vás přestane zajímat co s informací dělá, ale zda je průchozí. A tak k němu budete přistupovat i při testování.
Průchozími moduly myslíte třeba adaptér a podobně? Ty se píšou právě proto, abych se _nemusel_ zbývat tím, co je na druhé straně. Pokud musím myslet na to, že je nějaký modul komunikační kanál, tak je někde chyba.
Citace
Výhoda modulu se pak ztrácí, protože mu intuitivně dáváte menší váhu a snadněji přehlédnete jeho špatnou funkci, ve své hlavě ho nahradíte abstrakcí, která vám zastře jeho reálné chování a stane se to zdrojem těžko odhalitelných chyb.
Nahradit něco abstrakcí je přece jeden z důvodů, proč se moduly používají, ne? Pokud modul nemůžu v hlavě nahradit abstrakcí, pak je to bug. A kvůli tomu se píšou unit testy a podobně.
Citace
Imutable objekty v FP je vlastně taky snaha o lokalizaci informací a de facto modularizaci výpočtu, nikoliv programu jako takového. Funkce během výpočtu nekomunikuje s okolím, mění stav jen lokálně, pozorování okolí skrze jiné funkce během výpočtu není komunikace, protože to nemění stav jiných probíhajících výpočtů.
A tohle teda nedávám. Koukat na FP jako na komunikující moduly je tak nešikovné až to skoro bolí. Tady ta vaše analogie s mainframy kulhá na obě nohy. Abych ve FP viděl nějakou komunikaci, pak si musím celé to FP odmyslet a soustředit se na implementaci. Proč bych měl něco takového vůbec dělat?

Jak psal Zboj, dobrý modul je blackbox. Použít modul by mělo jít i bez "kuchání". Definovat si samotný pojem modul podle jeho vnitřností mi přijde, že jde přímo proti tomuhle principu.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: Ivan Nový 17. 03. 2016, 22:40:21
Citace
Citace
Pokud tedy píšete průchozí moduly, vnější závislosti jsou tak silné, že můžete od modulu abstrahovat a musíte se spíše zabývat vztahy mezi moduly, které propojuje, než průchozím modulem samotným. Modul degraduje na komunikační kanál, takže vás přestane zajímat co s informací dělá, ale zda je průchozí. A tak k němu budete přistupovat i při testování.
Průchozími moduly myslíte třeba adaptér a podobně? Ty se píšou právě proto, abych se _nemusel_ zbývat tím, co je na druhé straně. Pokud musím myslet na to, že je nějaký modul komunikační kanál, tak je někde chyba.
Citace

Objekt != Modul

Výhoda modulu se pak ztrácí, protože mu intuitivně dáváte menší váhu a snadněji přehlédnete jeho špatnou funkci, ve své hlavě ho nahradíte abstrakcí, která vám zastře jeho reálné chování a stane se to zdrojem těžko odhalitelných chyb.
Nahradit něco abstrakcí je přece jeden z důvodů, proč se moduly používají, ne? Pokud modul nemůžu v hlavě nahradit abstrakcí, pak je to bug. A kvůli tomu se píšou unit testy a podobně.
Unit testy vám nepomůžou, protože díky tomu, že modul degraduje na průchozí komunikační kanál, žádné nenapíšete, bude to pod rozlišovací schopností vašeho mozku, unit testy nepomohou, protože funkčnost komunikačního kanálu nezávisí na něm samém, ale na tom, co je na něj napojeno. Je to opak modulárního přístupu. Takže místo testu předpokládaného chování modulu, byste musel testovat chování jeho okolí.

Citace
Citace
Imutable objekty v FP je vlastně taky snaha o lokalizaci informací a de facto modularizaci výpočtu, nikoliv programu jako takového. Funkce během výpočtu nekomunikuje s okolím, mění stav jen lokálně, pozorování okolí skrze jiné funkce během výpočtu není komunikace, protože to nemění stav jiných probíhajících výpočtů.
A tohle teda nedávám. Koukat na FP jako na komunikující moduly je tak nešikovné až to skoro bolí. Tady ta vaše analogie s mainframy kulhá na obě nohy. Abych ve FP viděl nějakou komunikaci, pak si musím celé to FP odmyslet a soustředit se na implementaci. Proč bych měl něco takového vůbec dělat?

Jak psal Zboj, dobrý modul je blackbox. Použít modul by mělo jít i bez "kuchání". Definovat si samotný pojem modul podle jeho vnitřností mi přijde, že jde přímo proti tomuhle principu.
Důvod je jediný, paralelizace výpočtu, OOP je "prostorová" modularizace, FP je "časová" modularizace. U FP blackboxujete výpočet v čase. Nevíte kdy se tak stane, víte, že to nic dalšího neovlivní, takže do ukončení výpočtu je to, jako by výpočet uvnitř funkce neprobíhal. Z hlediska výsledku se provádí výpočet jakoby najednou, až jsou všechny dílčí výsledky k dispozici. Funkci můžete použít, aniž byste myslel na její implementaci, použijete rovnou výsledek.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: Mirek Prýmek 18. 03. 2016, 00:09:10
Důvod je jediný, paralelizace výpočtu, OOP je "prostorová" modularizace, FP je "časová" modularizace. U FP blackboxujete výpočet v čase. Nevíte kdy se tak stane, víte, že to nic dalšího neovlivní, takže do ukončení výpočtu je to, jako by výpočet uvnitř funkce neprobíhal. Z hlediska výsledku se provádí výpočet jakoby najednou, až jsou všechny dílčí výsledky k dispozici. Funkci můžete použít, aniž byste myslel na její implementaci, použijete rovnou výsledek.
To jsou tak obecné řeči, že se na to snad ani nedá rozumně reagovat.

Nicméně: základní rozdíl mezi OOP (v dnešním pojetí) a FP je v tom, že v FP si nemůžu zapamatovat referenci na něco s měnitelným stavem. Pokud v OOP předám objektu O1 nějakou referenci na objekt O2, tak si nikdy nemůžu být jistý, že si ji O1 nezapamatoval a že nebude stav O2 měnit kdykoli v budoucnu, typicky v situaci, kdy to vůbec nečekám. V (čistém) FP tohle není možné. Tím se OOP (a do nějaké míry i kód založený na aktorech) stává nepřehlednou sítí odkazů, o které nejsem schopný nic moc říct. Oproti tomu o (čistém) FP programu jsem schopný říct hodně.

Oproti aktorovému programování má (dnešní, reálné) OOP ještě tu nevýhodu, že prasácky do kódu může vlézt kdykoliv jakékoliv vlákno. Proto je OOP ještě větší maglajz.

Takže bych to z hlediska nějaké přehlednosti uspořádal asi takhle: čisté FP > aktory > OOP
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: Mirek Prýmek 21. 03. 2016, 19:04:53
aby člověk programoval na nějaké profi úrovni FP, tak musí umět nejspíš category theory, jinak je to patlal. Přičemž ale IMO na 90% kódu knihoven, které člověk v haskellu používá, nepotřebuje znát v podstatě žádnou category theory (resp. potřebuje znát, jak to funguje prakticky, nikoliv tu teorii za tím).
To si jenom zboj opět honí triko, můžeš to s klidem ignorovat :)
Tak jsem teď shodou okolností narazil na krásný popis toho, co se tady marně snažím vyjádřit roky :)

https://youtu.be/oYk8CKH7OhE?t=25m40s

Citace
It's a crazy way to teach ... adition. There's a reason we don't take that road. Maybe that road works for some percentage of people who are learning but for [...] let's say 95% of people, saying "two" is a better explanation.

- když už ne celou přednášku, určitě stojí za to si pustit aspoň kousek před a po téhle pasáži, kde povídá o tom, jak zbytečný strašák jsou monády - když to stačí ukázat na konkrétním příkladě a srozumitelně pojmenovat ("andThen").

...a za úplně excelentní považuju odpověď na otázku z publika: "no ale jak pojmenuješ ten obecný koncept?!" - "No, monády. Protože pokud mluvím o obecném konceptu, tak to jsou monády. [Ale ne každého to zajímá]"

Celkově ta přednáška je věnovaná tomu, proč je FP pro lidi odstrašující. A je fakt výborná.

P.S. Evana Czaplickiho snad nikdo za lopatu považovat nebude :) i když... tady je všechno možný :)
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: v 21. 03. 2016, 20:29:59
aby člověk programoval na nějaké profi úrovni FP, tak musí umět nejspíš category theory, jinak je to patlal. Přičemž ale IMO na 90% kódu knihoven, které člověk v haskellu používá, nepotřebuje znát v podstatě žádnou category theory (resp. potřebuje znát, jak to funguje prakticky, nikoliv tu teorii za tím).
To si jenom zboj opět honí triko, můžeš to s klidem ignorovat :)
Tak jsem teď shodou okolností narazil na krásný popis toho, co se tady marně snažím vyjádřit roky :)

https://youtu.be/oYk8CKH7OhE?t=25m40s

Citace
It's a crazy way to teach ... adition. There's a reason we don't take that road. Maybe that road works for some percentage of people who are learning but for [...] let's say 95% of people, saying "two" is a better explanation.

- když už ne celou přednášku, určitě stojí za to si pustit aspoň kousek před a po téhle pasáži, kde povídá o tom, jak zbytečný strašák jsou monády - když to stačí ukázat na konkrétním příkladě a srozumitelně pojmenovat ("andThen").

...a za úplně excelentní považuju odpověď na otázku z publika: "no ale jak pojmenuješ ten obecný koncept?!" - "No, monády. Protože pokud mluvím o obecném konceptu, tak to jsou monády. [Ale ne každého to zajímá]"

Celkově ta přednáška je věnovaná tomu, proč je FP pro lidi odstrašující. A je fakt výborná.

P.S. Evana Czaplickiho snad nikdo za lopatu považovat nebude :) i když... tady je všechno možný :)
já ho za lopatu nemám (prakticky netuším kdo to je), ale IMHO mele blbosti, ty analogie jsou chybné
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: Mirek Prýmek 21. 03. 2016, 21:51:58
já ho za lopatu nemám (prakticky netuším kdo to je), ale IMHO mele blbosti, ty analogie jsou chybné
Je to autor Elmu. http://elm-lang.org/
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: alex 22. 03. 2016, 06:36:19
Důvod je jediný, paralelizace výpočtu, OOP je "prostorová" modularizace, FP je "časová" modularizace. U FP blackboxujete výpočet v čase. Nevíte kdy se tak stane, víte, že to nic dalšího neovlivní, takže do ukončení výpočtu je to, jako by výpočet uvnitř funkce neprobíhal. Z hlediska výsledku se provádí výpočet jakoby najednou, až jsou všechny dílčí výsledky k dispozici. Funkci můžete použít, aniž byste myslel na její implementaci, použijete rovnou výsledek.
To jsou tak obecné řeči, že se na to snad ani nedá rozumně reagovat.

Nicméně: základní rozdíl mezi OOP (v dnešním pojetí) a FP je v tom, že v FP si nemůžu zapamatovat referenci na něco s měnitelným stavem. Pokud v OOP předám objektu O1 nějakou referenci na objekt O2, tak si nikdy nemůžu být jistý, že si ji O1 nezapamatoval a že nebude stav O2 měnit kdykoli v budoucnu, typicky v situaci, kdy to vůbec nečekám. V (čistém) FP tohle není možné. Tím se OOP (a do nějaké míry i kód založený na aktorech) stává nepřehlednou sítí odkazů, o které nejsem schopný nic moc říct. Oproti tomu o (čistém) FP programu jsem schopný říct hodně.

Oproti aktorovému programování má (dnešní, reálné) OOP ještě tu nevýhodu, že prasácky do kódu může vlézt kdykoliv jakékoliv vlákno. Proto je OOP ještě větší maglajz.

Takže bych to z hlediska nějaké přehlednosti uspořádal asi takhle: čisté FP > aktory > OOP
Varující je, že čisté FP se prakticky nepoužívá, znamená to, že se prosadí něco co se bude nazývat FP, ale FP to nebude, imutable objekty v FP padnou jako koncept do pěti let, po jejím masovém rozšíření.

Wirthovy snahy vybudovat jazyk, který by svou konstrukcí vedl k přehlednému programování v praxi taky vzaly za své, přehledné programování je výsledkem vnitřní disciplíny, ne jazyka, který používáte.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: BoneFlute 22. 03. 2016, 11:55:05
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?
Nesouhlasím.

Na složitý datový model je funkcionální jazyk naprosto vyhovující. (Zda Rust, je spíše otázka stability jeho samotného, než toho, že je funkcionální.)

Dokonce jsem nabyl dojmu, že objektové programování (tak jak jej známe) a dědičnost nejsou nijak zvláště užitečné, a neosvědčilo se to.

To soudím na základě zkušeností z projektů různých úrovní složitosti i různého skillu vývojářů, ke kterými jsem kdy přišel. Ono samozřejmě vytvářet nový projekt od základu je něco jiného. Tam je to fuk, protože si všechno pamatujete. Ale přijít k existujícímu projektu a zorientovat se v tom... OOP není nutně špatné, ale výceúrovňová dědičnost vysloveně zatemňuje.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: BoneFlute 22. 03. 2016, 11:56:45
Wirthovy snahy vybudovat jazyk, který by svou konstrukcí vedl k přehlednému programování v praxi taky vzaly za své, přehledné programování je výsledkem vnitřní disciplíny, ne jazyka, který používáte.
A není to poněkud škoda?
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: Mirek Prýmek 22. 03. 2016, 12:08:56
Varující je, že čisté FP se prakticky nepoužívá
To video, co jsem odkazoval výš, se právě docela detailně zabývá tím, proč to tak je (podle řečníka). A ve spoustě věcí má podle mě pravdu. Jakmile normální programátor uvidí někde napsáno "IO monády", tak zavře uši a nic už vědět nechce. Kdyby viděl "print x `andThen` print y", nemá problém. Čisté FP jazyky doteď žily/žijí převážně v akademickém prostředí a z toho vychází i všechna ta kultura a texty kolem toho. Nejlíp to vyjadřuje okřídlené:

Citace
Haskell gets some resistance due to the complexity of using monads to control side effects. Wadler tries to appease critics by explaining that "a monad is a monoid in the category of endofunctors, what's the problem?"

Navíc je myslím dobrý si uvědomit, že FP nutně neznamená pure&lazy. Erlang je sympatický jazyk, kde se na mikroúrovni používá docela pěkné FP, které ale není ani pure, ani lazy, ani silně typované (v obvyklém slova smyslu), takže většina té bižuterie z Haskellu tam není potřeba. Totéž F#, Scala (nakolik můžu posoudit, detailně je neznám). Je to kompromis, kterým se jazyk připraví o některé sympatické vlastnosti a garance, ale použitelnost (pro "obyčejné" programátory) je podstatně vyšší. A touhle cestou se nejspíš půjde, na čemž nevidím nic špatného. Jazyky, které dělají dobře promyšlené, teoreticky vyfutrované kompromisy, bývají fajn. To ale není případ OOP, které udělalo kompromis z technického (implementačního), ne designového důvodu.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: zboj 22. 03. 2016, 12:42:41
Důvod je jediný, paralelizace výpočtu, OOP je "prostorová" modularizace, FP je "časová" modularizace. U FP blackboxujete výpočet v čase. Nevíte kdy se tak stane, víte, že to nic dalšího neovlivní, takže do ukončení výpočtu je to, jako by výpočet uvnitř funkce neprobíhal. Z hlediska výsledku se provádí výpočet jakoby najednou, až jsou všechny dílčí výsledky k dispozici. Funkci můžete použít, aniž byste myslel na její implementaci, použijete rovnou výsledek.
To jsou tak obecné řeči, že se na to snad ani nedá rozumně reagovat.

Nicméně: základní rozdíl mezi OOP (v dnešním pojetí) a FP je v tom, že v FP si nemůžu zapamatovat referenci na něco s měnitelným stavem. Pokud v OOP předám objektu O1 nějakou referenci na objekt O2, tak si nikdy nemůžu být jistý, že si ji O1 nezapamatoval a že nebude stav O2 měnit kdykoli v budoucnu, typicky v situaci, kdy to vůbec nečekám. V (čistém) FP tohle není možné. Tím se OOP (a do nějaké míry i kód založený na aktorech) stává nepřehlednou sítí odkazů, o které nejsem schopný nic moc říct. Oproti tomu o (čistém) FP programu jsem schopný říct hodně.

Oproti aktorovému programování má (dnešní, reálné) OOP ještě tu nevýhodu, že prasácky do kódu může vlézt kdykoliv jakékoliv vlákno. Proto je OOP ještě větší maglajz.

Takže bych to z hlediska nějaké přehlednosti uspořádal asi takhle: čisté FP > aktory > OOP
Varující je, že čisté FP se prakticky nepoužívá, znamená to, že se prosadí něco co se bude nazývat FP, ale FP to nebude, imutable objekty v FP padnou jako koncept do pěti let, po jejím masovém rozšíření.


Nejspíš ze stejného důvodu, proč se prakticky nepoužívá čisté logické programování. Nehodí se na vše, procedurálně se často píše lépe.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: v 22. 03. 2016, 12:56:37
Varující je, že čisté FP se prakticky nepoužívá
Jakmile normální programátor uvidí někde napsáno "IO monády", tak zavře uši a nic už vědět nechce.
jakýkoliv normální profesionál když vidí někde "nová technologie", tak zavře uši a nic už vědět nechce, s terminologií to nemá nic společného
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: BoneFlute 22. 03. 2016, 12:59:18
Nejspíš ze stejného důvodu, proč se prakticky nepoužívá čisté logické programování. Nehodí se na vše, procedurálně se často píše lépe.
Ale už se tak dobře nečte.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: Mirek Prýmek 22. 03. 2016, 13:11:46
jakýkoliv normální profesionál když vidí někde "nová technologie", tak zavře uši a nic už vědět nechce, s terminologií to nemá nic společného
No, frontenďáci jsou celí říční, aby měli každej týdej úplně novej make systém a co 14 dní jinej framework. Ale je samozřejmě otázka, jestli jsou frontenďáci "normální profesionálové" ;)
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: Ondra Satai Nekola 22. 03. 2016, 13:28:02
jakýkoliv normální profesionál když vidí někde "nová technologie", tak zavře uši a nic už vědět nechce, s terminologií to nemá nic společného
No, frontenďáci jsou celí říční, aby měli každej týdej úplně novej make systém a co 14 dní jinej framework. Ale je samozřejmě otázka, jestli jsou frontenďáci "normální profesionálové" ;)

To je asi dost ovlivnene tim, ze ti, kteri meni frameworky ob tyden, jsou zaroven ti, kteri jsou vic videt a slyset. Cekal bych, ze "ticha vetsina" porad bastli neco v jquery.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: v 22. 03. 2016, 13:47:08
jakýkoliv normální profesionál když vidí někde "nová technologie", tak zavře uši a nic už vědět nechce, s terminologií to nemá nic společného
No, frontenďáci jsou celí říční, aby měli každej týdej úplně novej make systém a co 14 dní jinej framework. Ale je samozřejmě otázka, jestli jsou frontenďáci "normální profesionálové" ;)
taky záleží jestli tou technologií tady je framework nebo javascript
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: alex 23. 03. 2016, 06:39:54
Wirthovy snahy vybudovat jazyk, který by svou konstrukcí vedl k přehlednému programování v praxi taky vzaly za své, přehledné programování je výsledkem vnitřní disciplíny, ne jazyka, který používáte.
A není to poněkud škoda?
Není to škoda. Reálný svět je dokonalý takový jaký je. Proto neumožňuje reálnou existenci podobných projektů.

Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: alex 23. 03. 2016, 06:50:22
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?
Nesouhlasím.

Na složitý datový model je funkcionální jazyk naprosto vyhovující. (Zda Rust, je spíše otázka stability jeho samotného, než toho, že je funkcionální.)

Dokonce jsem nabyl dojmu, že objektové programování (tak jak jej známe) a dědičnost nejsou nijak zvláště užitečné, a neosvědčilo se to.

To soudím na základě zkušeností z projektů různých úrovní složitosti i různého skillu vývojářů, ke kterými jsem kdy přišel. Ono samozřejmě vytvářet nový projekt od základu je něco jiného. Tam je to fuk, protože si všechno pamatujete. Ale přijít k existujícímu projektu a zorientovat se v tom... OOP není nutně špatné, ale výceúrovňová dědičnost vysloveně zatemňuje.

Jestli to nebude tím, že v FP se vytváří výhradně nové projekty a vše je nové, svěží a čisté. Po pár letech provozu projektu to takové nebude. Jinak FP taky obsahuje dědičnost, negativní důsledky dědičnosti v FP představuje použití funkce uvnitř funkce. Změní-li se chování té vnitřní funkce rozhodí to ne zcela odvoditelným způsobem chování jiných funkcí. Což taky zatemňuje. Závislosti mezi funkcemi jsou taky časem hodně složité a dostatečně temné.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: Mirek Prýmek 23. 03. 2016, 09:12:41
Jestli to nebude tím, že v FP se vytváří výhradně nové projekty a vše je nové, svěží a čisté. Po pár letech provozu projektu to takové nebude.
RabbitMQ je devět let starý, CouchDB 11 let, Ejabberd 14 let. Nezaznamenal jsem, že by si někdo stěžoval na codebase.

Jinak FP taky obsahuje dědičnost, negativní důsledky dědičnosti v FP představuje použití funkce uvnitř funkce.
To je asi tak jako bys řekl, že v autě je taky dědičnost a tou dědičností je šaltrpáka. Proč mást pojmy? Dědičnost je dědičnost a v FP není.

Změní-li se chování té vnitřní funkce rozhodí to ne zcela odvoditelným způsobem chování jiných funkcí. Což taky zatemňuje. Závislosti mezi funkcemi jsou taky časem hodně složité a dostatečně temné.
Pokud mám funkci add(a,b) a "+" v ní přepíšu na "-", tak se ten program samozřejmě rozbije. Proti špatně napsanému kódu mě žádné paradigma neochrání. Výhoda FP je v tom, že ty funkce bývají tak jednoduché a dobře definované, že je jasné, jestli dělají co mají nebo nedělají. U Haskellu pak mám navíc silný typový systém, který spoustu chyb odhalí.

Zamotané závislosti je samozřejmě možné napsat v jakémkoliv jazyce. Rozdíl je v tom, že v OOP se tomu prakticky nedá vyhnout, zatímco v FP se člověk musí docela snažit, aby způsobil nějaký problém. Klíčem ke guláši nejsou funkce a jejich volání, ale STAV a jeho nepřehledné změny. A v FP je stav vždycky dobře izolovaný - z principu, vynuceného jazykem, který se nedá porušit i kdyby člověk chtěl.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: Ivan Nový 23. 03. 2016, 19:32:26
Jestli to nebude tím, že v FP se vytváří výhradně nové projekty a vše je nové, svěží a čisté. Po pár letech provozu projektu to takové nebude.
RabbitMQ je devět let starý, CouchDB 11 let, Ejabberd 14 let. Nezaznamenal jsem, že by si někdo stěžoval na codebase.

Jinak FP taky obsahuje dědičnost, negativní důsledky dědičnosti v FP představuje použití funkce uvnitř funkce.
To je asi tak jako bys řekl, že v autě je taky dědičnost a tou dědičností je šaltrpáka. Proč mást pojmy? Dědičnost je dědičnost a v FP není.

Změní-li se chování té vnitřní funkce rozhodí to ne zcela odvoditelným způsobem chování jiných funkcí. Což taky zatemňuje. Závislosti mezi funkcemi jsou taky časem hodně složité a dostatečně temné.
Pokud mám funkci add(a,b) a "+" v ní přepíšu na "-", tak se ten program samozřejmě rozbije. Proti špatně napsanému kódu mě žádné paradigma neochrání. Výhoda FP je v tom, že ty funkce bývají tak jednoduché a dobře definované, že je jasné, jestli dělají co mají nebo nedělají. U Haskellu pak mám navíc silný typový systém, který spoustu chyb odhalí.

Zamotané závislosti je samozřejmě možné napsat v jakémkoliv jazyce. Rozdíl je v tom, že v OOP se tomu prakticky nedá vyhnout, zatímco v FP se člověk musí docela snažit, aby způsobil nějaký problém. Klíčem ke guláši nejsou funkce a jejich volání, ale STAV a jeho nepřehledné změny. A v FP je stav vždycky dobře izolovaný - z principu, vynuceného jazykem, který se nedá porušit i kdyby člověk chtěl.
Nemáte funkce a + b, ale funkci pocet_vyr_skladem_bez_obratu_var_3(sklad, bez_obratu_od, min_cena, max_cena), která vznikla z funkce poc_vyr_bez_obratu_var_2(sklad) pomocí filtru. A je použita na mnoha místech v aplikaci v různých více méně nespecifikovaných kontextech. Odvozeno z ní je dalších x funkcí, které vznikaly v průběhu 10 let. A to je budoucnost FP, no a nebo ještě horší varianta, každý programátor co na projektu kdy pracoval, si vytvořil tuto funkci vlastní :-)))
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: Mirek Prýmek 23. 03. 2016, 19:34:50
Nemáte funkce a + b, ale funkci pocet_vyr_skladem_bez_obratu_var_3(sklad, bez_obratu_od, min_cena, max_cena), která vznikla z funkce poc_vyr_bez_obratu_var_2(sklad) pomocí filtru. A je použita na mnoha místech v aplikaci v různých více méně nespecifikovaných kontextech. Odvozeno z ní je dalších x funkcí, které vznikaly v průběhu 10 let. A to je budoucnost FP, no a nebo ještě horší varianta, každý programátor co na projektu kdy pracoval, si vytvořil tuto funkci vlastní :-)))
To je ale naprosto v pořádku. Funkci +/2 mám taky na spoustě míst v programu. Protože na všech těch místech dělá to, co tam dělat má. Hezké je na tom právě to, že na kontextu nezáleží a záležet nesmí.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: Ivan Nový 23. 03. 2016, 20:31:06
Nemáte funkce a + b, ale funkci pocet_vyr_skladem_bez_obratu_var_3(sklad, bez_obratu_od, min_cena, max_cena), která vznikla z funkce poc_vyr_bez_obratu_var_2(sklad) pomocí filtru. A je použita na mnoha místech v aplikaci v různých více méně nespecifikovaných kontextech. Odvozeno z ní je dalších x funkcí, které vznikaly v průběhu 10 let. A to je budoucnost FP, no a nebo ještě horší varianta, každý programátor co na projektu kdy pracoval, si vytvořil tuto funkci vlastní :-)))
To je ale naprosto v pořádku. Funkci +/2 mám taky na spoustě míst v programu. Protože na všech těch místech dělá to, co tam dělat má. Hezké je na tom právě to, že na kontextu nezáleží a záležet nesmí.
Ale použijete-li v rámci nějaké funkce jinou funkci, už na tom kontextu záleží, už to samo o sobě vytváří závislost, změnou té vnitřní funkce dojde ke změně chování té vnější funkce, a to se uhlídat nedá, protože nikde nemáte uschovanou definici závislostí, což u OOP koncetptu existuje (dědičnost, privátní proměnné). Takže ano, na malé projekty s omezenou dobou životnosti může být FP přínosem. Ale co z nějakého FP projektu bude po 10 letech, to si ani nechci představovat. Pracně se to bude pak přepisovat do tříd, aby se alespoň rámcově vědělo, co s čím souvisí. FP je samo o sobě nevýhodné, ale nutné v paralelním prostředí, kdy je potřeba dosáhnout stavu, aby přirozeně vznikaly bloky kódu, jejichž provádění je na sobě časově nezávislé. A k tomu se FP naopak hodí.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: Ivan Nový 23. 03. 2016, 20:43:20
Jak se budou chovat rozsáhlé FP aplikace po mnohaletém provozu? V časově neurčitých intervalech budou kolabovat jako celek po malé úpravě, která se projeví se zpožděním, díky provázaným funkcím, se chyba bude rychle šířit aplikací a bude téměř neidentifikovatelná.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: Kit 23. 03. 2016, 20:45:09
... Pracně se to bude pak přepisovat do tříd, aby se alespoň rámcově vědělo, co s čím souvisí. FP je samo o sobě nevýhodné, ale nutné v paralelním prostředí, kdy je potřeba dosáhnout stavu, aby přirozeně vznikaly bloky kódu, jejichž provádění je na sobě časově nezávislé. A k tomu se FP naopak hodí.

Proč přepisovat do tříd? Pro udržení pořádku stačí použít namespaces.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: Ivan Nový 23. 03. 2016, 20:47:48
Nemáte funkce a + b, ale funkci pocet_vyr_skladem_bez_obratu_var_3(sklad, bez_obratu_od, min_cena, max_cena), která vznikla z funkce poc_vyr_bez_obratu_var_2(sklad) pomocí filtru. A je použita na mnoha místech v aplikaci v různých více méně nespecifikovaných kontextech. Odvozeno z ní je dalších x funkcí, které vznikaly v průběhu 10 let. A to je budoucnost FP, no a nebo ještě horší varianta, každý programátor co na projektu kdy pracoval, si vytvořil tuto funkci vlastní :-)))
To je ale naprosto v pořádku. Funkci +/2 mám taky na spoustě míst v programu. Protože na všech těch místech dělá to, co tam dělat má. Hezké je na tom právě to, že na kontextu nezáleží a záležet nesmí.
Ale použijete-li v rámci nějaké funkce jinou funkci, už na tom kontextu záleží, už to samo o sobě vytváří závislost, změnou té vnitřní funkce dojde ke změně chování té vnější funkce, a to se uhlídat nedá, protože nikde nemáte uschovanou definici závislostí, což u OOP koncetptu existuje (dědičnost, privátní proměnné). Takže ano, na malé projekty s omezenou dobou životnosti může být FP přínosem. Ale co z nějakého FP projektu bude po 10 letech, to si ani nechci představovat. Pracně se to bude pak přepisovat do tříd, aby se alespoň rámcově vědělo, co s čím souvisí. FP je samo o sobě nevýhodné, ale nutné v paralelním prostředí, kdy je potřeba dosáhnout stavu, aby přirozeně vznikaly bloky kódu, jejichž provádění je na sobě časově nezávislé. A k tomu se FP naopak hodí.
To by platilo za předpokladu, že disponujete nějakým metajazykem, který je schopen jednoznačně a přesně posat sémantický obsah funkce, u + se vám to podaří, ale u funkcí se sémantickými přesahy to možné nebude. Každý člověk bude mít vlastní představu o tom, co dělají a nebo by měly dělat.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: Kit 23. 03. 2016, 20:50:28
Jak se budou chovat rozsáhlé FP aplikace po mnohaletém provozu? V časově neurčitých intervalech budou kolabovat jako celek po malé úpravě, která se projeví se zpožděním, díky provázaným funkcím, se chyba bude rychle šířit aplikací a bude téměř neidentifikovatelná.

Totéž platí i pro OOP. Opět se dostáváme k tomu, že když je programátor prase, tak zašmodrchá OOP i FP.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: Kit 23. 03. 2016, 20:54:20
To by platilo za předpokladu, že disponujete nějakým metajazykem, který je schopen jednoznačně a přesně posat sémantický obsah funkce, u + se vám to podaří, ale u funkcí se sémantickými přesahy to možné nebude. Každý člověk bude mít vlastní představu o tom, co dělají a nebo by měly dělat.

On snad někdo programuje nesémanticky? Sémantika se obvykle dává do názvu namespace+funkce.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: Ivan Nový 23. 03. 2016, 20:57:17
... Pracně se to bude pak přepisovat do tříd, aby se alespoň rámcově vědělo, co s čím souvisí. FP je samo o sobě nevýhodné, ale nutné v paralelním prostředí, kdy je potřeba dosáhnout stavu, aby přirozeně vznikaly bloky kódu, jejichž provádění je na sobě časově nezávislé. A k tomu se FP naopak hodí.

Proč přepisovat do tříd? Pro udržení pořádku stačí použít namespaces.
Nestačí. a je to nepraktické, povede to k zápisům:
let m = (sklad.brno.koje.zasuvka.mnozstvi.sum(id=11) - sklad.praha.koje.zasuvka.mnosztvi.sum(id=11)) * cenik.nakupni.(id=11, kat=katalog.filter(podminka.cenik.obdobi(12))) :-)))
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: JSH 23. 03. 2016, 20:57:42
Nemáte funkce a + b, ale funkci pocet_vyr_skladem_bez_obratu_var_3(sklad, bez_obratu_od, min_cena, max_cena), která vznikla z funkce poc_vyr_bez_obratu_var_2(sklad) pomocí filtru. A je použita na mnoha místech v aplikaci v různých více méně nespecifikovaných kontextech. Odvozeno z ní je dalších x funkcí, které vznikaly v průběhu 10 let. A to je budoucnost FP, no a nebo ještě horší varianta, každý programátor co na projektu kdy pracoval, si vytvořil tuto funkci vlastní :-)))
To je ale naprosto v pořádku. Funkci +/2 mám taky na spoustě míst v programu. Protože na všech těch místech dělá to, co tam dělat má. Hezké je na tom právě to, že na kontextu nezáleží a záležet nesmí.
Ale použijete-li v rámci nějaké funkce jinou funkci, už na tom kontextu záleží, už to samo o sobě vytváří závislost, změnou té vnitřní funkce dojde ke změně chování té vnější funkce, a to se uhlídat nedá, protože nikde nemáte uschovanou definici závislostí, což u OOP koncetptu existuje (dědičnost, privátní proměnné). Takže ano, na malé projekty s omezenou dobou životnosti může být FP přínosem. Ale co z nějakého FP projektu bude po 10 letech, to si ani nechci představovat. Pracně se to bude pak přepisovat do tříd, aby se alespoň rámcově vědělo, co s čím souvisí. FP je samo o sobě nevýhodné, ale nutné v paralelním prostředí, kdy je potřeba dosáhnout stavu, aby přirozeně vznikaly bloky kódu, jejichž provádění je na sobě časově nezávislé. A k tomu se FP naopak hodí.
Tohle ale přece není vůbec kritika omezená na FP. Naprosto stejně může někdo rozbít vnitřnosti nějaké třídy a rozbije tím i třídy, které je používají. V jakémkoliv paradigmatu se to rozbije úplně stejně. Tomuhle dokážou zabránit třeba unittesty, ale ty zase nejsou nijak omezené na použité paradigma.

Uchází mi něco?
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: JSH 23. 03. 2016, 21:03:42
Nestačí. a je to nepraktické, povede to k zápisům:
let m = (sklad.brno.koje.zasuvka.mnozstvi.sum(id=11) - sklad.praha.koje.zasuvka.mnosztvi.sum(id=11)) * cenik.nakupni.(id=11, kat=katalog.filter(podminka.cenik.obdobi(12))) :-)))
Začínám mít nepříjemný popis, že si pod funkcionálním programováním představujete nějaký špagetový procedurální zprasek, který mimochodem používá funkce. Jinak nechápu, proč sem taháte takovouhle zběsilost. U FP to ani neleželo.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: Ivan Nový 23. 03. 2016, 21:03:52
To by platilo za předpokladu, že disponujete nějakým metajazykem, který je schopen jednoznačně a přesně posat sémantický obsah funkce, u + se vám to podaří, ale u funkcí se sémantickými přesahy to možné nebude. Každý člověk bude mít vlastní představu o tom, co dělají a nebo by měly dělat.

On snad někdo programuje nesémanticky? Sémantika se obvykle dává do názvu namespace+funkce.
No malý problém je v tom, že dva lidé se málokdy shodnou na sémantickém obsahu čehokoliv. Takže těžko dohlédnou důsledky jen malé změny, nějaké funkce. U OOP u metody alespoň víte, na jaký objekt je její platnost omezena, její sémantika je fixována na objekt, naproti tomu funkce se může v aplikaci vyskytovat kdekoliv, a co je horší, v kontextech s rozdílným či jen posunutým sémantickým obsahem. Když funkci upravíte tak, aby vyhovola jednomu, vzdálí se od druhého, to naruší rovnováhu a vzniknou chyby, které budete jen těžko hledat.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: Ivan Nový 23. 03. 2016, 21:06:18
Jak se budou chovat rozsáhlé FP aplikace po mnohaletém provozu? V časově neurčitých intervalech budou kolabovat jako celek po malé úpravě, která se projeví se zpožděním, díky provázaným funkcím, se chyba bude rychle šířit aplikací a bude téměř neidentifikovatelná.

Totéž platí i pro OOP. Opět se dostáváme k tomu, že když je programátor prase, tak zašmodrchá OOP i FP.
Ano, samozřejmě, žádné samospásné koncepty neexistují.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: Ivan Nový 23. 03. 2016, 21:10:22
Nemáte funkce a + b, ale funkci pocet_vyr_skladem_bez_obratu_var_3(sklad, bez_obratu_od, min_cena, max_cena), která vznikla z funkce poc_vyr_bez_obratu_var_2(sklad) pomocí filtru. A je použita na mnoha místech v aplikaci v různých více méně nespecifikovaných kontextech. Odvozeno z ní je dalších x funkcí, které vznikaly v průběhu 10 let. A to je budoucnost FP, no a nebo ještě horší varianta, každý programátor co na projektu kdy pracoval, si vytvořil tuto funkci vlastní :-)))
To je ale naprosto v pořádku. Funkci +/2 mám taky na spoustě míst v programu. Protože na všech těch místech dělá to, co tam dělat má. Hezké je na tom právě to, že na kontextu nezáleží a záležet nesmí.
Ale použijete-li v rámci nějaké funkce jinou funkci, už na tom kontextu záleží, už to samo o sobě vytváří závislost, změnou té vnitřní funkce dojde ke změně chování té vnější funkce, a to se uhlídat nedá, protože nikde nemáte uschovanou definici závislostí, což u OOP koncetptu existuje (dědičnost, privátní proměnné). Takže ano, na malé projekty s omezenou dobou životnosti může být FP přínosem. Ale co z nějakého FP projektu bude po 10 letech, to si ani nechci představovat. Pracně se to bude pak přepisovat do tříd, aby se alespoň rámcově vědělo, co s čím souvisí. FP je samo o sobě nevýhodné, ale nutné v paralelním prostředí, kdy je potřeba dosáhnout stavu, aby přirozeně vznikaly bloky kódu, jejichž provádění je na sobě časově nezávislé. A k tomu se FP naopak hodí.
Tohle ale přece není vůbec kritika omezená na FP. Naprosto stejně může někdo rozbít vnitřnosti nějaké třídy a rozbije tím i třídy, které je používají. V jakémkoliv paradigmatu se to rozbije úplně stejně. Tomuhle dokážou zabránit třeba unittesty, ale ty zase nejsou nijak omezené na použité paradigma.

Uchází mi něco?
Rozsah škod u FP bude ale větší právě proto, že funkce nejsou vázány na nějaký pevně daný kontext, není zachován řetěz dědičnosti, to která funkce uvnitř používá kterou funkci není nějak explicitně zaznamenáno, spontánně vzniklé struktury závislostí budou daleko složitější.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: JSH 23. 03. 2016, 21:18:45
To by platilo za předpokladu, že disponujete nějakým metajazykem, který je schopen jednoznačně a přesně posat sémantický obsah funkce, u + se vám to podaří, ale u funkcí se sémantickými přesahy to možné nebude. Každý člověk bude mít vlastní představu o tom, co dělají a nebo by měly dělat.

On snad někdo programuje nesémanticky? Sémantika se obvykle dává do názvu namespace+funkce.
No malý problém je v tom, že dva lidé se málokdy shodnou na sémantickém obsahu čehokoliv. Takže těžko dohlédnou důsledky jen malé změny, nějaké funkce. U OOP u metody alespoň víte, na jaký objekt je její platnost omezena, její sémantika je fixována na objekt, naproti tomu funkce se může v aplikaci vyskytovat kdekoliv, a co je horší, v kontextech s rozdílným či jen posunutým sémantickým obsahem. Když funkci upravíte tak, aby vyhovola jednomu, vzdálí se od druhého, to naruší rovnováhu a vzniknou chyby, které budete jen těžko hledat.
Takhle se ale funkce v FP nechovají. Tam je jejich působnost omezená jen na to, co dostanou jako parametry.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: Ondra Satai Nekola 23. 03. 2016, 21:28:14
Rozsah škod u FP bude ale větší právě proto, že funkce nejsou vázány na nějaký pevně daný kontext, není zachován řetěz dědičnosti, to která funkce uvnitř používá kterou funkci není nějak explicitně zaznamenáno, spontánně vzniklé struktury závislostí budou daleko složitější.

Clovece, ty musis byt umelecky projekt ztohoven.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: v 23. 03. 2016, 21:33:27
Nemáte funkce a + b, ale funkci pocet_vyr_skladem_bez_obratu_var_3(sklad, bez_obratu_od, min_cena, max_cena), která vznikla z funkce poc_vyr_bez_obratu_var_2(sklad) pomocí filtru. A je použita na mnoha místech v aplikaci v různých více méně nespecifikovaných kontextech. Odvozeno z ní je dalších x funkcí, které vznikaly v průběhu 10 let. A to je budoucnost FP, no a nebo ještě horší varianta, každý programátor co na projektu kdy pracoval, si vytvořil tuto funkci vlastní :-)))
To je ale naprosto v pořádku. Funkci +/2 mám taky na spoustě míst v programu. Protože na všech těch místech dělá to, co tam dělat má. Hezké je na tom právě to, že na kontextu nezáleží a záležet nesmí.
Ale použijete-li v rámci nějaké funkce jinou funkci, už na tom kontextu záleží, už to samo o sobě vytváří závislost, změnou té vnitřní funkce dojde ke změně chování té vnější funkce, a to se uhlídat nedá, protože nikde nemáte uschovanou definici závislostí, což u OOP koncetptu existuje (dědičnost, privátní proměnné). Takže ano, na malé projekty s omezenou dobou životnosti může být FP přínosem. Ale co z nějakého FP projektu bude po 10 letech, to si ani nechci představovat. Pracně se to bude pak přepisovat do tříd, aby se alespoň rámcově vědělo, co s čím souvisí. FP je samo o sobě nevýhodné, ale nutné v paralelním prostředí, kdy je potřeba dosáhnout stavu, aby přirozeně vznikaly bloky kódu, jejichž provádění je na sobě časově nezávislé. A k tomu se FP naopak hodí.
Tohle ale přece není vůbec kritika omezená na FP. Naprosto stejně může někdo rozbít vnitřnosti nějaké třídy a rozbije tím i třídy, které je používají. V jakémkoliv paradigmatu se to rozbije úplně stejně. Tomuhle dokážou zabránit třeba unittesty, ale ty zase nejsou nijak omezené na použité paradigma.

Uchází mi něco?
Rozsah škod u FP bude ale větší právě proto, že funkce nejsou vázány na nějaký pevně daný kontext, není zachován řetěz dědičnosti, to která funkce uvnitř používá kterou funkci není nějak explicitně zaznamenáno, spontánně vzniklé struktury závislostí budou daleko složitější.
třída "používá" jenom své předky?
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: Ivan Nový 23. 03. 2016, 21:58:13
Nemáte funkce a + b, ale funkci pocet_vyr_skladem_bez_obratu_var_3(sklad, bez_obratu_od, min_cena, max_cena), která vznikla z funkce poc_vyr_bez_obratu_var_2(sklad) pomocí filtru. A je použita na mnoha místech v aplikaci v různých více méně nespecifikovaných kontextech. Odvozeno z ní je dalších x funkcí, které vznikaly v průběhu 10 let. A to je budoucnost FP, no a nebo ještě horší varianta, každý programátor co na projektu kdy pracoval, si vytvořil tuto funkci vlastní :-)))
To je ale naprosto v pořádku. Funkci +/2 mám taky na spoustě míst v programu. Protože na všech těch místech dělá to, co tam dělat má. Hezké je na tom právě to, že na kontextu nezáleží a záležet nesmí.
Ale použijete-li v rámci nějaké funkce jinou funkci, už na tom kontextu záleží, už to samo o sobě vytváří závislost, změnou té vnitřní funkce dojde ke změně chování té vnější funkce, a to se uhlídat nedá, protože nikde nemáte uschovanou definici závislostí, což u OOP koncetptu existuje (dědičnost, privátní proměnné). Takže ano, na malé projekty s omezenou dobou životnosti může být FP přínosem. Ale co z nějakého FP projektu bude po 10 letech, to si ani nechci představovat. Pracně se to bude pak přepisovat do tříd, aby se alespoň rámcově vědělo, co s čím souvisí. FP je samo o sobě nevýhodné, ale nutné v paralelním prostředí, kdy je potřeba dosáhnout stavu, aby přirozeně vznikaly bloky kódu, jejichž provádění je na sobě časově nezávislé. A k tomu se FP naopak hodí.
Tohle ale přece není vůbec kritika omezená na FP. Naprosto stejně může někdo rozbít vnitřnosti nějaké třídy a rozbije tím i třídy, které je používají. V jakémkoliv paradigmatu se to rozbije úplně stejně. Tomuhle dokážou zabránit třeba unittesty, ale ty zase nejsou nijak omezené na použité paradigma.

Uchází mi něco?
Rozsah škod u FP bude ale větší právě proto, že funkce nejsou vázány na nějaký pevně daný kontext, není zachován řetěz dědičnosti, to která funkce uvnitř používá kterou funkci není nějak explicitně zaznamenáno, spontánně vzniklé struktury závislostí budou daleko složitější.
třída "používá" jenom své předky?

Prakticky ano, když pošlete zprávu do nějakého objektu, neovlivní to objekt, který zprávu vyslal, třída z jiného objektu převezme jen stav, který umí zpracovat, cokoliv jiného vyvolá chybu.

V FP při řetězení funkcí map, filter, reduce chyba častěji než u OOP projde do dalšího kroku, asi tak, jako když na montážním pásu, kde montují automobily, zapomenou namontovat kliku u dveří. V jednom kontextu to vadit nebude, v jiném ano.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: JSH 23. 03. 2016, 22:05:22
Prakticky ano, když pošlete zprávu do nějakého objektu, neovlivní to objekt, který zprávu vyslal, třída z jiného objektu převezme jen stav, který umí zpracovat, cokoliv jiného vyvolá chybu.

V FP při řetězení funkcí map, filter, reduce chyba častěji než u OOP projde do dalšího kroku, asi tak, jako když na montážním pásu, kde montují automobily, zapomenou namontovat kliku u dveří. V jednom kontextu to vadit nebude, v jiném ano.
To už jsou tak vágní žvásty, že už to dokonce přestává být i špatně.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: v 23. 03. 2016, 22:12:01
Prakticky ano, když pošlete zprávu do nějakého objektu, neovlivní to objekt, který zprávu vyslal, třída z jiného objektu převezme jen stav, který umí zpracovat, cokoliv jiného vyvolá chybu.

V FP při řetězení funkcí map, filter, reduce chyba častěji než u OOP projde do dalšího kroku, asi tak, jako když na montážním pásu, kde montují automobily, zapomenou namontovat kliku u dveří. V jednom kontextu to vadit nebude, v jiném ano.
To už jsou tak vágní žvásty, že už to dokonce přestává být i špatně.
http://rationalwiki.org/wiki/Fractal_wrongness
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: v 23. 03. 2016, 22:15:49

Prakticky ano, když pošlete zprávu do nějakého objektu, neovlivní to objekt, který zprávu vyslal, třída z jiného objektu převezme jen stav, který umí zpracovat, cokoliv jiného vyvolá chybu.
tak např. musí třída dědit od třídy string aby ji mohla "použít"?

V FP při řetězení funkcí map, filter, reduce chyba častěji než u OOP projde do dalšího kroku, asi tak, jako když na montážním pásu, kde montují automobily, zapomenou namontovat kliku u dveří. V jednom kontextu to vadit nebude, v jiném ano.
z čeho odvozujete, že k tomu dojde častěji? v praktickém FP může i funkce vyvolat výjimku, kde se to liší od praktického OOP?
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: BoneFlute 23. 03. 2016, 22:25:23
Ale použijete-li v rámci nějaké funkce jinou funkci, už na tom kontextu záleží, už to samo o sobě vytváří závislost, změnou té vnitřní funkce dojde ke změně chování té vnější funkce
To není specifikum FP.

a to se uhlídat nedá
Ale dá, existují na to různé přístupy, například testování. (Předpokládám, že narážíte na situaci, kdy někdo změní chování funkce.)
A opět, to není specifikum FP. V OOP je to taky, a mnohem horší, protože se tam toho musí hlídat mnohem více.

protože nikde nemáte uschovanou definici závislostí
máme, jmenuje se to closure

což u OOP koncetptu existuje (dědičnost, privátní proměnné).
což nesouvisí se závislostmi, ale s mutabilitou.

Pracně se to bude pak přepisovat do tříd, aby se alespoň rámcově vědělo, co s čím souvisí.
Blbé je, že čím více a více získávám zkušeností z praxe, tím více OOP ohejbám do FP. Takže vaše odvážné tvrzení nemohu potvrdit.

Mimochodem nejsou třídy jako třídy, viz Haskell :-P
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: BoneFlute 23. 03. 2016, 22:31:55
Rozsah škod u FP bude ale větší právě proto, že funkce nejsou vázány na nějaký pevně daný kontext, není zachován řetěz dědičnosti, to která funkce uvnitř používá kterou funkci není nějak explicitně zaznamenáno, spontánně vzniklé struktury závislostí budou daleko složitější.
To je divný, nic z toho nepozoruji.

to která funkce uvnitř používá kterou funkci není nějak explicitně zaznamenáno
Hele, uvědomujete si, že základem FP je imutabilita, tudíž řešit něco takového je prostě absurdně zbytečné?

Když umíte tak šikovně popsat katastrofické scénáře které díky FP proběhnou, uveďte alespoň nějaký příklad toho, kdy by vámi uváděný problém mohl vzniknout.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: BoneFlute 23. 03. 2016, 22:39:26
Prakticky ano, když pošlete zprávu do nějakého objektu, neovlivní to objekt, který zprávu vyslal
Tak pokud ta zpráva nevrací výsledek (u klasických OOP jazyků věc nevýdaná), tak máte pravdu.
Stejně jako funkce, která je volána jinou funkcí není ovlivněná volanou funkcí.

třída z jiného objektu převezme jen stav, který umí zpracovat, cokoliv jiného vyvolá chybu.
ve FP je to stejné, funkce převezme jen parametry které umí zpracovat, cokoliv jiného vyvolá chybu.

A?

V FP při řetězení funkcí map, filter, reduce chyba častěji než u OOP projde do dalšího kroku, asi tak, jako když na montážním pásu, kde montují automobily, zapomenou namontovat kliku u dveří. V jednom kontextu to vadit nebude, v jiném ano.
Nedovedu si představit, proč by tento problém nemohl vzniknout při zřetězení objektů.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: atarist 23. 03. 2016, 22:39:57
Rozsah škod u FP bude ale větší právě proto, že funkce nejsou vázány na nějaký pevně daný kontext, není zachován řetěz dědičnosti, to která funkce uvnitř používá kterou funkci není nějak explicitně zaznamenáno, spontánně vzniklé struktury závislostí budou daleko složitější.

Nevim, jak je to mozny, ale vzdycky podle Tveho slohu po max. deseti slovech poznam, ze jsi to psal ty :)
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: Pavel Tisnovsky 23. 03. 2016, 22:51:16
Ale použijete-li v rámci nějaké funkce jinou funkci, už na tom kontextu záleží, už to samo o sobě vytváří závislost, změnou té vnitřní funkce dojde ke změně chování té vnější funkce, a to se uhlídat nedá, protože nikde nemáte uschovanou definici závislostí, což u OOP koncetptu existuje (dědičnost, privátní proměnné). Takže ano, na malé projekty s omezenou dobou životnosti může být FP přínosem. Ale co z nějakého FP projektu bude po 10 letech, to si ani nechci představovat. Pracně se to bude pak přepisovat do tříd, aby se alespoň rámcově vědělo, co s čím souvisí. FP je samo o sobě nevýhodné, ale nutné v paralelním prostředí, kdy je potřeba dosáhnout stavu, aby přirozeně vznikaly bloky kódu, jejichž provádění je na sobě časově nezávislé. A k tomu se FP naopak hodí.

To je ale úplně stejné (vlastně horší) v třídním i netřídním OOP že? Když mě někdo pod rukama změní dejme tomu String.substring tak, že se specifikují znaky od-do "včetně" (ne "kromě" u horního indexu), tak to prostě rozhodí veškerej kód, který počítá s původním chováním. Potom to buď mám pokryté testy nebo nemám, ale to není závislé na paradigmatu (u FP to však je samozřejmě jednodušší).

Btw sice uznávám, že Lisp a Scheme nejsou čisté FP jazyky, ale projekty v nich existují, a mnohé z nich *běží* delší dobu, než je životnost mnohých dnešních OOP jazyků.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: Mirek Prýmek 23. 03. 2016, 23:22:58
Ale použijete-li v rámci nějaké funkce jinou funkci, už na tom kontextu záleží
Ne, nezáleží na kontextu, nemaťme pojmy. Funkce f aplikovaná kdekoli na stejné argumenty dává stejný výsledek. To je princip FP a jeho hlavní deviza. U různých FP jazyků je to různě striktně dodržováno, ale v principu se to dodržuje všude, kde není pádný důvod to nedodržovat.

, už to samo o sobě vytváří závislost, změnou té vnitřní funkce dojde ke změně chování té vnější funkce, a to se uhlídat nedá, protože nikde nemáte uschovanou definici závislostí, což u OOP koncetptu existuje
Neexistuje. V OOP nikde nemáte mapu, že metoda M1 objektu O1 používá metodu M4 objektu 04, pokud si ji nějakým spešl toolem nevygenerujete z AST.

Vezměte si libovolný středně velký OOP projekt určený pro jednovláknový běh, na pět náhodně vybraných míst dejte nějaký ten skok do jiného vlákna a celé to pusťte na sto vláknech. Jestli dokážete předem přesně identifikovat místa, na kterých může dojít k nějakému problému, tak jste buď geniální, nebo lžete. Spíš ale lžete :) Abyste to udělal, musíte ten kód kompletně projít, analyzovat si stromy volání a pravděpodobný výsledek bude, že všechno v důsledku volá všechno, takže problém může nastat kdekoli.

Čili u OOP i FP máme jeden společný pseudoproblém "když změním chování fce, tak se změní chování fce" a navíc má OOP jeden megaproblém, na který se v praxi naráží.

Erlangovský program můžu spustit na kolika chci vláknech a nestane se vůbec nic. Protože neexistuje způsob, jak by si procesy mohly do stavů šahat. Prostě není. Funkce přijímají data a vrací data, sdílená data neexistují (kromě databáze) a s procesy se komunikuje výhradně zprávami.

Ale co z nějakého FP projektu bude po 10 letech, to si ani nechci představovat.
To není potřeba si představovat, stačí se podívat na ejabberd. Je z něj po (více než) deseti letech jeden z nejúspěšnějších jabber serverů (ne-li úplně nejúspěšnější).
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: Pavel Tisnovsky 24. 03. 2016, 00:01:24

To není potřeba si představovat, stačí se podívat na ejabberd. Je z něj po (více než) deseti letech jeden z nejúspěšnějších jabber serverů (ne-li úplně nejúspěšnější).

Z komercnich veci pak napriklad ITA, ti maji codebase starou dvacet let, stale upravuji, stale funguji (neni to ciste FP, stejne jako naprosta vetsina  OOP kodu neni ciste OOP).
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: Ivan Nový 24. 03. 2016, 08:10:21

To není potřeba si představovat, stačí se podívat na ejabberd. Je z něj po (více než) deseti letech jeden z nejúspěšnějších jabber serverů (ne-li úplně nejúspěšnější).

Z komercnich veci pak napriklad ITA, ti maji codebase starou dvacet let, stale upravuji, stale funguji (neni to ciste FP, stejne jako naprosta vetsina  OOP kodu neni ciste OOP).

Ano, ale to je aplikační doména, která je dostatečně abstraktní na to, aby to šlo naprogramovat elegantně. Je to svět sám pro sebe, vytvořený tvůrci toho projektu. Zajímavé bude sledovat, jak se to osvědčí v prostředí modelování reálných firemních procesů a nelogických požadavků na úpravy, mimo logiku aplikace, které v tomto prostředí běžně vznikají.

Osobně proti FP nic nemám, celkem mi toto paradigma vyhovuje, ale pořádek v kódu bych si od něj automaticky nesliboval. Samozřejmě nejlepší na něm je vazba na teorii kategorií.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: Pavel Tisnovsky 24. 03. 2016, 17:42:47

To není potřeba si představovat, stačí se podívat na ejabberd. Je z něj po (více než) deseti letech jeden z nejúspěšnějších jabber serverů (ne-li úplně nejúspěšnější).

Z komercnich veci pak napriklad ITA, ti maji codebase starou dvacet let, stale upravuji, stale funguji (neni to ciste FP, stejne jako naprosta vetsina  OOP kodu neni ciste OOP).

Ano, ale to je aplikační doména, která je dostatečně abstraktní na to, aby to šlo naprogramovat elegantně. Je to svět sám pro sebe, vytvořený tvůrci toho projektu. Zajímavé bude sledovat, jak se to osvědčí v prostředí modelování reálných firemních procesů a nelogických požadavků na úpravy, mimo logiku aplikace, které v tomto prostředí běžně vznikají.

Osobně proti FP nic nemám, celkem mi toto paradigma vyhovuje, ale pořádek v kódu bych si od něj automaticky nesliboval. Samozřejmě nejlepší na něm je vazba na teorii kategorií.

No dal jsem realny priklad dlouhodobeho projektu, na ktery byl dotaz :)

Jinak ja FP pouzivam presne na "modelování reálných firemních procesů a nelogických požadavků na úprav", protoze mi to umoznuje rapid turnaround. Nejsou tam hodnotove objekty, "jen" mapy/vektory/mnoziny, takze u uprav nehrozi nutnost masivniho refaktoringu (ostatne i celkove je kod o dost kratsi). Otestovani se da udelat prakticky nazivo upravou bezici aplikace (to neni vlastnost FP, spis konkretniho jazyka), dobre se to testuje. Kdyz potrebuji pro nejake hodnoty constraints, tak se to proste implementuje funkci - predikatem - ktera si to pohlida.

A navic - takova relacni databaze, na kterych je velka cast businessu postavena - a tyto databaze (zejmena ty s SQL) maji k FP mozna ponekud prekvapive velmi blizko.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: Mirek Prýmek 24. 03. 2016, 19:07:57
Otestovani se da udelat prakticky nazivo upravou bezici aplikace (to neni vlastnost FP, spis konkretniho jazyka)
Není to sice vlastnost FP, ale docela to s tím souvisí - u FP jazyků se to dá určitě udělat snadněji, čistěji a s lepšími garancemi. Excelentně udělaný erlangovský hot swap hodně využívá toho, že ví, který proces právě leze do kterého kódu, může ho pozastavit a kód mu vyměnit před nosem :) a taky že neexistují žádné reference na data. Dokonce v paměti může držet dvě verze jednoho modulu (aktuální a předchozí). To je v jiném prostředí dost těžko představitelné, že by se něco takového dalo udělat čistě.

Btw, na wiki se píše
Citace
Only a few programming languages support hot swapping natively, including Pike, Lisp, Erlang, Smalltalk, Visual Basic 6 (Not VB.net), Java and most recently Elm and Elixir.
Zajímalo by mě, jestli je to úplný výčet a jak dobře to který jazyk má zmáknuté.
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: Lama 24. 03. 2016, 22:04:09
Rozsah škod u FP bude ale větší právě proto, že funkce nejsou vázány na nějaký pevně daný kontext, není zachován řetěz dědičnosti, to která funkce uvnitř používá kterou funkci není nějak explicitně zaznamenáno, spontánně vzniklé struktury závislostí budou daleko složitější.

Clovece, ty musis byt umelecky projekt ztohoven.

Já bych to tipoval na nějaký nový generátor flamu, anebo to sem pustil Microshit a testuje tu novou verzi Tay:
http://www.zive.cz/bleskovky/microsoft-vypustil-na-twitter-robota-jmenuje-se-tay-a-odpovi-vam/sc-4-a-181841/default.aspx
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: Lama 24. 03. 2016, 22:16:33
Kde sou ty časy, když sem chodil Lenin (kde vůbec je?). To mělo aspoň nějakou úroveň. Nebo Slávek Ponkrác. To byly časy. Ba ba, bejvávalo. Teď už jen čekám, kdy se tu objeví Chocholoušek...
Název: Re:Rust vs. C++ (funkcionální vs. OOP)
Přispěvatel: Radek Miček 24. 03. 2016, 22:36:36
Btw, na wiki se píše
Citace
Only a few programming languages support hot swapping natively, including Pike, Lisp, Erlang, Smalltalk, Visual Basic 6 (Not VB.net), Java and most recently Elm and Elixir.
Zajímalo by mě, jestli je to úplný výčet a jak dobře to který jazyk má zmáknuté.

Otázkou je, zda to je vlastnost jazyka nebo implementace.

Některé Prology mají hot swap - třeba SWI (http://www.swi-prolog.org/pldoc/man?section=loadrunningcode). V principu to jde třeba i v .NET Frameworku - například se používá Edit & Continue nebo viz Shadow Copying Assemblies (https://msdn.microsoft.com/en-us/library/ms404279.aspx).