Těžké OOP problémy

Re:Těžké OOP problémy
« Odpověď #30 kdy: 07. 11. 2019, 00:19:36 »
ale chyba v je konceptu
To jsi četl kde?

Vidím ale jednu věc, na které se snad shodneme, to že OOP něco lidi naučí, ale implementace dělá něco jiného, je chyba. To beru. Ale tady je to chyba té implementace, ne toho konceptu. Podle mě nebyl původní dotaz na konkrétní implementace OOP ale obecně...
Samozřejmě, původní koncept OOP je v pohodě, není na něm nic špatného, naopak. Jenže dobré implementace původní myšlenky jaksi nejsou. Nebo jsou velmi okrajové. Čili obecně (s odhlédnutím od výjimek potvrzujících pravidlo, jako je třeba Pharo) stojí OOP (ať už Java, C++ nebo Python) za kulový.

Nic jako "obecné OOP" neexistuje, proto se na něho nedá ani ptát ani o něm diskutovat. Existují jenom jednotlivé implementace. A pokud se OP ptal na problém, který se těžko modeluje, tak na to není odpověď. V některé implementaci se blbě modeluje něco, v jiné něco jiného. Ale pro všechny mainstreamové implementace platí, že přináší víc škody než užitku :)


Re:Těžké OOP problémy
« Odpověď #31 kdy: 07. 11. 2019, 00:31:14 »
ale chyba v je konceptu
To jsi četl kde?
Tady:
Problem je v tom, ze (dnesni, takzvane) OOP uplne automaticky pocita s tim, ze ...
Dál neřeš, se zbytkem, že "původní koncept OOP je v pohodě" atd. se tedy myslím shodneme.
Nic jako "obecné OOP" neexistuje, proto se na něho nedá ani ptát ani o něm diskutovat.
Ano, takže bychom to tu rovnou uzavřeli, ne?  8)

Re:Těžké OOP problémy
« Odpověď #32 kdy: 07. 11. 2019, 00:34:03 »
Já bych to fakt tak nedramatizoval. Jak sám píšeš, žárovka má sama rozhodnout a případně volajícího poslat někam (žárovka je v tomto ohledu agent), pokud to nedělá, je špatně její kód.
No jo, jenže jak bys to konrétně v nějakém mainstreamovém "OOP jazyce" implementoval? Dáš na každou metodu mutex a každá metoda bude mít možnost buď vyhodit výjimku nebo vracet speciální chybový stav "teď nemůžu"? Podle mě tam na to prostě není žádný nástroj, který by 1. z kódu neudělal totálně nečitelnou zhovadilost nebo 2. by kód nedegradoval na normální strukturovaný kód s nějakými podivnými strukturami "class", které s původní myšlenkou OOP nemají nic společného.

IMHO pokud se má OOP spojit s konkurentností a zároveň se nemá jedno nebo druhý totálně zhovadit, jediný řešení je to, které má Erlang (nepřekvapivě ;) ) - co objekt (actor), to vlákno. Protože "actor" je od slova "act". A vlákno je od slova "act". Vlastně není, ale to neva.

Že OOP naučí nějak myslet bych taky nepřeceňoval, “nějak myslet” naučí matematika nebo třeba analytická filosofie, ale to už se bavíme na úplně jiné úrovni, běžný Ferda programátor je rád, když mu stačí myslet ve for cyklech.
Kéž by! Jak říká Linus: "[C programmers] don't screw things up with any idiotic "object model" crap". Když budeš BFP rvát do hlavy koncepty jako "objekt", "objektový model", "objektový návrh" a budeš se tvářit, že to je na kódu to nejdůležitější, tak to jenom pochopí blbě a začnou vymýšlet fantasmagorie.

Když jim dáš funkce, struktury a cykly, tak to pochopí v pohodě a žádný zhovadilosti nebudou mít potřebu vymýšlet. Tohle imho vyhmátl Pike hodně dobře :)

--
Už se pro dnešek omlouvám, jednak se zbytečně vracíme k té někdejší debatě a navíc musím dneska už chrnět :)
« Poslední změna: 07. 11. 2019, 00:36:21 od Mirek Prýmek »

