Co si myslíte o OOP?

Kiwi

Re:co si myslite o oop?
« Odpověď #60 kdy: 23. 12. 2018, 18:46:16 »
Podle mě se v tom strašně pipláte. Z praktického pohledu mě nikdy nenapadlo nad tím tak dumat. Jen vnímám rozdíly, resp. to, co mě irituje jinde. Mě vůbec připadá, že se tady strašně teoretizuje, místo aby si lidi prakticky zkusili A, pak B a pak řešili, v čem se jim dělá lépe.
Ne, tohle není žádná teoretická onanie. Má to konkrétní (tragické) důsledky. Ten asi nejhorší ze všech je, že když máš posílání zpráv implementované (jednoduše) jako volání metod, tak při vícevláknovém zpracování ti vznikají race conditions. Což je přesně to, co to dnešní praseOOP dostává do kolen. A co by se nemohlo stát, kdyby se tyhle dvě věci nemíchaly.

Je to velice praktická věc, akorát ten "teoretický" problém jako příčinu ne každý vidí, protože prostě nic jinýho neviděl, nezažil. Proto bych každýmu fakt vřele doporučoval si zkusit ten Elixir, aby mu to mohlo docvaknout. Zprávy jsou zprávy, mají se posílat do inboxu, odtud vybírat a (dle libovůle) zpracovávat. Žádný nesmysly typu vlákno Pes teď vlezlo do třídy Kočka. Pes je pes a kočka je kočka. Stačí to jenom nemíchat, tak snadné to je :)
Tohle mi připadá jako opačný extrém.


Martin

Re:co si myslite o oop?
« Odpověď #61 kdy: 23. 12. 2018, 19:07:57 »
Rozdíl je hlavně v tom, že poslání zprávy a volání funkce je úplně něco jiného. C++ to pomíchalo a lidi to přestali rozlišovat.
Poslani synchronni zpravy a volani funkce je to same. Nebo preferujete asynchronni posilani zprav, kazdy obekt s vlastnim vlaknem, handlerem a obrovskym balastem navic? Prijde Vam soucasny SW prilis optimalizovany, chcete ho jeste viz zpomalit?

Re:co si myslite o oop?
« Odpověď #62 kdy: 23. 12. 2018, 19:21:55 »
Poslani synchronni zpravy a volani funkce je to same.
V jakém smyslu?

Nebo preferujete asynchronni posilani zprav, kazdy obekt s vlastnim vlaknem, handlerem a obrovskym balastem navic?
Není potřeba vlastní vlákno. Nevím, co si mám představit pod handlerem. Jaký "obrovský balast"?

Kadet

Re:co si myslite o oop?
« Odpověď #63 kdy: 23. 12. 2018, 19:46:51 »
Poslani synchronni zpravy a volani funkce je to same.
V jakém smyslu?

Nebo preferujete asynchronni posilani zprav, kazdy obekt s vlastnim vlaknem, handlerem a obrovskym balastem navic?
Není potřeba vlastní vlákno. Nevím, co si mám představit pod handlerem. Jaký "obrovský balast"?

Volani funkce a synchronni poslani zpravy, tj. zaslani pozadavku a obdrzeni odpovedi, jsou skutecne totez, pokue je to v ramci programovaciho jazyka.

Vlakno je pouze abstrakce. Muze byt tezkopadne jako unix nebo nt vlakno s velkym stackem, nebo velmi lehka abstrakce v pripade green threadingu.

Ale z pohledu actor systemu bezi kazdy agent ve svem vlakne.

Martin

Re:co si myslite o oop?
« Odpověď #64 kdy: 23. 12. 2018, 21:19:37 »
Vlakno je pouze abstrakce. Muze byt tezkopadne jako unix nebo nt vlakno s velkym stackem, nebo velmi lehka abstrakce v pripade green threadingu.
Ale z pohledu actor systemu bezi kazdy agent ve svem vlakne.
Green threading? A jsme zpet u kooperativniho multitaskingu jako ve win 3.11. A neni nejlepsi cely ten balast zahodit a rovnou zavolat metodu?


Bacsa

Re:co si myslite o oop?
« Odpověď #65 kdy: 23. 12. 2018, 21:26:04 »
Vlakno je pouze abstrakce. Muze byt tezkopadne jako unix nebo nt vlakno s velkym stackem, nebo velmi lehka abstrakce v pripade green threadingu.
Ale z pohledu actor systemu bezi kazdy agent ve svem vlakne.
Green threading? A jsme zpet u kooperativniho multitaskingu
Go má kooperativní scheduler a jak skvěle šlape...

Martin

Re:co si myslite o oop?
« Odpověď #66 kdy: 23. 12. 2018, 21:34:08 »
Go má kooperativní scheduler a jak skvěle šlape...
Jiste, na dnesnich CPU bezi rychle vsechno. Ale mohlo by i rychleji.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/go-gpp.html

Bacsa

Re:co si myslite o oop?
« Odpověď #67 kdy: 23. 12. 2018, 21:52:23 »
Go má kooperativní scheduler a jak skvěle šlape...
Jiste, na dnesnich CPU bezi rychle vsechno. Ale mohlo by i rychleji.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/go-gpp.html
Debilně napsaný kód bude vždy pomalejší. Vypovídací hodnota nula.

