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

Ivan Nový

Re:Rust vs. C++ (funkcionální vs. OOP)
« Odpověď #105 kdy: 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.


zboj

  • *****
  • 1 507
    • Zobrazit profil
    • E-mail
Re:Rust vs. C++ (funkcionální vs. OOP)
« Odpověď #106 kdy: 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.

Ivan Nový

Re:Rust vs. C++ (funkcionální vs. OOP)
« Odpověď #107 kdy: 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?

JSH

Re:Rust vs. C++ (funkcionální vs. OOP)
« Odpověď #108 kdy: 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

Ivan Nový

Re:Rust vs. C++ (funkcionální vs. OOP)
« Odpověď #109 kdy: 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í.


JSH

Re:Rust vs. C++ (funkcionální vs. OOP)
« Odpověď #110 kdy: 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.

Ivan Nový

Re:Rust vs. C++ (funkcionální vs. OOP)
« Odpověď #111 kdy: 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

atarist

Re:Rust vs. C++ (funkcionální vs. OOP)
« Odpověď #112 kdy: 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"?

Ivan Nový

Re:Rust vs. C++ (funkcionální vs. OOP)
« Odpověď #113 kdy: 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 :-)

JSH

Re:Rust vs. C++ (funkcionální vs. OOP)
« Odpověď #114 kdy: 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.

zboj

  • *****
  • 1 507
    • Zobrazit profil
    • E-mail
Re:Rust vs. C++ (funkcionální vs. OOP)
« Odpověď #115 kdy: 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?

Ivan Nový

Re:Rust vs. C++ (funkcionální vs. OOP)
« Odpověď #116 kdy: 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ů.

JSH

Re:Rust vs. C++ (funkcionální vs. OOP)
« Odpověď #117 kdy: 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.

Ivan Nový

Re:Rust vs. C++ (funkcionální vs. OOP)
« Odpověď #118 kdy: 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.

Re:Rust vs. C++ (funkcionální vs. OOP)
« Odpověď #119 kdy: 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