Re:Těžké OOP problémy
« Odpověď #33 kdy: 07. 11. 2019, 00:35:41 »
Tady:
Jenže tos právě ustřihl půl věty. Ta věta říká, že problém je v rozporu mezi konceptem a realitou.

BoneFlute

  • *****
  • 1 981
    • Zobrazit profil
Re:Těžké OOP problémy
« Odpověď #34 kdy: 07. 11. 2019, 00:39:41 »
No jo, jenže jak bys to konrétně v nějakém mainstreamovém "OOP jazyce" implementoval? Dáš na každou metodu mutex a každá metoda bude mít možnost buď vyhodit výjimku nebo vracet speciální chybový stav "teď nemůžu"? Podle mě tam na to prostě není žádný nástroj, který by 1. z kódu neudělal totálně nečitelnou zhovadilost nebo 2. by kód nedegradoval na normální strukturovaný kód s nějakými podivnými strukturami "class", které s původní myšlenkou OOP nemají nic společného.

IMHO pokud se má OOP spojit s konkurentností a zároveň se nemá jedno nebo druhý totálně zhovadit, jediný řešení je to, které má Erlang (nepřekvapivě ;) ) - co objekt (actor), to vlákno. Protože "actor" je od slova "act". A vlákno je od slova "act". Vlastně není, ale to neva.
Co třeba Pony ?


Idris

  • *****
  • 2 286
    • Zobrazit profil
    • E-mail
Re:Těžké OOP problémy
« Odpověď #35 kdy: 07. 11. 2019, 02:45:19 »
Já bych to fakt tak nedramatizoval. Jak sám píšeš, žárovka má sama rozhodnout a případně volajícího poslat někam (žárovka je v tomto ohledu agent), pokud to nedělá, je špatně její kód.
No jo, jenže jak bys to konrétně v nějakém mainstreamovém "OOP jazyce" implementoval? Dáš na každou metodu mutex a každá metoda bude mít možnost buď vyhodit výjimku nebo vracet speciální chybový stav "teď nemůžu"? Podle mě tam na to prostě není žádný nástroj, který by 1. z kódu neudělal totálně nečitelnou zhovadilost nebo 2. by kód nedegradoval na normální strukturovaný kód s nějakými podivnými strukturami "class", které s původní myšlenkou OOP nemají nic společného.

IMHO pokud se má OOP spojit s konkurentností a zároveň se nemá jedno nebo druhý totálně zhovadit, jediný řešení je to, které má Erlang (nepřekvapivě ;) ) - co objekt (actor), to vlákno. Protože "actor" je od slova "act". A vlákno je od slova "act". Vlastně není, ale to neva.

Že OOP naučí nějak myslet bych taky nepřeceňoval, “nějak myslet” naučí matematika nebo třeba analytická filosofie, ale to už se bavíme na úplně jiné úrovni, běžný Ferda programátor je rád, když mu stačí myslet ve for cyklech.
Kéž by! Jak říká Linus: "[C programmers] don't screw things up with any idiotic "object model" crap". Když budeš BFP rvát do hlavy koncepty jako "objekt", "objektový model", "objektový návrh" a budeš se tvářit, že to je na kódu to nejdůležitější, tak to jenom pochopí blbě a začnou vymýšlet fantasmagorie.

Když jim dáš funkce, struktury a cykly, tak to pochopí v pohodě a žádný zhovadilosti nebudou mít potřebu vymýšlet. Tohle imho vyhmátl Pike hodně dobře :)

--
Už se pro dnešek omlouvám, jednak se zbytečně vracíme k té někdejší debatě a navíc musím dneska už chrnět :)
Ano, metody, které někdy můžou selhat, by měly vracet chybu, jestli výjimkou, to už je celkem jedno. Za funkčnost ať si zodpovídá objekt sám. Vlákna bych do toho netahal, to je k OOP ortogonální koncept. 

Jinak moje zkušenost je, že kvalita kódu nezávisí na konceptech, je to čistě o člověku. Tam, kde jsem teď (School of physics na jedné britské univerzitě), mám kolem sebe jen fyziky, kteří se naučili psát kód jen tak mimochodem při počítání kovariantních derivací a stáčení perihelií exoplanet, na nějaké koncepty a SW inženýrství zvysoka šitujou a i tak píšou o řády lepší kód než někdo, kdo někde na VŠE “studoval koncepty” a na internetovém fóru vypisuje blbosti, když se mu občas nedejbože udělá názor, protože prostě když má někdo intelektuální kapacitu na pochopení obecné relativity a Schrödingerovy rovnice, nějaké programování bere jako gymplák malou násobilku. V tomto mají Linus a Pike pravdu, k čemu fancy jazyk, když chci jen ovládat urychlovač částic  :)

