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

[JS]

Tusim autor hry Iconclad :Steam Legions (psano v Clojure) se v blogu tvaril, jak se mu s immutable stavem hry strasne dobre pracovalo.

Viz tez http://stackoverflow.com/questions/9755882/are-functional-programming-languages-suitable-for-graphics-programming.

[Reklama]

[gamer]

Pokud je ale ta úloha z definice sekvenční, tak ji prostě FP žádným magickým proutkem samo neparalelizuje, to dá rozum. Pokud budeš počítat sha(md5(x)), tak na to prostě nemůžeš jít stylem y=md5(x) z=sha(x) a divit se, že neumíš y a z "dát deterministicky dohromady". Protože to prostě takhle nejde.

Ta úloha není z definice sekvenční, dá se bez problémů paralelizovat. Řeším třeba AI panáků, kteří sbírají pomeranče. Klidně můžu pustit každého panáka v samostantném vláknu, ale musím nějak synchronizovat přístup k pomerančům, protože dva panáci nesmí současně pracovat s jedním pomerančem. FP mi to nijak neusnadňuje, synchronizaci musí řešit taky, i když třeba jinými prostředky.

Naštěstí vždycky, když něco nejde, tak se najde nějakej blbec, kterej neví, že to nejde, a naprogramuje to

Nikdo netvrdí, že by to nešlo, samozřejmně že to jde. Ale je to neefektivní, imperativní přístup s mutable objetky dává lepší výsledky.

[BoneFlute]

FP mi to nijak neusnadňuje, synchronizaci musí řešit taky, i když třeba jinými prostředky.

Musím řešit jen ten pomeranč, kterej jedinej je napříč vlákny. U mutable musím hlídat úplně všechno. To mi přijde jako dost velké usnadnění. (A to jsme ještě nevytáhly nástroje a zatím se bavíme jen o výhodách daných principy.)

Nikdo netvrdí, že by to nešlo, samozřejmně že to jde. Ale je to neefektivní, imperativní přístup s mutable objetky dává lepší výsledky.

Čím by si podložil své tvrzení? Nebo je to jen tvůj pocit?

[Mirek Prýmek]

Pokud je ale ta úloha z definice sekvenční

Ta úloha není z definice sekvenční, [...] dva panáci nesmí současně pracovat s jedním pomerančem.

Jsi si jistý?

Nikdo netvrdí, že by to nešlo, samozřejmně že to jde. Ale je to neefektivní, imperativní přístup s mutable objetky dává lepší výsledky.

Citation needed.

[Kit]

Ta úloha není z definice sekvenční, [...] dva panáci nesmí současně pracovat s jedním pomerančem.

Jsi si jistý?

Záleží na tom, jak se ta úloha uchopí. Pokud má panák kapsu (kolekci) a do ní strká pomeranče (položky), je při práci s takovou strukturou hromada rizik. Pokud však máme panáka bez kapsy a pomeranč, jehož atributem je majitel, problém se dvěma panáky najednou mizí. Atribut je jen jeden - pouze jeden panák může ten pomeranč vlastnit.

[Reklama]

[Mirek Prýmek]

Pokud však máme panáka bez kapsy a pomeranč, jehož atributem je majitel, problém se dvěma panáky najednou mizí. Atribut je jen jeden - pouze jeden panák může ten pomeranč vlastnit.

...a jenom vlastník s ním může pracovat. Čili sekvenční kód, explicitně vylučující paralelismus

[Kit]

Pokud však máme panáka bez kapsy a pomeranč, jehož atributem je majitel, problém se dvěma panáky najednou mizí. Atribut je jen jeden - pouze jeden panák může ten pomeranč vlastnit.

...a jenom vlastník s ním může pracovat. Čili sekvenční kód, explicitně vylučující paralelismus

Proč? Akci panáka přece spustím prostřednictvím toho pomeranče. Pokud mám ve hře 10 pomerančů, mohu mít 10 paralelních větví.

Přesně tak to mám ve svém webovém RPG, ve kterém je držený meč vlastněn hráčem, batoh vlastněn hráčem a artefakt vlastněn batohem. Tím se mi většina vazeb zredukovala na 1:1. Předměty v batohu se neúčastní soubojů, štít chrání hráče pouze pokud je nasazen, hráč může být zaklet do artefaktu a uložen do batohu jiného hráče... Také databázi se ulevilo.

