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

[gamer]

Kopie znamená, že mám někde v paměti nějaká data a PŘEKOPÍRUJU je někam do nějaké jiné oblasti paměti - mám dvě KOPIE, které jsou stejné. A k tomuhle právě nikdy nedochází. Pokud jsou někde stejná data, tak se případně kopíruje jenom pointer na ně, protože vím, že je nikdo nikdy nezmění, takže můžu s klidem ten pointer předat komu chci.

(P.S. když mluvím o pointeru, tak mluvím o vnitřní implementaci, v jazyce jako takovém se pointery nepoužívají vůbec, není proč)

Já ale neřeším interní implementaci, ta je mi ukradená a může být úplně jiná v každém jazyce. Máš immutable objekt, který nejde změnit. Ty s ním chceš něco udělat, takže musíš vytvořit nový objekt. To je u mě kopie. Říkej si tomu třeba kopírování pointerů, interně to tak klidně může fungovat, ale nesnaž se tvrdit, že jsou to ty stejné objekty. Nejsou. Interně můžou být, ale taky nemusí. Logicky je to jiný objekt.

To jsou takové mlhavé statementy, založené kdovínačem. Telefonní ústředna snad není "provázaná"? Každý může komunikovat s každým a když komunikuje A s B, tak ani s jedním nemůže komunikovat nikdo jiný. Jestli tohle není provázanost, tak už fakt nevím

Telefonní ústředna je z hlediska logiky funkce jednoduché zařízení, prakticky jen spojuje hovory, dá se to implementovat třeba relativně jednoduchým stavovým automatem, žádné složitosti v tom nehledej.

Nevím, kolik máš s FP zkušeností, ale mám trochu podezření (bez urážky!) že ty tvoje zkušenosti vychází z toho, že jsi vzal svoje znalosti z konvenčních jazyků, snažil ses to naroubovat na FP a ono to nefungovalo moc dobře. Nevím, v jakém jazyce a co jsi zkoušel napsat, ale takhle obecně se o tom dá mluvit dost těžko, musel by se vzít konkrétní kód a podívat se na něj.

Nevím kolik máš zkušeností s vývojem her, ale mám trochu podezření (bez urážky!), že ty tvoje zkušenosti vychází z toho, že jsi vzal svoje znalosti funkcionálních jazyků a snažíš se je naroubovat na simulaci reálného světa a ono to nefunguje moc dobře. Nevím, v jakém jazyce a co jsi zkoušel napsat, ale takhle obecně se o tom dá mluvit dost těžko, musel by se vzít konkrétní kód a podívat se na něj. 

[Reklama]

[gamer]

Každopádně se podívej na to video s Carmackem. Když ti Carmack řekne, že funkcionální přístup je fajn, tak asi to s těma hrama nebude tak tragicky nemožný

Na to video se podívám, ale nemyslím si, že by mě Carmack přesvědčil Jinak aby to nevyznělo špatně, já mám funkcionální programování rád, ale mám problém s tím, když se snaží roubovat i na úlohy, na které se funkcionální přístup z principu nehodí.

[Mirek Prýmek]

Já ale neřeším interní implementaci, ta je mi ukradená a může být úplně jiná v každém jazyce. Máš immutable objekt, který nejde změnit. Ty s ním chceš něco udělat, takže musíš vytvořit nový objekt. To je u mě kopie. Říkej si tomu třeba kopírování pointerů, interně to tak klidně může fungovat, ale nesnaž se tvrdit, že jsou to ty stejné objekty. Nejsou. Interně můžou být, ale taky nemusí. Logicky je to jiný objekt.

Tak já nevím, možná mluvím Čínsky, ale vůbec nerozumím, proč tohle píšeš, protože to vůbec nesouvisí s tím, co jsem napsal. No, nechme to být, zavání to spíš zbytečným flejmem než zajímavou diskusí...

Telefonní ústředna je z hlediska logiky funkce jednoduché zařízení, prakticky jen spojuje hovory, dá se to implementovat třeba relativně jednoduchým stavovým automatem, žádné složitosti v tom nehledej.

