Názory k článku
Webdesignérův průvodce po HTML5: Multithreading s WebWorkers

Vzpomínám si, kdysi o tom psal Martin Hassman. Já se ho ptal, zda tam půjde předat libovolný objekt, včetně třeba window. (Tím by šlo obejít omezení na manipulaci se stránkou.) Dostal jsem (přibližně) odpovězeno, že půjde předávat pouze primitivní datové typy. Tak nevím. V Opeře mini se mi to teď nechce zkoušet.

Podle originálu by mělo jít předat, cituji: „JavaScript objects such as Object, Array, Date, Math, String.“ Objekt window pravděpodobně předat nepůjde, bylo by to nelogické – mám takové podezření, že tam někde proběhne konverze na JSON a že pod pojmem „objekt“ je tu spíš míněna „datová struktura“.

No je to zaujimava moznost a v dnesnej dome pararelneho programovania a presadzovania viacjadrovych procesorov je to aj velmi pravdepodobna cesta. Ale osobne si myslim ze vzhladom na to ako dokaze byt js zabordelovany a neprehladny pridanie este aj vytvarania threadov a pararelneho programovania v js je uplne peklo. Uz len deadlocky v js tu chybaju. Osobne si myslim ze optimalizacie a pararelne vypocty by mali stale ostat na web browseri a jeho js interprete a nie na programatorovy a jeho kode v js.

Taková optimalizace na straně prohlížeče nikdy nebude mít rovnocenné výsledky s dobře napsaným paralelním kódem. Vážně bychom měli kvůli „programátorům“ zakázat tuto možnost lépe rozložit výkon?
JS je výborný jazyk a neřekl bych, že je „zabordelovaný“. Musíte se mu jen dostat pod kůži a (ostatně jako u všech jazyků) musíte psát jako člověk ;)

Samozrejme rucne napisany kod moze byt vykonnejsi, len je otazne ci cena za to a za potencionalne problemmy je adekvatna.
Dobre, poviem to inak, JS umoznuje velmi lahko spravit chybu a tak isto pisat prasacky kod. Samozrejme to neznamena ze je to zly jazyk ale proste fakt z praxe.

však nikdo nikoho nenutí WebWorkery používat =) … když někdo uzná za vhodné, že by je měl použít, tak už by to měl být někdo kdo se v JS vyzná

Prosím, mohl byste se podělit o název programovacího jazyka, který neumožní udělat jednoduše chybu a psát kód jako prase? Ano, chyba a prasácký kód v ECMAScriptu bude pravděpodobně vypadat jinak, než to samé v C#, jenže to platí i pro C# a Pascal, pro Pascal a C,…
Je-li programátor prase, je jedno, v čem píše.

Nikoliv, znamená stejnou pravděpodobnost udělání chyby, jenom ji compiler odhalí :)
Na druhou stranu, pokud pracujete s proměnnými typu object, pointer, variant apod. tak jako tak čert ví, co tam vůbec je :). A k tomu je potřeba pořádnost :)

Nikoli, pokud vám IDE napovídá.

Je mi líto, ale pokud máte typ pointer, IDE nemá žádnou možnost zjistit, co tam bude, až program poběží.

No, bavíme-li se o vyšších jazycích (jedna z mála podobností Javy a Javascriptu), řekněme s GC, tak tam nejsou pointery, ale reference. A kompilátor (popř. běhové prostředí) nedovolí udělat referenci nekonzistentní.

1/ jenže se můžeme bavit i o vyšších jazycích bez GC
2/ GC nemá s datovým typem a prací s tímto datovým typem nic společného
3/ i s GC se vám může vrátit pointer na datovou strukturu o ketré můžete jenom doufat, že tam je, co tam má být :)