Re:Těžké OOP problémy
« Odpověď #36 kdy: 07. 11. 2019, 07:30:46 »
Co třeba Pony ?
To vypadá fakt dobře, díky za upozornění! Někdy na to kouknu trochu podrobněji.

Evidentně nad věcí uvažují podobně jako já:
Citace
The code within a single actor is never run concurrently. This means that, within a single actor, data updates cannot cause problems.

Ano, metody, které někdy můžou selhat, by měly vracet chybu, jestli výjimkou, to už je celkem jedno. Za funkčnost ať si zodpovídá objekt sám. Vlákna bych do toho netahal, to je k OOP ortogonální koncept. 
Je a není. V C je zvykem mít u funkce napsané, jestli je nebo není reentrantní. A předáváš jí většinou přesně jenom ta data, která potřebuje. Takže se dá to zamykání udělat s nějakou rozumnou granularitou. V OOP má každá metoda přístup ke všem datům objektu a objekty obsahují bambiliony referencí, takže granularita zamykání je problém. V praxi se to pak často řeší způsobem "GUI vlákno + výpočetní vlákno/vlákna", protože kdybys to měl řešit na úrovni metod, tak by ses z toho zvencnul, nasekal tam spoustu chyb a ještě by to bylo nečitelné.

na nějaké koncepty a SW inženýrství zvysoka šitujou a i tak píšou o řády lepší kód než někdo, kdo někde na VŠE “studoval koncepty”
Já tvrdím, že OOP koncepty lidem matou hlavy. Tahle tvoje historka je s tím tvrzením ortogonální :)

Re:Těžké OOP problémy
« Odpověď #37 kdy: 07. 11. 2019, 08:38:26 »
Prymek:

Volani metody není nic jineho, nez implementace obecného OOP konceptu zaslani zprávy, je to synchronni zprava s volitelnou navratovou hodnotou. Klidopido je možno zasilat pozadavky přes frontu, kde bude zarovka subscribovana, na vlastnim nechanismu to nemeni nic.
OOP model zarovka s metodami rozsvit, zhasni je naprosto korektni model. Nechapu blaboleni, proc by jako zarovka mela sama něco delat, zarovka je pouze objektem, se kterym se manipuluje. Iniciatorem akce je objekt Osoba, která implementuje Runnable.run a zde je kod manipulujici se zarovkou.
Zkousel jsem to dneska rano v koupelne, byl jsem tam ja, zena a deti a normalne to fungovalo, zarovka svitila presne podle pozadavku.
Blaboly o threadech jsou mimo misu OOP, prislusne metody se daji synchronized, coz je implementacni detail, klidne muze byt OOP jazyk, co ma volani metod synchronizovane defaultne a krome rychlosti to nicemu vadit nebude.
Model zarovka je naprosto validni s omezením, ze funguje pouze pro konfiguraci jeden vypinac s jednou zarovkou, model zarovka defacto obsahuje celou tuto kompozici.
V realnem svete bude potreba model Okruh, který ma vypinace, které přes definovanou logiku ovladaji zarovky, takhle se pokryjou i schodistaky. A objekty Osoba budou manipulovat s vypinaci. Problem solved, jednoduche jak varic, prosty model realneho světa, vic hovadin vymyslet netreba.
Chapu, ze mezi nami ziji lide, kteří ziji ve svete, ve kterem pokojem vede trubka s protekajicimi funkcemi, které si obcas vezmou zhaslou zarovku a vymeni ji za jinou, rozsvicenou, muj svet je ale objektovy.

Re:Těžké OOP problémy
« Odpověď #38 kdy: 07. 11. 2019, 08:50:43 »
Nechapu blaboleni, proc by jako zarovka mela sama něco delat
To je v pohodě, rozhodně nejsi sám.