[Mirek Prýmek]

Proč? Akci panáka přece spustím prostřednictvím toho pomeranče. Pokud mám ve hře 10 pomerančů, mohu mít 10 paralelních větví.

No jasně, to je ten partitioning, o kterým jsem psal. Gamer je ale zhrzenej, že není paralelizovaná práce s jedním pomerančem a zároveň chce, aby k němu nemohli přistupovat dva hráči zároveň.

Prostě, když mám nějaký sdílený stav, tak přístup k němu musím vždycky serializovat, z principu, v tom mi žádná magická hůlka nepomůže. Výhoda FP je v tom, že množství sdílených stavů udržuje na nezbytném minimu a proto se dá paralelismus použít na víc místech než v kódu, kde je sdílené kde co a ani nemůžu efektivně zjistit, co je a co není. V tom je ta výhoda. Gamer ji hledá někde, kde není a být nemůže.

[gamer]

Musím řešit jen ten pomeranč, kterej jedinej je napříč vlákny. U mutable musím hlídat úplně všechno. To mi přijde jako dost velké usnadnění. (A to jsme ještě nevytáhly nástroje a zatím se bavíme jen o výhodách daných principy.)

Nemusím hlídat všechno, u mutable taky řeším jen ten pomeranč, který jde napříč vlákny. Nic jiného synchronizovat nemusím. Je to úplně stejné.

Čím by si podložil své tvrzení? Nebo je to jen tvůj pocit?

Težko srovnávat, protože velké funkcionální hry neexistují. Ani žádný významný herní engine není funkcionální. Existují jen menší hry, napsané jako hobby projekty. Ale budiž, musíme si vystačit s tím. Můžeš začít třeba tady:
http://stackoverflow.com/questions/9755882/are-functional-programming-languages-suitable-for-graphics-programming
Autor Ironclad: Steam Legions popisuje svoje zkušenosti, vytrhnu z kontextu jen tohle:
You need to be careful about performance
Mutability is useful in games

Zajímavé věci se dají dočíst i tady: http://prog21.dadgum.com/23.html
Je to od člověka, který udělal funkcionálního Pac-Mana. I když se jedná o velmi jednoduchou hru, byl donucen k nedobrým řešením. Protože nemůže rozumně během výpočtu měnit herní scénu, řeší změny scény až ex-post na základě eventů ({ate_dot,Coordinates}, ate_fruit). To je problém, protože může vygenerovat eventy, které jsou vzájemně v kolizi. Ex-post potom musíš řešit, co dělat, když jdou nějaké eventy proti sobě. U Pac-Mana s pár eventy to ještě asi bude řešitelné, ale nedokážu si to představit u větší hry, kde budou tisíce různých eventů, které můžou vznikat ve všech možných kombinacích. Dá se to vyřešit tak, že budu seznam už existujících eventů předávat do každé funkce a na základě toho pak rekonstruovat aktuální scénu, ale to je už úplně uhozené.

Můžeš argumentovat, že je to vlastně super, všechny výpočty dělám s konstatní scénou, která se nemění, takže to můžu perfektně paralelizovat. Jenomže imperativně můžu udělat to samé, můžu to paralelizovat úplně bez sychronizace, pokud neměním scénu. Prakticky to takhle ale nikdo nedělá, i když může. Není to dobrý přístup.

Pak ještě napsal takové obecné shrnutí o funkcionálním programování: http://prog21.dadgum.com/54.html

[gamer]

Proč? Akci panáka přece spustím prostřednictvím toho pomeranče. Pokud mám ve hře 10 pomerančů, mohu mít 10 paralelních větví.

Můžeš to tak udělat, ale není to dobrý design. O tom, co se stane s pomerančem, rozhoduje panák, pomeranč je jen pasivní objekt. Panák by měl tu akci provádět.

[gamer]

Gamer je ale zhrzenej, že není paralelizovaná práce s jedním pomerančem a zároveň chce, aby k němu nemohli přistupovat dva hráči zároveň.

Nevím, jestli nerozumíš tomu, co píšu, nebo jestli to schválně překrucuješ tak, jak se ti to hodí. Spíš bych tipoval to druhé, ale budiž, pokusím se to vysvětlit znovu.

