Vlákno názorů k článku
Jak vytvořit pseudo 3D hry v HTML5 canvasu s raycastingem

Proc delat neco efektivne, kdyz to jde i neefektivne. Nechapu lidi, co tohle delaji. K cemu je to dobre? Misto aby se prosazovalo programovani efektivnich aplikaci, tak se takto plytva vypocetnimi zdroji.

Ono ide o to, ze efektivita je casto nepriamo umerna zrozumitelnosti kodu. A pri takychto prikladoch, samozrejme, nejde o to urobit to co najefektivnejsie, ale co najprehladnejsie a zrozumitelne. A podla mna je clanok fajn...

Takisto by ma potesilo, keby sa Canvas a HTML5 presadili na ukor Flash-u. Avsak je pravda, ze keby sme mali nieco taketo uz skor, Flash by davno nebol tak rozsireny (ak vobec), ako je teraz.

Mam na mysli neefektivitu jakychkoliv aplikaci bezicich v prohlizeci napsanych v javascriptu.

Prave ze to jste uplne vedle -- vemte si, jak to bezi na starsich prohlizecich, jak pomalu to bezi na starsich pocitacich s novymi prohlizeci a vemte si, jak se plytva vykonem pocitace, a jak se plytva i vasim casem, kdyz na tu aplikaci musite cekat. Mnohem efektivnejsi by bylo stahnout si binarku a spoustet primo tu.

Vy rikate, ze o tom to je, ale soucasne prohlizece maji vazne problemy s vykonem, tudiz je otazkou, zda-li je dobry napad implementovat do nich aplikace.

Osobne bych rekl, ze Java i .NET urcyhluji vyvoj aplikaci a zvysuji jejich bezpecnost, zatimco javascript nedela ani jedno.

S kompatibilitou je na tom asi stale nejlepe C.

S tim Flashem s vami naprosto souhlasim.

To je otazne.Java aj .NET akurat presunul problematiku bezpecnosti z programatora na deployment a prostredie.Inak povedane bezpecne nastaveny system s c/c++ aplikaciou (ktora je maximalne safe ako moze byt) je rovnaka ako nejaky VM.Ostatne v Unixoch napriklad chroot existuje dlho.Problem s verziami a kniznicami je aj pod Javou/NETom len sa to ako som napisal presuva inde.Co sa tyka urychlenia vyvoju, to je zasa otazne.Klikacie generatory kodu/gui sa daju spravit na kazdy jazyk.Davno pred nejakym Swingom alebo C# gui editorom v MSVC tu bolo napriklad Delphi, ktore co sa tyka RADu aj dnes nema moc konkurencie (bohuzial ale iba co sa radu tyka,ostatne taky VB tiez dost veci kopiroval,alebo naopak).Obcas mam pocit ze sa objavuje objavene a este mame MS/Adobe/Google a ostatnym za to asi tileskat.
Mimochodom z aktualneho web developmentu a trendov je mi dost nevolno.Jedina vec z ktorej v poslednej dobe mam aspon trochu pozitivny pocit je Flex.

Problém s verzemi a knihovnami v .NETu prakticky není - vše je jasně definováno, knihovny se podepisují. Bezpečnost je násobně vyšší oproti nativním programům (např. buffer overflow útokům atd.). Jestli si myslíte, že efektivita .netu je v naklikávání, tak jste v tom asi moc nenapsal.
Javascript a další technologie uměle naroubované na html - to je slepá ulička, kdo to pochopí, ušetří neuvřitelné množství peněz a času.

zacal som to citat a pozerat v praci na winxp/chrome, docital a dopozeral doma na fedora/firefox. o tom to je.

nikto vas nenuti robit v javascripte simulaciu vybuchu atomovky, ale na ucel prezentacie algoritmu je javascript celkom fajn.

Jeste bych doplnil, ze ne vsechny prohlizece podporuji javascript a ne vsichni uzivatele ho maji zapnuty.

U JS bych trochu brzdil. V tuhle chvíli sice neláme rychlostní rekordy, ale počkejme si nějaký pátek a možná se ještě všichni budeme divit. Mnoho společností investuje mnoho peněz do vývoje JS. Proč? protože mu věří. Takže s JS tutoriáli - jen víc a houšť.

Zakladnim duvodem je zpristupnit programovani/ovladani prostredi vice uzivatelum
(Je otazkou jak moc je to zvrhla myslenka - osobne myslim, ze neni spatna - jelikoz dnes a denne vidime na internetu priklady velmi zajimavych reseni, myslenek, projektu, ktere by nevznikly byt tu jen assembler).

