Příspěvky

676

Vývoj / Re:Omezená dědičnost (je něco lepšího než OOP?)

« kdy: 15. 09. 2015, 10:15:48 »

Složité myšlenky se špatně udržují, proto se do reálné praxe nehodí.

Takze misto napr. flatMap a foreach na jeden radek davate prednost ciste imperativnimu pristupu - ukecany cyklus na nekolik radku? Vzdyt to nic neprinasi, jen delsi kod. Nevim, prijde mi, ze slozite myslenky se lepe transformuji na jednoduche ve FP - mam nekolik funkci ktere postupne vstup zpracuji. V imperativnim programovani to casto skonci velkou metodou s nekolika vnorenymi cykly.

I reálné algoritmy v živé přírodě, které vznikly díky evoluci, nejsou ve své podstatě složité a jsou složeny z interakce jednoduchých elementů. A nejen tam. Například úplný soubor logických funkcí tvoří Shefferova funkce. No až v Haskellu nebude if a nebo while, tedy imperativní prvky, pak možná bude čitelný a elegantní :-) Zaměnit if a : y za y = if a : c moc elegantní není. Z hlediska čitelnosti programu je to katastrofa, protože se vám tam vynořuje to c, a musíte hledat, o co vlastně jde. Jistě u programu o 10 řádcích to problém není, problém to už je, když těch řádků jsou tisíce. Navíc, abyste někdy v budoucnosti mohl modifikovat to c, musíte dojít až k jeho zdroji, a zpětně prohledávat řetězy transformací imutable objektů, protože to c máte samozřejmě použito ve více místech programu a změnit ho potřebujete jen v jednom místě. Přidání modifikačního dekorátoru v místě použití situaci neřeší. Jen systém znepřehledňuje.

No, abych byl uprimny tak se moc nechytam. c? Kdyz jsem delal tu chvilku v Haskellu, tak v tymu byla snaha mit funkce co nejkratsi a nejstrucnejsi, idealne vzdy s tim typovym zapisem (ten projektik presahl tisic radek urcite). Navic FP je snad zalozeno na tom, ze mame jasny vstup a vystup, vse bez vedlejsich efektu, jak se tedy c muze nekde ztracet?

677

Vývoj / Re:Omezená dědičnost (je něco lepšího než OOP?)

« kdy: 15. 09. 2015, 09:30:36 »

Vyjadřovací schopnosti programovacích jazyků nejsou na úrovni textu prózy, ale na úropvni čtení básní, proto i struktura textu je důležitá. A FP jazyky ji mají přímo katastrofální.

Zrovna napr. takovy Haskell dost lidi povazuje za prekrasny jazyk - lze strucne a vystizne zapsat slozite myslenky. Samozrejme pokud si nekdo pod hezkym kodem programu predstavuje co nejvice nevyznamoveho balastu (Java/Python), pak je IMO neco spatne.

678

Vývoj / Re:Omezená dědičnost (je něco lepšího než OOP?)

« kdy: 15. 09. 2015, 08:20:33 »

Nad JVM nebo CLR můžete postavit jazyky se silnějšími typovými systémy než má Haskell.

Ostatně Scala nemá ostře slabší typový systém než Haskell. Na rozdíl od Haskellu má Scala navíc podtypový polymorfismus. Důsledkem toho je slabší typová inference.

Mel jsem na mysli predevsim generiku a inferenci. A to, ze to "jde" postavit, neznamena, ze by se melo - vykon muze byt dost zalostny, pokud se bude muset uzivat ve velkem reflexe protoze omezeni JVM (ikdyz myslim celkem dost toho padlo, nekde jsem cetl neco s dynamic instrukcemi).

Generika JVM je dost chaba. Ve Scale se musi pouzivat berlicky v podobe tagu a v podstate simulovat runtime podporu generiky pomoci reflexe. CLR je o uroven vys.

No, je mozne ze je to dusledek toho podtypoveho polymorfismu (netusim), ale faktem je, ze oproti Haskellu se musi Scale opravdu casto pomahat (jiste, porad lepsi nez Java).

