Omezená dědičnost (je něco lepšího než OOP?)

[BoneFlute]

Ukaž mi, jak změníš pozici pomeranče, když budeš mět jen ten pomeranč. Klidně v Javě. Ale musíš mět jen pomeranč, to je podmínka!

Kód: [Vybrat]

pomeranc.SetPos(1,2,3);


To jsi nastavil objektu pomeranc atribut pos na 1,2,3. To není změna pozice.
Nesplnil jsi zadání.
Zkus znova.

[Reklama]

[gamer]

Ok, tak raději mluv o tom, co znáš a ne o tom, co neznáš.

Nápodobně.

Takže: máš dvě vlákna, v každém ti běží jedna postavička. Jak v ne-FP zabezpečíš, aby postavičky nevlezly na stejné políčko? Potenciálně konfliktní změny musíš tak jako tak serializovat. Čili jsi na tom úplně stejně. Nebo?

Nepleť dohromady serializaci a sychronizaci, to je něco úplně jiného. Vy chcete vytvářet seznam eventů o tom, co všechno se změnilo, který pak nějakou magií zpracujete, vyřešíte vzájemně si odporující eventy a rozhodnete o konečném stavu. Já to tak dělat nechci, provádím změny rovnou ve scéně, žádný seznam nevytvářím. Kdo dřív přijde, ten dřív mele. Musím řešit sychronizaci, když mám panáky ve vláknech, tak musím políčko nejdřív zamknout, než na něj panák vstoupí.

Obojí má svoje nevýhody. Řešení s eventy má jako nevýhodu nedeterminismus, rozhodnout které eventy jsou ty pravé není vůbec triviální úloha. Já tohle vůbec dělat nemusím. Řešení se sychronizací může být pomalejší, ale je to všechno o návrhu, co poběží paralelně a jaké sdílená data to může mít.

[gamer]

Kluci z facebooku si myslí něco jiného.

A JavaScript library for building user interfaces. To asi nebude na hry, že?

[Mirek Prýmek]

Nápodobně.

Já mluvím o tom, co znám. Znám (jakžtakž) FP a znám i klasiku. O hrách, které neznám, netvrdím nic.

Nepleť dohromady serializaci a sychronizaci, to je něco úplně jiného.

Pokud máš dvě potenciální kolizní úpravy datové struktury, tak je musíš serializovat. Jak přesně to uděláš, je detail, ale vždycky to bude nějaká serializace.

Vy chcete vytvářet seznam eventů o tom, co všechno se změnilo, který pak nějakou magií zpracujete, vyřešíte vzájemně si odporující eventy a rozhodnete o konečném stavu.

To je jenom jeden z možných přístupů. Netvrdím, že bych to tak dělal, protože jsem žádnou netriviální hru nikdy neprogramoval.

Já to tak dělat nechci, provádím změny rovnou ve scéně, žádný seznam nevytvářím. Kdo dřív přijde, ten dřív mele.

No vidíš - a přesně takhle bys to udělal ve FP, kde by scénu držel actor. To je překvápko, že?

Musím řešit sychronizaci, když mám panáky ve vláknech, tak musím políčko nejdřív zamknout, než na něj panák vstoupí.

Čili operace s políčkem serializovat - úplně přesně jako při použití actoru.

Řešení se sychronizací může být pomalejší, ale je to všechno o návrhu, co poběží paralelně a jaké sdílená data to může mít.

No vidíš - a u FP žádná sdílená data řešit nemusíš. Buď máš data v ruce - a pak ti do nich nikdo lézt nemůže, neboje nemáš a pak do nich nemůžeš lézt ty. Nemusíš řešit, kdo drží odkaz na co, kde je potřeba synchronizovat co, kde ti vzniká jaký deadlock. To je celé, nic víc v tom nemusíš hledat.

[BoneFlute]

Vy chcete vytvářet seznam eventů o tom, co všechno se změnilo

To chci dělat já. Jestli by to tak dělal Prýmek, ...

Já to tak dělat nechci, provádím změny rovnou ve scéně, žádný seznam nevytvářím. Kdo dřív přijde, ten dřív mele. Musím řešit sychronizaci, když mám panáky ve vláknech, tak musím políčko nejdřív zamknout, než na něj panák vstoupí.

Ale vždyť tě nikdo nenutí. Já bych to tak sice nedělal, páč mi to přijde hrozně pracný a bordeloizní, ale každému co jeho jest.

Řešení s eventy má jako nevýhodu nedeterminismus, rozhodnout které eventy jsou ty pravé není vůbec triviální úloha. Já tohle vůbec dělat nemusím.

Ale musíš, musíš. A mnohem víc netriviálně.

Obojí má svoje nevýhody.

Immutable řešení má jedinou nevýhodu. Změnu myšlení.

[Reklama]

[Mirek Prýmek]

Řešení s eventy má jako nevýhodu nedeterminismus, rozhodnout které eventy jsou ty pravé není vůbec triviální úloha. Já tohle vůbec dělat nemusím.