No dobře, možná jsem špatně zobecnil. Takže, máme tyto možnosti:
* dynamicky typovaný jazyk – např. Javascript, Ruby, Python
* staticky typovaný jazyk – např. Java, C, C++, Scala
(Mixovanými jazyky jako Groovy++, C# a Mirah (aspoň v budoucnu) si situaci nebudeme komplikovat.)
a nezávisle (Má to myslím i nějaké oficiálně používané názvy, teď se mi to nechce hledat.):
* volná správa paměti (malloc apod.) – např C, C++
* striktní správa paměti (typicky s GC) – např. Java, Scala, Javascript, Ruby, Python
Zpracováním budu nazývat např. kompilaci nebo nějaké počáteční parsování apod. v závislosti na implementaci jazyka.
Asi se shodneme, že staticky typovaný jazyk má obecně větší kontrolu při zpracování než obdobný dynamicky typovaný jazyk. A podobně, jazyk se striktní správou paměti má při zpracování obecně větší kontrolu než obdobný jazyk s volnou správou paměti.
Dělat obecnější srovnání nemá asi moc smysl. Co do kontroly při zpracování, je asi jasné, že např. Java > Javascript, ale už se můžeme dohadovat, co doplnit místo otazníku do C ? Javascript.

Ještě jedna věc:
„3/ i s GC se vám může vrátit pointer na datovou strukturu o ketré můžete jenom doufat, že tam je, co tam má být :)“
To by byl asi poněkud specifický případ. GC, pokud nepoužívá ne úplně dokonalý reference counting asi nemá jinou možnost, než obsahu paměti dobře porozumnět. Ano, i za dodržení této podmínky by šlo asi vymyslet něco takového, jak říkáte, ale považuji to za extrémní.
„2/ GC nemá s datovým typem a prací s tímto datovým typem nic společného“
Jak jsem psal výše, má.

Extrémní? Nikoliv, pro někoho každodenní rutina, stačí pracovat s knihovnami, které alokují a uvolňují paměť sami, kdy si předáváte datové struktury mezi knihovnou (z pohledu kompilátoru a programového GC se jedná o blackbox) a programem a naopak.
Možná si jenom nerozumíme, samožejmě, že GC rozumí typům, ale nemá s prací s daným typem nic společného ve smyslu algoritmu programu (pokud integer, pracujete s ním stejně bez ohledu na přítomnost GC, integer se nemění na základě přítomnosti GC)

Knihovny, které paměť alokují a uvolňují samy, neřadím do GC.
Integer GC moc nezajímá, ale reference ano, včetně toho, co je na ní obsaženo. Znám dva typy GC:
* reference counting – Dobře, pro něj některá z uvedených tvrzení nemusí platit, ale na druhou stranu, tento GC si neporadí např. s cyklickými referencemi. Myslím, že se od něj dnes spíše upouští.
* Mark&sweep (včetně generačních, kopírovacích apod.) – tento tu paměť prolézat musí. Zajímají jej reference a všechny datové typy, které mohou obsahovat další reference. Proto představa nějakého pointeru, který odkazuje na neznámý typ, mi přijde zvláštní.
(Pokud existuje ještě jiný typ GC, rád se naučím něco nového. Existenci jiného typu GC jsem nevyvrátil. Na druho stranu, bavím se o dnešku, tedy to, co může být zítra, mě v tuto chvíli až tak nezajímá.)

Nemám na mysli jiný typ GC. K této diskuzi jsem se dostali z bodu, kdy jsme diskutovali, do jaké míry silná typovost, kompilátor a GC umožní odfiltrovat chyby. Odfiltrovat umožní, ale chybám v typu nezabrání. Ok odprostím se od pointeru a knihoven, uvedu jiný příklad, představte si, že máte proměnnou typu Object (od kterého jsou odvozené všechny ostatní typy objektové typy), v nějakém místě se do ní něco přiřadí (řekněme že program očekává User a „nějak“ se tam dostane DBConnection), co konkrétně tam je prostě nikdo nemůže zjistit, samozřejmě, GC to za běhu ví, a poradí si stím, protože má přehled o té proměnné, ale GC vás před chybným přiřazením neuchrání, ani kompilátor, ani nic jiného. A to byl začátek této diskuze :)

Koukám, že jsem diskutoval spíše o statickém než o silném typování. Oboje pomáhá proti chybám. Že to není 100% prostředek proti nim je snad jasné.

Reagoval jsem na příspěvek pana Augustýna z 11. 8. 2010 22:38 a na Váš z 12. 8. 2010 2:03, které naznačovaly, že snad nějaké takové prostředky existují :)

To jsem naznačit nechtěl, měl jsem namysli pouze snížení pravděpodobnosti chyby, ne odstranění možnosti chyby. Hlavně že si rozumíme.