muj svet je ale objektovy.
Však to je v pohodě. Když tě to baví psát a někdo ti za to zaplatí, není nikde žádný problém. Jsou i lidi, kteří píší ve Visual Basicu a baví je to. Rozhodně nemám potřebu kohokoli o čemkoli přesvědčovat.

kimec

Re:Těžké OOP problémy
« Odpověď #39 kdy: 07. 11. 2019, 09:07:46 »
Jenže dobré implementace původní myšlenky jaksi nejsou. Nebo jsou velmi okrajové. Čili obecně (s odhlédnutím od výjimek potvrzujících pravidlo, jako je třeba Pharo) stojí OOP (ať už Java, C++ nebo Python) za kulový.

Problem je v tom, ze (dnesni, takzvane) OOP uplne automaticky pocita s tim, ze objekt je entita a pritom klidne do te entity necha vlezt nekolik vlaken. Cista schizofrenie.

Presne tak. Pan Prymek, povedali ste to celkom presne, ale malo to byt zadanie pre povodneho tazatela. Ten mal zaujem o riesenie tazkeho problemu v OOP.

Kit

  • *****
  • 704
    • Zobrazit profil
    • E-mail
Re:Těžké OOP problémy
« Odpověď #40 kdy: 07. 11. 2019, 09:08:55 »
OOP model zarovka s metodami rozsvit, zhasni je naprosto korektni model. Nechapu blaboleni, proc by jako zarovka mela sama něco delat, zarovka je pouze objektem, se kterym se manipuluje. Iniciatorem akce je objekt Osoba, která implementuje Runnable.run a zde je kod manipulujici se zarovkou.
Zkousel jsem to dneska rano v koupelne, byl jsem tam ja, zena a deti a normalne to fungovalo, zarovka svitila presne podle pozadavku.

Jistě to skvěle funguje i v případě, že ty a manželka chcete mít rozsvíceno, ale děti chtějí mít zhasnuto. Ve chvíli, kdy je objektů Osoba víc, musíš zajistit (ne)svícení buď fackováním, tedy soutěží mezi objekty Osoba, anebo technicky, kdy k žárovce je přidán doplněk, který nedovolí změnu stavu častěji, než např. jednou za minutu.

Re:Těžké OOP problémy
« Odpověď #41 kdy: 07. 11. 2019, 10:57:52 »
OOP model zarovka s metodami rozsvit, zhasni je naprosto korektni model. Nechapu blaboleni, proc by jako zarovka mela sama něco delat, zarovka je pouze objektem, se kterym se manipuluje. Iniciatorem akce je objekt Osoba, která implementuje Runnable.run a zde je kod manipulujici se zarovkou.
To, že žárovka sama něco dělá, vyplývá právě z toho zasílání zprávy. Osoba té žárovce jen zašle zprávu a je na té žárovce, jak s tou zprávou naloží. A i OOP jazyky bez posílání zpráv mají virtuální metody, díky kterým volající neví, co tahle konkrétní žárovka udělá. Osoba to jen iniciuje, ale nerozhoduje o tom, co se má stát.

To je právě zásadní rozdíl mezi objekty z OOP a z reálného světa. Drtivá většina toho, čemu normálně říkáme "objekt" rozumí akorát zprávě "zůstaň". :)

Re:Těžké OOP problémy
« Odpověď #42 kdy: 07. 11. 2019, 11:03:51 »
Drtivá většina toho, čemu normálně říkáme "objekt" rozumí akorát zprávě "zůstaň". :)
Ještě často implementovaná zpráva je "lehni nebo ne!" Tu umí každý objekt.

P.S. "normálně" neříkáme "objekt" skoro ničemu. Možná tak ještě budově nebo souboru budov :) Ten náš "objekt" je celkem čistý kalk z angličtiny.

Re:Těžké OOP problémy
« Odpověď #43 kdy: 07. 11. 2019, 11:08:37 »
Mimochodem, když už jsme u té amatérské lingvistiky, tak ve filosofii se "objekt" odlišuje od "subjektu" právě tím, že je aktérem, původcem děje. A proto má i ta žárovka konat autonomně. Kdyby byla pasivní, nebyla by "objektem", ale "subjektem" :)

Re:Těžké OOP problémy
« Odpověď #44 kdy: 07. 11. 2019, 11:23:50 »
Není to přesně naopak, minimálně v anglické gramatice?