679

Vývoj / Re:Omezená dědičnost (je něco lepšího než OOP?)

« kdy: 14. 09. 2015, 21:01:25 »

Spíš se ale trochu bojím toho, že kvůli technickým a manažerským omezením se FP do mainstreamu dostane ve stejně vykastrované podobě jako se to stalo OOP

Nekteri rikaji, ze se Scala stane dalsi Javou (osobne tak optimisticky nejsem, myslim ze je prilis "slozita" pro bezne pohodlne Javisty). Bohuzel kvuli omezenim JVM se ten typovy system rozhodne nemuze rovnat treba Haskellu (a to s nim mam zkusenosti jen z maleho skolniho projektu).

Cim dele si ctu tuto diskuzi (nechce se mi az verit te vyspelosti prekladacu/runtimu), tim vice mam nutkani se navratit ke zkoumani Haskellu po vecerech . Nejaky tip na video kurzy/prednasky?

680

Vývoj / Re:Omezená dědičnost (je něco lepšího než OOP?)

« kdy: 14. 09. 2015, 19:50:56 »

... Jde spíš o to, že pokud se mají vysokoúrovňové jazyky a zvláště FP posunout dál, budou asi muset hledat jiné cesty než kopírovat C či Javu.

Pusobi to na me tak, ze zrovna na hry by se FP poustet nemelo. Resp. ne do te doby, nez budou optimalizace na urovni stavajicich prekladacu/virtualnich stroju (tzn. ze prekladac bude opravdu spolehlive transformovat funkcionalni veci na imperativni). IMO zacit by se melo tam, kde trochu horsi vykon je vyvazen rychlejsim vyvojem. Velmi podobna pozice jakou mela Java - ma (melo) to maly vykon, ale vyvoj je velmi svizny, takze to vyvazi ty nevyhody: $ za vyvoj >> $ za hw => radeji koupime lepsi/vic hw.

681

Vývoj / Re:Omezená dědičnost (je něco lepšího než OOP?)

« kdy: 14. 09. 2015, 17:24:43 »

Jinak celkově debatu nechápu. Porovnávají se tu dvě řešení: s eventy a bez, a jedno z nich "se považuje" za funkcionální. Co komu brání napsat v imperativním přístupu řešení s eventy a získat tím také výhodu změn scény a tedy možnost vzniku kolizí pouze na jednom místě? IMHO ani jedno z prezentovaných řešení nijak nesouvisí s paradigmatem jazyka, v kterém ho budete implementovat.

To si myslim nikdo netvrdi, akorat se tak asi nedeje. Pokud jsou vhodnejsi nastroje pro implementaci daneho reseni (eventy) ve funkcionalnich jazycich, tak asi lide vice tihnout k tomu uzivat ty funkc. jazyky pro dane reseni. Priklad: pri psani utilitky v Pythonu jsem se snazil to psat funkcionalne, ale prestoze to jde, tak je to tak krkolomne a neuveritelne uzvanene... Napr. na Scalu [nebo nedej boze Haskell] to proste nema.

No, rekl bych, ze ta druha moznost - mutable data ve funkcionalnim jazyku - nebude moc typicka .

PS: Jak pise pan Prymek, neni to jedine reseni. Napr. Akka (knihovna s actory) je dostupna i pro Javu, ktera neni urcite funkcionalni jazyk.

682

Vývoj / Re:Omezená dědičnost (je něco lepšího než OOP?)

« kdy: 14. 09. 2015, 16:54:16 »

Presne jak pise Radek Miček (ten typ predstavuje mapu [slovnik] ze souradnice [triple intu] na int [id bloku - napr. trava, kamen]; primitivnim intem myslim datovy typ, ktery v JVM IIRC odpovida 64b integeru, ne-primitvni by byl objekt obalujici int [v Jave Integer?]).

