Zobrazit příspěvky
Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.
Ve funkci, která mění pozici pomeranče, opravdu nepotřebuju celou scénu, stačí mi ten pomeranč.
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ší ;-)Zmínil jsem ty zástupné commandy. Protože to vypadá, že si si to nedomyslel, tak popíšu:
V rámci tiku, každý objekt dostal stejnou scénu. Jeho úkolem bylo určit a vrátit co chce na té scéně změnit.
To už jsme řešili, stejný přistup jako v Pac-Manovi. Generuješ eventy, které říkají, jak se má scéna změnit a uděláš to ex-post. To taky není dobré, budeš tam mít kolize a vzájemně si odporující eventy.
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š ;-)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ý.
Povedzte Kefalín, čo vy si predstavujete pod takým slovom "rozumě"?A není to naopak? Že v této jediné věci ti FP moc nepomůže, zatímco ve všem ostatním ano? Zkus si přečíst naše příspěvky. Vždyť ty vůbec nereflektuješ co popisujem.
V čem mi pomůže? Že nejde rozumně udělat změnu ve scéně? Zkuste si přečíst, co píšu já.
scene' = setScene scene (100,100,100) pomeranc
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ě.No, ve skutečnosti jsem to dělal pomocí zástupných commandů, ale ten princip, ať si to nekomplikujem je ten, že jsem funkci předal celou scénu, a vrátil novou.
Na tom je krásně vidět, jak tě funkcionální omezení dotlačilo do prakticky asi nejhoršího řešení. Neber to jako kritiku, ta úloha ve funkcionálním přístupu nemá žádné dobré řešení.
Co je na tom zásadně špatně:Zmínil jsem ty zástupné commandy. Protože to vypadá, že si si to nedomyslel, tak popíšu:
1) Funkce by měla pracovat jen s daty, která opravdu potřebuje. Ty předáváš celou scénu, i když s ní funkce provede jen nějakou omezenou operaci. Vůbec nevíš, co se kde zpracovává za data.
2) Nejde to paralelizovat. Jednotlivé funkce musíš spouštět sekvenčně.
3) Vytvářet kvůli každé jedné izolované změně novou scénu je neefektivní.Nevím jak v jiném jazyce, ale v Haskellu je to zadarmo. (Samozřejmě nebavíme se o vytváření nové scény od nuly, ale to už tu Prímek vysvětloval.)
Kdybys to napsal rovnou imperativně, bylo by to přehlednější, rychlejší a udržovatelnější.Opravdu nevidím důvod si něco takového myslet. Můžeš mi to vysvětlit? Bohužel výše uvedené tři argumenty pouze naznačují, že nemáš zkušenosti jak FP funguje.
A není to naopak? Že v této jediné věci ti FP moc nepomůže, zatímco ve všem ostatním ano? Zkus si přečíst naše příspěvky. Vždyť ty vůbec nereflektuješ co popisujem.A musíš hlídat, že pomeranče nemají někde schovaný odkaz na citrony.
V tom případě sdílím i citrony. A FP mi nijak nepomůže, sychronizaci citronů musím i v FP řešit stejně jako sychronizaci pomerančů, pokud jde s citronem přes pomeranč provádět nějaká akce.
No, ve skutečnosti jsem to dělal pomocí zástupných commandů, ale ten princip, ať si to nekomplikujem je ten, že jsem funkci předal celou scénu, a vrátil novou.No, já jsem to řešil tak, že jsem měl scénu, ta měla tiky, a v každém tiku jednotlivé objekty udělaly změny na scéně co potřebovali.
Moment, tohle je imperativní přístup s mutable objekty, co mi uchází? Nebo jsi jako parametr do funkce předal celou scénu a z funkce dostal novou scénu?
No dobře. Teoreticky nemusíš hlídat všechno. Prakticky, když jsem to nehlídal, tak jsem nedotáhl projekt do konce.No musíš hlídat všechno. Protože všechny objekty máš mutable. To znamená nevíš dne a hodiny, kdy ti někdo nepřepíše.
Ne nemusím hlídat všechno. Hlídám jen objekty sdílené mezi vlákny. Když sdílím pomeranče, hlídám pomeranče. Když nesdílím citrony, tak je ani nemusím hlídat.
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é.
a = getAccount
b = getBalance a
setBalance a b+1
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ě.
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?
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.
Přesně! Tady nejde o zatvrzelé odpůrce dědičnosti, ale o zatvrzelé zastánce dědičnosti pro nevhodná použití. Dědičnost na code reuse se používá proto, že máme blbý jazyky, který to lépe neuměj.
Je to přesně obráceně
Proč tady musí být zatvrzelí odpůrci versus zatvrzelí zastánci dědičnosti? Je tak těžké pochopit, že někdy se dědičnost hodí a jindy ne?
Protože code reuse. Mít čtyři různé objekty je teoreticky správné, ale prakticky nežádoucí a kontraproduktivní. Stejně ty čtyři různé objekty budou jenom boiler plate pro volání funkcí společných pro všechny čtyři varianty.
Takže když programátorům zakážeme používat dědění, tak bude problém vyřešen, ne?To je dost nesmysl, bo code reuse.
Prakticky každá firma (co jsem viděl), která měla zoufale neudržitelný kód ho měla zoufalí proto, že dědily kůli code reuse. Takže za mě fakt ne!
To je lidma, ne děděním.
Někteří diskutující by z obavy před porušením LSP nejraději tyhlety dědičnosti úplně zakázali a vyhodili z OOP.
To je dost nesmysl, bo code reuse.
Root.cz (www.root.cz), informace nejen ze světa Linuxu. ISSN 1212-8309
Copyright © 1998 – 2023 Internet Info, s.r.o. Všechna práva vyhrazena. Powered by Linux.