jen drobnost, nedělejte rovnítko mezi pointer a referenci. Pointer je datový typ obsahující adresu v paměti. Prakticky se jedná o číslo, tohle samozřejmě kompilátor pohlídá, ale nepohlídá, co je na daném místě v paměti. Prakticky se dostáváte do pozice slabě typového jazyka: máte proměnnou, ale nevíte co se za jí prakticky ukrývá (jinak řečeno, víte, že p je pointer, ale co je v p^ nevíte a kompilátor vám to nepoví)

Jo, to vím a myslím, že mezi pointer a referenci jsem zde rovnítko nedával. Nebo ano?

„No, bavíme-li se o vyšších jazycích (jedna z mála podobností Javy a Javascriptu), řekněme s GC, tak tam nejsou pointery, ale reference.“
Pointer je datový typ, který může existovat i v prostření s GC i ve vyšších jazycích. Resp zeptám se jinak, proč se podle vás pointer a reference vylučují? (možná jsem se netrefil, znám několik významů slova reference ve spojení s programovacími jazyky, kompilátory/in­terprety a GC)

Tak, pointer je podle mé představy nástroj, který dává programátorovi maximální volnost a za to od něj vyžaduje maximální odpovědnost. Například v C mohu mít pointer na nějaké místo, k němu přičíst nějaké číslo (automaticky vynásobené příslušným sizeof) a dostat se úplně jinam. GC nemá jak zjistit, že je daný kus paměti používán. Asi by to šlo nějakou dohodou s GC „na toto mi nesahej“, něco takového má AFAIK D, ale zatím jsem se s tím moc nesetkal.
Tedy je asi pravda, že jsem se dopustil určité nepřesnosti, na druhou stranu, podstatná část „Striktní a statické typování pomáhají statické kontrole, nejlepší je na to oboje dohromady.“ tu zůstává.

tak tady 2× souhlas :) GC ví o pointru, ale neví, co tam na programátora čeká :)
a ano, statické a striktní typování pomáhá, hodně pomáhá :). Proto se i ECMAScriptu snažím dodržovat některá základní pravila: všechny proměnné jsou deklarované na začátku bloku platnosti a mají přiřazenou výchozí hodnotu (aby bylo poznat, k čemu jsou, výjimkou jsou proměnné jako i, j, k, l… které používám pouze jako iterátory [for cyklus] a nikdy jinak), žádnou proměnnou nerecykluji, je-li použita jednou jako to string, musí to být string po celou dobu platosti :))

Ano, takže přidáme typy parametrů a můžeme dělat type inference jako ve Scale, Mirah a Groovy++. Mimochodem, váš přístup je dobrý i pro výkon. Mám pocit, že mnohé dnešní implementace JS používají type inference jako implementační detail, takže k function(a, b){return a+b;} mohou časem za běhu vzniknout varianty jako function(String a, String b){return a+b;}, function(int a, int b){return a+b;} apod., které jsou vevnitř staticky typované a lépe optimalizované.

Tak ano, pokud je parser/interpret výkonný a nezaznamená například v daném kontextu eval() popřípadě new Function() (kterým se vyhýbám jako čert kříži), může interně při interpretaci vytvořit staticky typované reprezentace.
Nějaká forma pro začátek alespoň type hintingu by pomohla, ale změnit najedou ECMAScript na silně a/nebo staticky typovaný jazyk by byla dost výrazná změna jazyka.

je možné vložit webWorker do webWorkeru?

Pokud ne přímo, pak by to teoreticky mělo jít tak, že mu to umožní obklopující stránka.

Jak „přímo vložit“? Přímo vložit nelze – co WebWorker, to vlastní soubor. Ale je možné, že se tazatel špatně vyjádřil, a chtěl se zeptat na vyvolávání workeru z workerů – to by mělo bez problémů jít – v hlavním vláknu zavolat jako workera work1.js, a ten si zavolá workera work2.js… :)

To „vložení“ jsem pochopil jako ono „volání“. Poznamenal jsem, že i kdyby to nebyl přímo podporováno, tak by to šlo obejít.

Pochopil jsem to stejně, jen jsem to možná poslal jako odpověď k jiné otázce. Pokud ano, omlouvám se.

Bylo to myleno jako volání workeru z workeru

Tak to by mělo jít, ale raději vyzkoušejte…