Problem je v tom, ze pri uvedenem prikladu s bloky se pocita doslova kazdy bit - "struktura" predstavujici blok (v nasem pripade 64b int, kde cast myslim tvori bitove flagy) - se opakuje ~20 milionkrat (a to se bavime jen o klientovi, server muze mit desitky hracu, tzn. nasobne vice prace). Implementace chunku jako Map[(Int,Int,Int),Int] by znamenala minimalne 300% pametovy overhead (explicitni souradnice) a bylo by to podstatne pomalejsi, protoze pro vyhledavani v teto strukture se budou pouzivat hashe souradnic, prestoze by to mohlo byt v klidu pole intu (mozna ne o tolik pomalejsi, jit optimalizator obcas dela zazraky; navic pri vyhledavani se bude konstruoovat triple podle ktereho se vyhledava). Muj priklad je extrem (mluvim z pohledu JVM, Haskell skoro neznam), nikdo by neco takoveho asi ani nezkousel, ale celkem dobre to ilustruje podstatu.

PS: Prace s ukazateli v Haskellu nevypada vubec vabne (pripadam si jak kdybych cetl C++ kod).

683

Vývoj / Re:Omezená dědičnost (je něco lepšího než OOP?)

« kdy: 14. 09. 2015, 14:47:25 »

Chyba v úvaze je v tom, že předpokládáš, že ten objekt něco renderuje.
Logické rozdělení je to z pohledu toho, zda se mohou elementy ovlivňovat.

Bohuzel pro rychle vytvoreni modelu (meshe) je myslim nutna tato reprezentace (ikdyz sam se nerendruje, je rendrovan). Uzivaji se co nejefektivnejsi datove typy (tusim pole id bloku - primitivnich intu; overhead pri pouziti napr. Map[(Int,Int,Int),Int] by byl primo monstrozni). Je take treba si uvedomit narocnost voxeloveho sveta - std. dohlednost je IIRC 10, tzn. 20x20chunku = 400x16^2x256 bloku = ~26 milionu bloku (kazdy blok az 6 sten ruzne textury a osvetleni). To je nutne efektivne skladovat, jinak dojde pamet velmi rychle (zanedbal jsem napr. osvetleni, sky flag, tile entity a urcite dalsi veci).

Zkus si představit jednoduché lineární pole objektů (pańáců a pomerančů). Pak můžeš mět jakýsi strom, který určuje, kde se které větve mohou ovlivňovat. Sourozence můžeš paralelizovat (když si to čtu, tak to zní děsivě, ale popisuji spíše potenciál, protože v praxi by to byl spíš takovej keř). A v každém ticku se ti v tom stromu provedou výpočty a v kořeni ti vypadne seznam všech změn, které musíš provést na scéně. Až tady máš to místo, kde budeš renderovat. A kde můžeš perfektně optimalizovat (zničení chunku, a vygenerování už finálního se všemi elementy, renderování jen viditelné scény, atd). A díky tomu, že mám seznam všech změn, mohu zkusit paralelizovat i to renderování.

Na entitach si to celkem predstavit jde (je jich pouze par, v pripade MC tak do stovky v okruhu viditelnosti), ale v pripade bloku? Mit stromy i pro bloky, napr. pro kazdy blok lavy (blok vyskytujici se v "prirode", tj. muze byt ve velkem mnozstvi soucasti sveta), ktery muze zapalit horlave objekty ve svem okoli, bude vetev v tom stromu? To bysme se posunuli o rad, mozna o dva. V kazdem ticku se muze lava "rozlit" dale (zmen za tick u lavovych jezer muze byt tedy mnoho), opravdu si nedovedu predstavit, ze by generovani toho stromu trvalo kratsi dobu, nez neparalelni puvodni verze. Kdyz vidim, jake vykonostni problemy jsou v aktualnim MC obcas s tokem vody, lavy a prepocty osvetleni (kteremu ta tvorba stromu bude asi celkem blizko), tak mi prijde, ze tohle reseni nemuze fungovat (ale mozna to jen klame, fakt nevim).