Ugh. Viděl jsi někdy konfiguraci Asterisku? A viděl jsi někdy specifikaci Jabber protokolu a k tomu alespoň pár rozšíření?

Nevím kolik máš zkušeností s vývojem her

To je jednoduchý - žádný. Taky jsem o vývoji her nic netvrdil, mluvím jenom o FP a vyvracím tvoje tvrzení o něm.

[Meh]

Já ale neřeším interní implementaci, ta je mi ukradená a může být úplně jiná v každém jazyce. Máš immutable objekt, který nejde změnit. Ty s ním chceš něco udělat, takže musíš vytvořit nový objekt. To je u mě kopie. Říkej si tomu třeba kopírování pointerů, interně to tak klidně může fungovat, ale nesnaž se tvrdit, že jsou to ty stejné objekty. Nejsou. Interně můžou být, ale taky nemusí. Logicky je to jiný objekt.

Tak já nevím, možná mluvím Čínsky, ale vůbec nerozumím, proč tohle píšeš, protože to vůbec nesouvisí s tím, co jsem napsal. No, nechme to být, zavání to spíš zbytečným flejmem než zajímavou diskusí...

Je tahle "1" neco jineho, nez tahle "1"? Jak je odlisim? Hodnota je hodnota a je uplne jedno, jestli ji kopiruju nebo na ni nejak odkazuju. Nema identitu a nemuze se zmenit. Pokud postava bere pomeranc a oboji ma byt immutable, pak je vysledkem nova postava. Pokud jsou dve ruzne a jsou obe to soucasti jedne immutable sceny, tak je vysledkem jina immutable scena. Je to stejne, jako 1+1+1. Kdybych to mel paralelizovat, tak musim na konci resit synchronizaci, protoze vysledkem je jedna nova zmenena scena, odlisna od puvodni, jina hodnota. Ta synchronizace se postara, ze "vyhraje" jedna z postav, ale nemelo by dojit ke kolizi, protoze nema jak, pokud je to cele immutable.

[Mirek Prýmek]

Je tahle "1" neco jineho, nez tahle "1"? Jak je odlisim? Hodnota je hodnota a je uplne jedno, jestli ji kopiruju nebo na ni nejak odkazuju.

Neni to jedno, protoze odkaz je prakticky zadarmo, kopirovani muze byt hodne drahy. A jestli nekdo tvrdi, ze problem je v kopirovani, tak to je proste kravina, protoze se nic nekopiruje, jenom odkazuje.

Pokud postava bere pomeranc a oboji ma byt immutable, pak je vysledkem nova postava. Pokud jsou dve ruzne a jsou obe to soucasti jedne immutable sceny, tak je vysledkem jina immutable scena. Je to stejne, jako 1+1+1. Kdybych to mel paralelizovat, tak musim na konci resit synchronizaci, protoze vysledkem je jedna nova zmenena scena, odlisna od puvodni, jina hodnota. Ta synchronizace se postara, ze "vyhraje" jedna z postav, ale nemelo by dojit ke kolizi, protoze nema jak, pokud je to cele immutable.

Sorry, ale já vůbec nechápu, co řešíte. Jaký "Pokud jsou dve ruzne a jsou obe to soucasti jedne immutable sceny"? Mám prostě

Kód: [Vybrat]

def init_state do
  ...
end

def aktualizuj_postavu(postava) do
  ...
end

def aktualizuj_stav(stary_stav) do
  {stara_postava,nejaky_zatracene_velky_data,jiny_zatracene_velky_data} = stary_stav
  nova_postava = aktualizuj_postavu(stara_postava)
  {nova_postava,nejaky_zatracene_velky_data,jiny_zatracene_velky_data}
end

def loop(stav) do
  stav2 = aktualizuj_stav(stav)
  loop(stav2)
end

def main do
  stav1 = init_state
  loop(stav1)
end
- nejaky_zatracene_velky_data se nikam nekopiruji. Jedine, co se zdestruuje a znovu vytvori v kazdem aktualizuj_stav, je jedna trojice ukazatelu. Stejne tak to funguje v aktualizuj_postavu. Nevidim zadny kopirovani velkych dat ani zadny problem se synchronizaci.