Nechci paralelizovat práci s jedním pomerančem. Chci paralelizovat AI panáků. Ve hře mám 50 panáků a každý se musí rozhodnout, co bude dělat. Musí nejdřív zjistit, jaké vidí pomeranče a okolní panáky. Potom k těm pomeračům musí najít nejkratší cestu. Mohl by se taky snažit najít nejkratší cestu ostatních panáků k pomeračům. Na základě všech těchto informací se bude každý panák snažit najít optimální řešení, které bude maximalizovat jeho zisk - získá co nejvíc pomeranců. Můžu to pustit paralelně v samostatném vlákně po každého panáka. A já se ptám, jak mi pomůže, když to udělám funkcionálně? Bez sychronizace se stejně neobejdu, musím řešit co se stane, když panáci přistupují ke sdíleným pomerančům a taky musím řešit jejich kolize, aby se mi na cestě nesráželi.

Výhoda FP je v tom, že množství sdílených stavů udržuje na nezbytném minimu a proto se dá paralelismus použít na víc místech než v kódu, kde je sdílené kde co a ani nemůžu efektivně zjistit, co je a co není. V tom je ta výhoda. Gamer ji hledá někde, kde není a být nemůže.

To jsou jen takové teoretické řeči. I když to udělám funcionálně, nevypadne z toho nějak magicky, které zdroje jsou sdílené a které ne. Funcionální kód mi neřekne, že modří panáci sbírají jen pomeranče a červení panáci sbírají jen citróny. To je informace, kterou musím explicitně znát.

[Mirek Prýmek]

Zajímavé věci se dají dočíst i tady: http://prog21.dadgum.com/23.html

No, tak bysme měli jeden blog jednoho programátora, kterému to nešlo, fajn

Každopádně mám velké pochyby o tom, jak moc FP ten člověk zná, protože ten příklad s globálním proměnnou (např. skóre) je přesně to, na co se používá Actor/Agent - k zapouzdření sdíleného stavu a serializaci přístupu k němu. A používá se to velice snadno. Takže těžko říct, co vyvozovat z blogu, který říká, že to nejde...

http://elixir-lang.org/docs/stable/elixir/Agent.html

[Mirek Prýmek]

Nechci paralelizovat práci s jedním pomerančem. Chci paralelizovat AI panáků. Ve hře mám 50 panáků a každý se musí rozhodnout, co bude dělat. Musí nejdřív zjistit, jaké vidí pomeranče a okolní panáky. Potom k těm pomeračům musí najít nejkratší cestu. Mohl by se taky snažit najít nejkratší cestu ostatních panáků k pomeračům. Na základě všech těchto informací se bude každý panák snažit najít optimální řešení, které bude maximalizovat jeho zisk - získá co nejvíc pomeranců. Můžu to pustit paralelně v samostatném vlákně po každého panáka. A já se ptám, jak mi pomůže, když to udělám funkcionálně? Bez sychronizace se stejně neobejdu, musím řešit co se stane, když panáci přistupují ke sdíleným pomerančům a taky musím řešit jejich kolize, aby se mi na cestě nesráželi.

Napsal jsem ti několikrát několik způsobů, jak se taková věc řeší. Nebudu to opakovat, nemám důvod tě o něčem přesvědčovat, když o to nemáš zájem.

To jsou jen takové teoretické řeči. I když to udělám funcionálně, nevypadne z toho nějak magicky, které zdroje jsou sdílené a které ne.

Ale samozřejmě, že vypadne, protože ve FP prostě žádný sdílený stav z principu být nemůže. Prostě to nejde, není, na úrovni kódu neexistuje. A pokud ho potřebuješ na úrovni sémantiky, tak se to dělá agentem, čili máš ten stav na jednom místě, jasně zapouzdřený a s jasným API.

Tím bych s dovolením tuhle debatu ukončil, fakt to nikam nevede, myslel jsem, že by to mohla být zajímavá debata, ale dostali jsme se do stádia přesvědčování a v tom nemá smysl pokračovat.

[Kit]

Proč? Akci panáka přece spustím prostřednictvím toho pomeranče. Pokud mám ve hře 10 pomerančů, mohu mít 10 paralelních větví.

Můžeš to tak udělat, ale není to dobrý design. O tom, co se stane s pomerančem, rozhoduje panák, pomeranč je jen pasivní objekt. Panák by měl tu akci provádět.

Panák může říct pomeranči: Teď máš nového panáka, tak si to zapiš za uši.

[v]

http://prog21.dadgum.com/23.html

soudě podle toho co píše, autor blogu je tupec