Zprehlednovanim kodu, snadnejsimi vyvojovymi nastroji, a upoutanim uzivatele tech.demem jako je toto, se laka uzivatel k tomu aby se do programovani pustil. To je neci marketing. Ale zaroven je to prinosne(viz text v zavorkach vyse).

Proto panove nepiseme v assebleru a stranky si neprohlizime v textovem modu na zelenocernem monitoru.

Tim chci take rict, jen houst s takovymi tutorialy! Root vede!

Za redakci Zdrojáku děkuji 8-)

Myslim, ze divit se nebudeme, protoze pokud se JS radikalne nezmeni (nezavede silne typovani), bude stale umorne pomaly. Uvedomte si prosim fakt, ze kdyz mnoho spolecnosti do neceho investuje a necemu veri, tak to neznamena, ze neexistuje neco lepsiho.

chtel jsem napsat silne staticke typovani

Se statickým typováním nemáte úplně pravdu. Zrovna můj dnešní článek tady na Zdrojáku ukazuje, jak se s absencí typových deklarací poměrně úspěšně vyrovnává interpret SquirrelFish (WebKit/Safari) - jednoduše si potřebná data posbírá v runtime. Podobně to dělá V8 (Google Chrome). SpiderMonkey/TraceMoneky (Firefox) zas používá techniku trace trees, která nedostatek informací o typch také v určitých případech dovede obejít.

Pokud se interpret napíše opravdu dobře (což ale stojí poměrně hodně úsilí, proto se to moc nedělá), dá se s ním dosáhnout rychlosti blízké rychlosti céčka. Viz zmínka Avi Bryanta o Strongtalku, dialektu SmallTalku:

Strongtalk is that it does allow optional static type annotations, but the optimizer completely ignores them: your code runs exactly as fast if you duck type everything as if you statically type everything. That’s not because the implementors were lazy - their goal was to produce the fastest system possible, it’s just that their dynamic implementation was already fast enough that the static information didn’t help.

Podobně také viz jazyk Self:

Despite this complete devotion to objects, Self code runs at up to half the speed of optimized C, the high performance being achieved through dynamic profile-driven optimization.

JavaScript na tom sice nyní tak dobře, aby běžel polovinou rychlosti céčkového kódu, není, ale není nepravděpodobné, že brzy někde okolo těchto hodnot bude.

Optimalizace ve vasem clanku uvedene v castech "Pristup k vlastnostem objektu" nebo "Typova inference" se prakticky jen snazi zmirnit fakt, ze chybi typove informace -- resp. kdyby tam typy byly tak k clenskym datum objektu muzete pristupovat v case konstantnim a bez nejake rezie ci optimalizace.

Jazyk Self neznam, nicmene srovnavate, ze rychlost jeho interpretru se blizi rychlosti kompilovaneho C, coz je sice chvalihodne, ale je otazka, zda je vystup kompilatoru C skutecne ultimatni cil, zda nejde jit jeste dale.

Problem jazyka C je zejm. prima manipulace s pameti, kde kompilator nemuze nic moc delat. Napriklad jazyky jako Clean, Haskell maji potencialne moznost toto vyresit mnohem lepe -- navic uz ted provadeji optimalizace celych programu.

Vemte si napriklad kompilator omezene varianty jazyka Scheme jmenem Stalin, ten je schopen vyplodit rychlejsi kod (preklada do C), nez je rucne psany kod v C. Porad ale plati, ze kompilatory dynamickych jazyku se musi spolehat predevsim na urcitou intuici (nebo na statistiky z predeslych behu programu) -- tudiz vysledek neni jisty. Zato kompilatory staticky typovanych jazyku nemusi pouzivat intuici k detekci typu, protoze je maji predem (jasne) dane.

Je treba uznat, ze kompilator staticky typovaneho jazyka je proste ve vyhode oproti kompilatoru dynamicky typovaneho jazyka, nebot ma informace navic.

Je treba uznat, ze kompilator staticky typovaneho jazyka je proste ve vyhode oproti kompilatoru dynamicky typovaneho jazyka, nebot ma informace navic.

S tím souhlasím. Jen sem chtěl vyvrátit vaše tvrzení z komentáře, že JavaScript bude bez statického typování "úmorně pomalý". Ztráta informace absencí typových deklarací vadí, ale nevadí tolik, jak se může na první pohled zdát.

Máte samozřejmě pravdu, že céčko není ultimátní cíl; zmiňované problémy s ukazateli se vysvětlují na každé přednášce z kompilátorů. Bral jsem to zde spíš jako referenci (vágní, ale často používanou).