V zaveru mi z toho tedy vyplyva, ze by musela zustat stavajici reprezentace (pouzivat strom pro meshovani sveta si myslim rozumne nepujde) a paralelne udrzovat strom ovlivnitelnosti. Pomoci nej paralelizovat tick a z vysledneho seznamu zmen paralelne zpracovat vsechny chunky zaraz (prikazy pro 1 chunk tedy budou sekvencni, coz nevadi, maloktere (?) pouzivane cpu ma vice nez 400 jader). Je otazka, zda rezie spjata s udrzovanim/generovanim stromu a rozdelovanim prace (seznam zmen) nevyjde hur, nez stary jednodussi pristup (tyto zmeny se budou bezne provadet klidne nekolikrat do vteriny, pokud budou trvat dele nez jeden frame, tak se hra zacne "skubat"; anebo by se muselo zacit resit nejaky "shadow world" ala "shadow dom", to ale nevim, jestli by pametove fungovalo).

Jak by se to dalo dělat lépe? JS navrhoval Monády, ale (pravděpodobně díky nedostatku zkušeností) bych se bál aby mi z toho nevylezl podobnej nepřehlednej mrdník, jaký obhajuje gamer u svého mutable řešení.

Prijde mi, ze tema programovani her je velmi narocne - musi se zajistit velmi dobry vykon, pritom ale stabilni (aby nekolisalo FPS). U voxelovych her je vse jeste umocneno nepodporou enginu i GPU. Pritom zrovna ty voxelove hry jsou myslim primo idealni pro masivni paralelizaci (a tedy i pro FP?).

Omlouvam se za dlouhy post. Doufam, ze jsem nektere veci moc nezjednodusil nebo spatne nepochopil. Jen dodam, ze jsem napsal velmi jednoduche rendrovani voxeloveho sveta v jME a od te doby jsem zacal mit respekt k Minecraftu a jeho (ne)dobremu vykonu .

684

Vývoj / Re:Omezená dědičnost (je něco lepšího než OOP?)

« kdy: 14. 09. 2015, 08:22:22 »

Nezapomínej, že to rozdělení musí být logické, ne adminstrativní.

Logicke rozdeleni to je z pohledu vykonu - pri kazde zmene chunku (napr. zniceni bloku) je treba znovu vytvorit mesh (3d "model" chunku, rendrovat blok po bloku to opravdu nejde, vytvori se jen model s viditelnymi stranami bloku), coz je draha operace a pri nevhodne velikosti to povede k vykonostnim problemum (velky chunk -> casteji a dlouho se generuje, maly chunk -> vice rezie).

A klidně to můžeš dělat i během života (postaví zeď atd).

Po pravde, az takto dynamicke rozdelovani sveta zni velmi narocne. Kdyz si vezmu, ze jen hloupy algoritmus pro svetlo (trivialni flood-fill, navic s podstatne nizsim polomerem nez je napr. dostrel luku) pusobi vykonostni problemy.

685

Vývoj / Re:Omezená dědičnost (je něco lepšího než OOP?)

« kdy: 13. 09. 2015, 22:28:41 »

Já jsem tomu objektu nepředával celý svět, ale jen adekvátní výřez (zjednodušení, ve skutečnosti jsem to měl optimalizované ještě jinak). Například když byl objekt jakože v místnosti, tak dostal jen tu místnost. Protože za zeď nevidí, že jo. Mělo to ten efekt, že jsem to mohl paralelizovat, každá "místnost" mohla běžet samostatně. Myslím, že Prýmek tomu říkal partioning.

To zni zajimave, bohuzel si nejsem jisty, jestli to muze vsude fungovat - napr. ten zminovany Minecraft. Kdyz mam svet rozdeleny na casti (chunky - 16x16x256 bloku IIRC), tak hrac na kraji jednoho chunku zcela jiste muze (a casto bude) interagovat z blokem z jineho chunku. Mozna to rozsekat podle maximalniho mozneho dosahu jakekoliv interakce s prostredim, nebo podle dohlednosti? Co jsem kod videl posledne, tak se to proste neresilo - pro kazdy svet bylo vse serializovane (ticky bloku, entit, tile entit).