Jasne, jsou struktury, kde to dela problemy, protoze jsou moc hluboce vnorene a musi se hodne restaurovat. Ale to jsem prece napsal. Stejne tak muzu chtit paralelni zmeny stavu, ale to se resi partitioningem, to jsem taky napsal.

Fakt nevim, s čím máte pořád problém.

[Reklama]

[Mirek Prýmek]

...a už vůbec nechápu to argumentaci vícevláknovým zpracováním. Když budu mít klasický přístup, řekněme objekt, a budu ho chtít modifikovat ze dvou vláken, tak udělám co? Zamču, upravím, odemču, zamču, upravím. Což můžu úplně klidně dělat i v immutable jazycích, prostě použiju actor.

[M.]

Řekl bych, že to zmatení s immutable a víc vlákny je z tohoto pohledu:
Mám immutable data, řekněme číslo 5 někde, a mám dvě vlákna, které mají referenci na tu 5 (obě vlákna drží ukazatel na stejnou adresu), pokud obě provedou příčtení čísla 2 , tak dojde k copy on write, obě vlákna ukazují na číslo 7, ale na dvou místech (a pokud původní 5 už nikdo nedrží, likviduje ji GC). Gamer se ptá, jak udělat, aby když ty dvě vlákna to přičtení udělají, aby viděly výsledek 9....

V tomto případě musí probíhat synchronizace mezi vlákny a předávat si referenci na poslední platný stav. Např:
Mám hlavní vlákno, které modifikuje "scénu" s immutable daty 5, odkaz na tuto scénu předá těm dvěma vláknům. Pokud se má synchornizovaně přičíst každé ty 2, tak přičítací vlákna posílají zprávu držiteli scény, přičti 2, ten to udělá (a vznikne mu nové scéna prvně se 7 a pak hned s 9) a odkaz na nové scény předá vláknům, která pak vidí od okamžiku přijmu nového odkazu poslední stav scény (a jak postupně všechna vlákna opustí scény s daty 5 a 7, tak je GC likviduje).

[Mirek Prýmek]

Řekl bych, že to zmatení s immutable a víc vlákny je z tohoto pohledu:
Mám immutable data, řekněme číslo 5 někde, a mám dvě vlákna, které mají referenci na tu 5 (obě vlákna drží ukazatel na stejnou adresu), pokud obě provedou příčtení čísla 2 , tak dojde k copy on write, obě vlákna ukazují na číslo 7, ale na dvou místech (a pokud původní 5 už nikdo nedrží, likviduje ji GC). Gamer se ptá, jak udělat, aby když ty dvě vlákna to přičtení udělají, aby viděly výsledek 9....

Ano, já si taky myslím, že tak nějak ta gamerova představa je. Jenže tohle se prostě ve FP neděje, to je představa přenesená z imperativních jazyků. Ve FP se nepracuje s žádnými referencemi v tomhle smyslu. Pokud mám dvě funkce f1 a f2, jedna přičítá jedničku a druhá dvojku, a předhodím jím tentýž stav (5), tak mi prostě jedna vrátí 6 a druhá 7, to je správně a má to tak být. Jak jsem říkal, není to nic jiného než starý dobrý https://en.wikipedia.org/wiki/MISD Pokud chci ty funkce na stav aplikovat postupně, tak to opravdu musím udělat postupně - f1 mi vrátí 6 a potom aplikuju f2, která mi vrátí 8. V jazycích, které mají speciální vlastnosti (Haskell) si pak taky můžu hrát třeba s tím, že na pořadí aplikace nezáleží, můžu f1 a f2 snadno sloučit do jedné operace atd. atd. Mám tam úplně jiné možnosti a proto bych jich měl využívat a ne psát kód imperativním stylem a divit se, že mi to nefunguje podle představ...

Mimochodem, když mám immutabilní stav a ten MISD model, tak můžu dělat jednu krásnou věc: spekulativní výpočet. Čili něco, o čem si mutabilní přístup může nechat tak leda zdát Opět: je ale potřeba to umět využít a využívat...