Re:co si myslite o oop?
« Odpověď #68 kdy: 23. 12. 2018, 22:09:40 »
Volani funkce a synchronni poslani zpravy, tj. zaslani pozadavku a obdrzeni odpovedi, jsou skutecne totez, pokue je to v ramci programovaciho jazyka.
Tak já zkusím jeden protipříklad: když se skutečně předává zpráva, tak se předávají data a 1. ten, kdo je předává nad nimi ztrácí jakoukoliv kontrolu, 2. příjemce jim nutně nemusí rozumět. Čili jde například udělat velmi snadno obecnou RPC proxy, která umí proxovat cokoli, i to, co v době jejího překladu ještě vůbec neexistuje. S voláním metod tohle udělat nejde.

Ale z pohledu actor systemu bezi kazdy agent ve svem vlakne.
Tak to asi bude dost záležet na definicích pojmů. Nemám potřebu se o ně přít ani je řešit. To, co je opravdu důležitý, je, že actors komunikují pouze pomocí předávání dat, tj. nesdílejí ani paměť, ani jiné zdroje, čili z principu nemůže nastat race condition jako u OOP, nemusí se používat žádné zběsilé zámky, kritické sekce a podobné srandy. Pořád existuje problém deadlocku kvůli možným kruhovým závislostem, ale to asi žádné extraelegantní řešení stejně nemá (aspoň já o něm nevím).

Jestli dvěma goroutinám, které si posílají zprávy pomocí kanálu někdo chce nebo nechce říkat "dvě vlákna", je mi celkem jedno. Skutečné OS vlákno to může být jenom jedno a žádná tragická performance penalty tam není (btw, stejný princip se používá i v embedded), ani žádné extrabuřthandlery ani jiný "obrovský balast".

Kit

Re:co si myslite o oop?
« Odpověď #69 kdy: 23. 12. 2018, 22:30:52 »
Tak já zkusím jeden protipříklad: když se skutečně předává zpráva, tak se předávají data a 1. ten, kdo je předává nad nimi ztrácí jakoukoliv kontrolu, 2. příjemce jim nutně nemusí rozumět. Čili jde například udělat velmi snadno obecnou RPC proxy, která umí proxovat cokoli, i to, co v době jejího překladu ještě vůbec neexistuje. S voláním metod tohle udělat nejde.

Tak těmto definicím vyhovuje PHP docela dobře, tedy alespoň v mých aplikacích.

Kadet

Re:co si myslite o oop?
« Odpověď #70 kdy: 23. 12. 2018, 22:42:40 »
Vlakno je pouze abstrakce. Muze byt tezkopadne jako unix nebo nt vlakno s velkym stackem, nebo velmi lehka abstrakce v pripade green threadingu.
Ale z pohledu actor systemu bezi kazdy agent ve svem vlakne.
Green threading? A jsme zpet u kooperativniho multitaskingu jako ve win 3.11. A neni nejlepsi cely ten balast zahodit a rovnou zavolat metodu?

Ja jsem nikde nezminil nic o konkretni implementaci frajere.

Pouze rikam, ze z pohledu jednoho agenta muzu na posloupnost jeho operaci nahlizet jako na vlakno. Kdyz usporadam jeho operace v kodu podle toho jak pujdou po sobe, dokonce.ten kod zacne vypadat jako synchronni. Ale presto muzu volat jeho jednotlivy 'metody'.

Bacsa

Re:co si myslite o oop?
« Odpověď #71 kdy: 23. 12. 2018, 22:44:31 »
Poslani synchronni zpravy a volani funkce je to same.
V jakém smyslu?

Nebo preferujete asynchronni posilani zprav, kazdy obekt s vlastnim vlaknem, handlerem a obrovskym balastem navic?
Není potřeba vlastní vlákno. Nevím, co si mám představit pod handlerem. Jaký "obrovský balast"?
Volani funkce a synchronni poslani zpravy, tj. zaslani pozadavku a obdrzeni odpovedi, jsou skutecne totez
To je pravda, ale jen v rámci jednoho adresního prostoru.

Re:co si myslite o oop?
« Odpověď #72 kdy: 23. 12. 2018, 22:45:58 »
Tak těmto definicím vyhovuje PHP docela dobře, tedy alespoň v mých aplikacích.
To není definice, jenom znínění dvou vlastností, které jsou podstatné pro ten protipříklad.

Jinak formální definice actor modelu existují (i velmi formální) a každý si může ověřit, jestli je ta která implementace OOP splňuje nebo ne.

Re:co si myslite o oop?
« Odpověď #73 kdy: 23. 12. 2018, 22:47:21 »
To je pravda, ale jen v rámci jednoho adresního prostoru.
Znova opakuju: v jakém smyslu je to pravda (v rámci jednoho adresního prostoru)?

Re:co si myslite o oop?
« Odpověď #74 kdy: 23. 12. 2018, 22:48:48 »
Kdyz usporadam jeho operace v kodu podle toho jak pujdou po sobe, dokonce.ten kod zacne vypadat jako synchronni. Ale presto muzu volat jeho jednotlivy 'metody'.
Přiznám se, že vůbec nejsem schopnej dešifrovat, co se snažíš sdělit :)