Zajímalo by mě, na jaké nevýhody můžu u FP narazit. Zatím, co vím, tak že takovej Haskell je výkonově na úrovni Javy.  Což zase není tak hrozné, a možná by to chtělo nějaké lepší benchmarky. ...

To me celkem zarazilo, myslel jsem, ze Oracli HotSpot ma celkem vychytany optimalizace za behu. Nebo ze by ten funkc. pristup byl o tolik lepe optimalizovatelny (ve Scale jsem pozoroval spise opak )?

686

Vývoj / Re:Omezená dědičnost (je něco lepšího než OOP?)

« kdy: 13. 09. 2015, 20:13:18 »

Tato diskuze je velmi zajimava .

... Ale pro mě přináší oproti FP dvě zásadní věci, umožňuje mi udržet rozhraní minimalistické (nemusím všude pracovat s celým světem) a umožňuje mi udržet svět v konzistentním stavu.

V programovani her mam zkusenosti jen s tvorbou modu pro Minecraft, je mozne, ze to jde delat i jinak (nebylo by to poprve). Ale to s minimalistickym rozhranim (minimalne v MC) proste neplati. Napr. z kazde entity mohu vytahnout instnaci sveta a delat uplne cokoliv. To je jen iluze minimalniho rozhrani, pokud stejne mohu pristupovat kamkoliv - je to stejne jako f(world) -> world ve FP. Akorat tam je to explicitne receno, ze se s tim svetem neco muze stat, zatimco pri player.setDirection(1,0,0) nepoznam, jestli to nahodou nezasahuje i do jinych casti sveta. Nebo se v "opravdovych" hrach toto takto neresi (zadne zpetne reference atp.)?

687

Studium a uplatnění / Re:Má cenu studovat IT navazující?

« kdy: 08. 09. 2015, 13:16:34 »

pokročilé předměty typu Teoretická informatika

Z vlastni zkusenosti mohu rict, ze navazujici na VUT v Brne byl kvuli par predmetum celkem peklo a osobne si nemyslim, ze ma smysl je vyucovat tak a v takove mire, jak se uci dnes. Naopak co jsem slysel o MUNI, to bylo mnohem povzbudivejsi. Kdybych se rozhoval znovu, z FITu bc a z MUNI mgr.

PS: Pokud jde o FIT, tak o regexech (teorii - formalni def., automaty) se ucilo minimalne jednou i pred TINem, takze to rozhodne neni tak, ze by clovek o tom slysel poprve az v TINu.

688

Vývoj / Re:Native queries (aneb databáze a OOP)

« kdy: 30. 08. 2015, 15:16:16 »

Když se SQL generuje z bajtkódu v runtime, je to NQ, ale když se generuje za běhu programu, je to SODA? Trochu se to komplikuje...

Ehm, není to přesně to samé? Nebo jde jen o ten bytekód (to nezní moc obecně)?

689

Vývoj / Re:Obdoba where T : new() v Javě

« kdy: 29. 08. 2015, 13:02:32 »

... V Javě ale zaboha nemůžu přijít na to, jak to udělat (kromě odporného použití reflexe, což pochopitelně nechci). ...

Na pouziti reflexe neni inherentne nic spatneho. Bezne se pouziva a napr. v tomto pripade bych ji preferoval pred tovarnami = boilerplate. Jedinne opodstatneni kdy nepozit reflexi a spokojit se s berlickou jsou vykonostni problemy. (Ale i tam jsou pro nektere pripady alternativy, jak reflexi pouzit, pripadne prejit k dynamickemu generovani/modifikaci bytekodu za behu.)

690

Vývoj / Re:Javascript open modal

« kdy: 26. 08. 2015, 19:30:27 »

Co takhle?

Kód: [Vybrat]

<script>
    window.location = '#openModal';
</script>