Ale musíš, musíš. A mnohem víc netriviálně.

Mě fakt baví, jak gamer vykládá, jakej je strašnej problém synchronizace eventů, ale když se ho zeptáš, jak by to dělal on, tak odpoví "kdo dřív přijde...". Synchronizovat eventy stylem "kdo dřív přijde" je fakt strašnej problém )

[BoneFlute]

Kluci z facebooku si myslí něco jiného.

A JavaScript library for building user interfaces. To asi nebude na hry, že?

Kontext!

Ale věřím, že jsi se s tím nikdy nesetkal, takže pointa:
Prohlížeč si vytváří objektovou strukturu dokumentu, takzvaně DOM. Na každém uzlu můžeš pověsit posluchače událostí, a ty odpalovat, a dynamicky měnit strukturu jak chceš. Tedy, jestli jsem tě dobře pochopil, tak toto je tvůj, dle tebe výhodnější, přístup. React dělá mimojiné to, že si vytváří kopii DOM, a všechny změny, které se vytvářejí se nejdříve provádí na té kopii - takže je to trochu podobné tomu mému přístupu. Po té, co si všechny objekty uplatní všechny změny, které jsou potřeba, a React samozřejmě musí zohledňovat i konflikty atd, tak se ta změny teprve promítne do originálního DOM. Vtip je v tom, že ač se ti může zdát, že to přeci musí být strašně pomalé, tak zkušenost ukázala, že to lítá jak z praku (ačkoliv zvorat se to dá taky).

[gamer]

To jsi nastavil objektu pomeranc atribut pos na 1,2,3. To není změna pozice.
Nesplnil jsi zadání.
Zkus znova.

A jak si myslíš, že se to normálně dělá? Objekt drží informaci o své poloze a jen jemu se to nastavuje:
https://docs.unrealengine.com/latest/INT/API/Runtime/Engine/GameFramework/AActor/SetActorLocation/index.html
Nebo v Unreal Engine taky nesplnili zadání a mají to předělat podle tvých představ?

[BoneFlute]

Řešení s eventy má jako nevýhodu nedeterminismus, rozhodnout které eventy jsou ty pravé není vůbec triviální úloha. Já tohle vůbec dělat nemusím.

Ale musíš, musíš. A mnohem víc netriviálně.

Mě fakt baví, jak gamer vykládá, jakej je strašnej problém synchronizace eventů, ale když se ho zeptáš, jak by to dělal on, tak odpoví "kdo dřív přijde...". Synchronizovat eventy stylem "kdo dřív přijde" je fakt strašnej problém )

Pokud tam dva paňácové šahali po pomeranči, tak ten první ho dostal, a ten druhej šáhnul do prázdna (v příším tiku by se to dozvěděl). Jednoduše, kdo dřív přijde. Podobně to fungovalo když by se měl ten paňáca hejbat, a vznikla by nějaká kolize (narazil do jiného paňáci).

Ve skutečnosti je to takhle velice šikovné, protože se mi ty kolize setřesou na jedno místo, žádná mi neunikne, a mohu volit strategii.

Hmm...

[BoneFlute]

To jsi nastavil objektu pomeranc atribut pos na 1,2,3. To není změna pozice.
Nesplnil jsi zadání.
Zkus znova.

A jak si myslíš, že se to normálně dělá? Objekt drží informaci o své poloze a jen jemu se to nastavuje:
https://docs.unrealengine.com/latest/INT/API/Runtime/Engine/GameFramework/AActor/SetActorLocation/index.html
Nebo v Unreal Engine taky nesplnili zadání a mají to předělat podle tvých představ?

V Unreal Engine taky netvrdí, že:

Ve funkci, která mění pozici pomeranče, opravdu nepotřebuju celou scénu, stačí mi ten pomeranč.

[BoneFlute]

A jak si myslíš, že se to normálně dělá?

No, já si sem docela pevně jist, že normálně se to dělá tak, že se vezme scéna, a ten pomeranč se na té scéně umístí kam je třeba. A obávám se, že v tomto vesmíru to prostě jinak nejde. Jo, samozřejmě jsou kolem toho různé omáčky, to je jasné. S Unrealengine sice nemám zkušenosti, ale typoval bych, že tam taky bude nějaká kritická sekce, kam se ten Actor, nebo jak to mají pojmenované, doputuje, a to se pak promítne do scény.

[gamer]

Mě fakt baví, jak gamer vykládá, jakej je strašnej problém synchronizace eventů, ale když se ho zeptáš, jak by to dělal on, tak odpoví "kdo dřív přijde...". Synchronizovat eventy stylem "kdo dřív přijde" je fakt strašnej problém )

