Příspěvky

961

/dev/null / Re:Těžké OOP problémy

« kdy: 07. 11. 2019, 14:23:16 »

Ano, velmi zlehka. Ruku na srdce, každý z nás pár astrofyziků zná, oder?

Já ne

962

/dev/null / Re:Těžké OOP problémy

« kdy: 07. 11. 2019, 14:22:35 »

Rad bych videl architektonicke vytvory mistniho osazenstva, to musi byt veru zajimave cteni...

No problem. Nejnovější veřejně dostupný kód: https://github.com/mprymek/PeaLC/tree/master/firmware/ - víceméně tak, jak byl napsaný, na první dobrou, ještě bez většího review a dokumentace, pořád trochu v pohybu.

963

/dev/null / Re:Těžké OOP problémy

« kdy: 07. 11. 2019, 14:13:00 »

Tak ale ty sám jsi zmínil “amatérskou lingvistiku.”

Já vím, napsal jsem to zmateně. Chtěl jsem říct "když už se bavíme o významech slov". Byla to narážka na předchozí ""normálně" neříkáme "objekt" skoro ničemu."

To je pravda, ale v zápětí jsem psal, že ta laťka může být jinde, prostě jsem si dovolil nadsázku 

Jak říká klasik: "Trochu jsem si zapřeháněl"

964

/dev/null / Re:Těžké OOP problémy

« kdy: 07. 11. 2019, 14:08:37 »

Já tvrdím, že OOP koncepty lidem matou hlavy.

Ani ne. Jen tvrdím, že když má někdo PhD z astrofyziky, nějaký zcestný koncept ho nezmate

Doktoři astrofyziky budou uvnitř "lidí" tvořit dost zanedbatelné procento

965

/dev/null / Re:Těžké OOP problémy

« kdy: 07. 11. 2019, 14:06:11 »

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"

Tos těžce netrefil, subjekt/objekt jsou pojmy z oblasti syntaxe

Asi ste chceli poukazat na tranzitivnost/netranzitivnost slovies

Oba jste to pochopili příliš lingvisticky, já jsem myslel spíš https://en.wikipedia.org/wiki/Object_(philosophy)
...ale jak jsem u toho psaní dělal ještě něco jinýho, tak jsem to omylem otočil, takže jsem dodal argument proti tomu, co říkám (že "objekt" má být "konatel")

966

/dev/null / Re:Těžké OOP problémy

« kdy: 07. 11. 2019, 11:25:52 »

Není to přesně naopak, minimálně v anglické gramatice?

No vidis, vlastne je. Nejenom v anglictine, ale i ve filosofii. To jsem se teda dobre upsal )) Diky.

967

/dev/null / Re:Těžké OOP problémy

« 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"

968

/dev/null / Re:Těžké OOP problémy

« 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.

969

Vývoj / Re:Uváznutí v Aktor systému

« kdy: 07. 11. 2019, 11:00:28 »

Mě tak nějak furt nedochází, proč bych měl těm aktorům dávat volnost, když je pak tak snadné to evidentně napsat špatně.

Protože jestli je to dobře nebo špatně záleží na tom, co implementuješ. V základu můžeš mít stavového a nestavového aktora a stavový a nestavový protokol. Souvisí to spolu, ale ne těsně, takže to je ortogonální => z tohodle pohledu můžeš mít celkem 4 možnosti toho, co chceš implementovat. A co je korektní v jedné nemusí být korektní v druhé.

Jinak ale ta tvoje myšlenka je správná, akorát se to řeší jinak: nějaká základní "šablona" aktoru je ve standardní knihovně a ty dodáš jenom callbacky implementující tu tvoji kýženou funkcionalitu. V erlang světě je taková nejčastější "šablona" http://erlang.org/doc/man/gen_server.html (implementuje stavováho aktora implementujícího potenciálně stavový protokol).

Takže máš vlastně pravdu, akorát se to nedělá na úrovni jazyka, kde by to bylo těžký a matoucí, ale na úrovni knihovny.

970

/dev/null / Re:Těžké OOP problémy

« 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.

971

/dev/null / Re:Těžké OOP problémy

« 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á:

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í

972

/dev/null / Re:Těžké OOP problémy

« 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.

973

/dev/null / Re:Těžké OOP problémy

« 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

974

/dev/null / Re:Těžké OOP problémy

« 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

975

/dev/null / Re:Těžké OOP problémy

« kdy: 06. 11. 2019, 23:37:00 »

Normální vývojář se neřídí tím, co mu řekne “koncept,”

Po dlouhé době s tebou velmi zásadně nesouhasím. OOP naučí lidi nějak myslet. V pojmech "mám žárovku", "řeknu žárovce, aby se rozsvítila". Což je naprosto perfektně OOP a nemám proti tomu nic. Až na to, že implementace dělá něco úplně jiného, v tom je problém

ale jednoduchými instrukcemi, jak na synchronizaci.

Synchronizace je (v tomhle kontextu) jenom narovnávák na ohýbák. V OOP nemá co dělat. Já mám prostě žárovku a řeknu jí, aby se rozsvítila. Jestliže se právě nažhavuje, má mi odpovědět "sorry, teď nemůžu, mám na práci něco jinýho". Synchronizace má svoje místo mezi entitami (já začnu až ty skončíš), nemá být zneužívaná k tomu, abych "zesynchronizoval" "jednu entitu". Už v kombinaci těhle dvou pojmů je vidět, jak je to ujetý. Co se tam totiž synchronizuje? Vlákna. A proč? No protože vlákna jsou tam ty entity, ne objekty Protože chci dosáhnout "prvně já (vlákno1) rožnu a pak ty (vlákno2) zhasneš". Objekt tam žádnou entitou není. Jenom se snaží udělat takovej dojem. A ochotně mu to žereme. Dokud máme jenom jedno vlákno