...a pokud bych to skutečně chtěl udělat takhle, pomocí nějakého typu reference, tak třeba v Elixiru/Erlangu se na to právě používá actor (agent) - ten drží jedinou kopii dat a provádí nad němi dané operace. Takže obě vlákna drží nějakou referenci na actor (stačí jeho jméno) a posílají mu instrukce, jak má stav měnit. Actor to pak dělá ve vlastním vlákně, klidně asynchronně, původní vlákna dostanou zprávu, až je to hotovo, mezi tím můžou dělat něco jiného klidně.

Prostě možností, jak to celé uspořádat, je bambilion a připadá mi, že gamer se upnul na jednu představu, která ještě ke všemu moc neodpovídá realitě.

(A nebo se možná úplně pletu, gamer přesně ví, o čem mluví, a má pravdu. Pak by to ale chtělo líp vysvětlit pro nás méně chápavé.)

[BoneFlute]

Code reuse samozřejmě neznamená jen dědičnost. Dědičnost je jedna z metod. A ten kdo umí dědičnost a neumí jiné metody bude obhajovat dědičnost, a kdo neumí dědičnost a umí jiné metody ji bude hanit. A oba se budou hádat, že "to druhé" je cesta do pekla. Dobrý programátor prostě použije vhodně daný kontext a max si zanadává - todle by šlo v támdletom jazyku napsat elegantnějc. Já takhle střídám několik jazyků a rozstu z toho dost.

Jazyk, který poskytuje takové nástroje, že je průměrný programátor nikdy nenaučí používat, je docela na pytel, nemyslíš? Bez ohledu na to, že si myslím, že dědičnost umím používat, tak jde o to, že spousta programátorů ne. Programátorské jazyky a metodiky nám mají pomáhat, ne nás filtrovat podle inteligence a zkušeností. To jsme si pak tak nějak spletli barák.

[Meh]

Neni to jedno, protoze odkaz je prakticky zadarmo, kopirovani muze byt hodne drahy. A jestli nekdo tvrdi, ze problem je v kopirovani, tak to je proste kravina, protoze se nic nekopiruje, jenom odkazuje

Spatne jsem se vyjadril a asi spatne citoval, byla to reakce hlavne na gamera. Ten rozdil je v implementaci, ale ne semanticky. Hodnota je hodnota - presne jako ve vasem kodu, "zmena" hodnoty proste vytvori novou hodnotu, hotovo (a ani ta se v praxi nemusi kopirovat cela, protoze mame persistent data structures). I se zbytkem souhlasim a vcetne te synchronizace pri paralelizaci jsem se snazil napsat to same. Actor taky neni nic jineho, nez zpusob synchronizace zmen stavu.

Vnorene struktury jsou trochu problem, ale na to zase pomuzou lenses.

[Mirek Prýmek]

byla to reakce hlavne na gamera.

Aha, tak to jsme si nerozuměli, já to chápal přesně opačně

P.S. nemohli bysme si tykat, mně to vykání vždycky přijde jakoby mi bylo padesát a děsí mě to

Ten rozdil je v implementaci, ale ne semanticky. Hodnota je hodnota - presne jako ve vasem kodu, "zmena" hodnoty proste vytvori novou hodnotu, hotovo.

Já bych to asi polopaticky řekl takhle: celý to nepochopení je způsobený tím, že v imperativních jazycích se pracuje s pamětí - s chlívečky, které jsou nějak pojmenované a postupně do nic něco strkám. Tímpádem i dvě vlákna můžou vidět tentýž chlíveček a něco tam strčit.

U FP se nepracuje s chlívečky, ale s hodnotami. Hodnota je hodnota a nic se do ní nestrká, ani nikdo nemůže změnit 1 na 2 a ještě ke všemu tak, aby pak 1 bylo 2 i v sousedním vlákně. 1 je prostě 1 vždy a všude

[gamer]

Jenže tohle se prostě ve FP neděje, to je představa přenesená z imperativních jazyků. Ve FP se nepracuje s žádnými referencemi v tomhle smyslu. Pokud mám dvě funkce f1 a f2, jedna přičítá jedničku a druhá dvojku, a předhodím jím tentýž stav (5), tak mi prostě jedna vrátí 6 a druhá 7, to je správně a má to tak být.