Mě fakt baví, jak nechápete podstatu problému. Funkcionálním přístupem s generováním eventů jste tam přidali kompexitu navíc. Netriviální kompexitu navíc, kterou musíte řešit. A podle mě rozumně vyřešit nejde, ty eventy budou kolizní a nemáte deterministický algoritmus na řešení kolizí. Single thread imperativním přístupem žádné eventy nevznikají, nemusím je vůbec řešit. Nezajímají mě. Multi thread imperativním přistupem taky žádné eventy nevzníkají. Nezajímají mě. Musím řešit navíc synchronizaci přístupu ke sdíleným objektům. Mám to ale pořád docela dobře pod kontrolou, protože o tom, co a kdy se bude paralelizovat, rozhoduju já. Za mě je lepší můj způsob. Ale klidně si to dělejte jinak, když se vám to zdá dobré.

[gamer]

No, já si sem docela pevně jist, že normálně se to dělá tak, že se vezme scéna, a ten pomeranč se na té scéně umístí kam je třeba. A obávám se, že v tomto vesmíru to prostě jinak nejde. Jo, samozřejmě jsou kolem toho různé omáčky, to je jasné. S Unrealengine sice nemám zkušenosti, ale typoval bych, že tam taky bude nějaká kritická sekce, kam se ten Actor, nebo jak to mají pojmenované, doputuje, a to se pak promítne do scény.

Tohle mě fakt nebaví. Dělal jsem na engine AAA hry (nebyl to Unreal) a žádná kritická sekce tam nebyla. Nechceš ji tam, zamykání stojí výkon. Není tam potřeba. Nastavení pozice je prostě metoda objektu. Nepotřebuješ k tomu scénu. Všichni (kromě funkcionálních fanatiků  ), to tak dělají.

[Mirek Prýmek]

Funkcionálním přístupem s generováním eventů jste tam přidali kompexitu navíc. Netriviální kompexitu navíc, kterou musíte řešit.

Zatímco když budeš řešit zamykání všude možně ve všech možných kontextech, protože kdokoli si může nechat odkaz na cokoli, a občas nějaký ten zámek zapomeneš přidat a ono ti to bude zničehožnic nedeterministicky padat, tak tím žádnou komplexitu nepřidáváš a nic řešit nemusíš

Hele, už toho fakt nechme, nikam to nevede. Vždyť tě nikdo nenutí FP používat, tak jakej máš problém? Prostě FP nepoužívej. Když o něm nebudeš rozšiřovat nesmysly, tak na tebe nikdo nebude reagovat a všichni budou spokojení, ne?

[BoneFlute]

Mě fakt baví, jak nechápete podstatu problému. Funkcionálním přístupem s generováním eventů jste tam přidali kompexitu navíc. Netriviální kompexitu navíc, kterou musíte řešit. A podle mě rozumně vyřešit nejde, ty eventy budou kolizní a nemáte deterministický algoritmus na řešení kolizí. Single thread imperativním přístupem žádné eventy nevznikají, nemusím je vůbec řešit. Nezajímají mě. Multi thread imperativním přistupem taky žádné eventy nevzníkají. Nezajímají mě. Musím řešit navíc synchronizaci přístupu ke sdíleným objektům. Mám to ale pořád docela dobře pod kontrolou, protože o tom, co a kdy se bude paralelizovat, rozhoduju já. Za mě je lepší můj způsob. Ale klidně si to dělejte jinak, když se vám to zdá dobré.

Podstata problému je, že neumíš počítat (prosím neber to osobně). Ta komplexita je ve FP mnohem menší. Máš nad tím mnohem menší kontrolu. Synchronizaci přístupu musíme řešit oba, ale tobě to půjde hůř (a nebo jsi šikovný programátor, což mi ale nepomůže).

Já bych to tady uzavřel. Dokavad nesplatíš "dluhy", tak za mě nemá smysl pokračovat:

Ukaž mi, jak změníš pozici pomeranče, když budeš mět jen ten pomeranč. Klidně v Javě. Ale musíš mět jen pomeranč, to je podmínka!

Jakoby ty kolize byly jen díky tomu, že to je napsáno immutable. Ve skutečnosti je to takhle velice šikovné, protože se mi ty kolize setřesou na jedno místo, žádná mi neunikne, a mohu volit strategii. Ukaž, jak by jsi to dělal mutable, a snaž se, aby to bylo fakt lepší ;-)

Vidiš to. Já bych naopak řekl, že je na tom krásně vidět, jak těžké je opustit mutable svět a začít přemýšlet funkcionálně.

Na tom, co jsi udělal, nic funkcionálního není. Spojuje to nevýhody imperativního a funkcionálního přistupu dohromady. Pracovat ve všech funkcích s celou scénou je totální fail. Formálně je to funkcionální, prakticky je to ale hybrid, imperativní přístup jsi násilně narouboval do funkcionálního světa. Výsledek není dobrý.

Respektuji tvůj názor, ale nemám důvod s ním souhlasit. Jsem bohužel dost tvrdohlavý, a bez argumentů se mnou nehneš ;-)