Však jo, já neříkám nic jiného, takhle to v FP funguje a má fungovat. A FP se taky zaklíná tím, že mávnutím kouzelného proutku řeší problémy s paralelizací a synchronizací, které mají imperativní jazyky. Řeší, ale nikoliv obecně, funguje to jen pro určité úlohy. Ve chvíli, kdy se jedná o nějaký složitejší problém (paralelním výpočtem vznikne více různých scén), tak nemám žádnou metodu, jak je dát deterministicky dohromady a stejně skončím na tom, že i v FP výpočet musím spustit buď v jednom vláknu, nebo řešit nějakou interní synchronizaci na úrovni jednotlivých objektů.

[M.]

A FP se taky zaklíná tím, že mávnutím kouzelného proutku řeší problémy s paralelizací a synchronizací, které mají imperativní jazyky. Řeší, ale nikoliv obecně, funguje to jen pro určité úlohy.

Nu, prostředí s immutable daty neřeší vše, ale odstraňuje řadu synchrobnizačních problémů, které řeším nad muttable daty se zámky/bariérama a podobnými, aby si např. různá vláka nepřepisovala nahodile a neřízeně data. Tento přístup předchází i vzniku celé řady deadlockům z toho (ale ne všch) a zjednodušuje to.
Nicméně pro situace, kdy musí docházet k synchronizaci mezi různými částmi aplikace z podstaty problému co řeší, tak ji musím stejně definovaně řešit (jenom patříčnými prostředky daného prostředí, např ty zmíněné actory v Erlangu a hromadě dalších).

[Mirek Prýmek]

Však jo, já neříkám nic jiného, takhle to v FP funguje a má fungovat. A FP se taky zaklíná tím, že mávnutím kouzelného proutku řeší problémy s paralelizací a synchronizací, které mají imperativní jazyky. Řeší, ale nikoliv obecně, funguje to jen pro určité úlohy. Ve chvíli, kdy se jedná o nějaký složitejší problém (paralelním výpočtem vznikne více různých scén), tak nemám žádnou metodu, jak je dát deterministicky dohromady

Ale samozřejmě že máš, vždyť jsem ti napsal několik metod. 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.

Jinak, asi nejlepší přístup, který se dá pro hry použít, je FRP. Viz

• https://youtu.be/1MNTerD8IuI?t=7m23s
• https://leanpub.com/gameinhaskell

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

• http://helm-engine.org/
• http://blog.chucklefish.org/wayward-tide-technical-details/
• https://www.youtube.com/watch?v=JleoASegUlk
• https://www.youtube.com/watch?v=0jYdu2u8gAU

[Pavel Tisnovsky]

Řekl bych, že to zmatení s immutable a víc vlákny je z tohoto pohledu:
Mám immutable data, řekněme číslo 5 někde, a mám dvě vlákna, které mají referenci na tu 5 (obě vlákna drží ukazatel na stejnou adresu), pokud obě provedou příčtení čísla 2 , tak dojde k copy on write, obě vlákna ukazují na číslo 7, ale na dvou místech (a pokud původní 5 už nikdo nedrží, likviduje ji GC). Gamer se ptá, jak udělat, aby když ty dvě vlákna to přičtení udělají, aby viděly výsledek 9....

Takové chování taky v některých FP jazycích dosáhneš, ale je tady jedno velké ALE: v těchto jazycích (dobře budu mluvit konkrétně o Clojure) se nepoužívají běžné proměnné, ale (zjednodušeně) speciální formy referencí na neměnná data. Takže máš například tzv. atomy, jejichž změna je z pohledu vlákna synchronní, tzv. agenty, kde je změna asynchronní (nemusí nastat hned) a refs, jejichž změnu (reference, ne hodnoty) je nutné udělat uvnitř transakce. Již jenom toto rozdělení dost dobře programátora donutí o řešeném algoritmu přemýšlet a ne semtam do kódu vrazit "synchronized" (což je zaprve pesimistická varianta, zadruhé DL čeká za nejbližším rohem :-)