Od asm.js k WebAssembly (diskuse)

[Radek Miček]

Jaký je potenciál nahradit CLR a JVM?

[little.owl]

Rekl bych, ze v nekterych oblastech celkem znacny. Zavisi na cem se Google a Microsoft dohodnou. Vzhledem k tomu, ze se dohodly treba ohledne typescriptu, nevidel bych nejakou dohodu nerealne. Evidentne jim ten nestabilni bordel ve web domene zacina vadit.

[deda.jabko]

Myslim, ze to jsou dva paralelni svety, ktere se tak nejak mijeji. Sice chapu pohnutky pro tento krok, ale prijde mi ponekud uchylne, preoperovavat prohlizec na behove prostredi misto pouziti behoveho prostredi navrzeneho od zakladu po strechu.

[pavlix]

Trochu pozdě v době, kdy většina používá prohlížeč z velké části jako běhové prostředí.

[R]

Ano, je to podobne uchylne ako postupne znasilnovanie HTML do toho, co je z neho dnes...

[Ondra]

a to vsechno jenom proto, ze nikdo nechtel delat setup pro nativ aplikace. Bohuzel je to tak proste, ostatne jako vse na tomto svete.

[little.owl]

No ale hlavne byl predevcirem prijat novy standard javascriptu (ECMAScript 6), ktery cini ten jazyk vice snesitelny.

[Radek Miček]

Od WAsm si slibuji hlavně to, že by mohlo dojít k oslabení pozice ECMAScriptu.

[little.owl]

O tom pochybuji, spise naopak.

[Radek Miček]

Pokud používáte staticky typovaný jazyk, tak kód budete moci psát v něm, přeložit do WAsm a ono to poběží rychleji, než kdybyste to napsal přímo v ECMAScriptu. Kdo by pak používal ECMAScript?

[little.owl]

Pokud zarizeni nepodporuje WebAssembly - bude jich jeste dlouho plno, je Javascript fallback a nikdo to nebude psat dvakrat. Javacript dela skutecne velky progress, ECMAScript 7 je uz na ceste a bude asi podporovat i static typing (guards a trademarks). Spise to vypada, ze oni ten jazyk opravi. JavaScript ma obrovky pool programatoru, podporu vsech hlavnich hracu a to i na desktopu, takze oslabeni je iluze.

[Radek Miček]

podporovat i static typing (guards a trademarks)

Koukal jsem na to a není mi jasné, jak budou fungovat parametrizované typy (například generika)?

Spise to vypada, ze oni ten jazyk opravi.

Moc tomu nevěřím – nebude vůle udělat změny, které poruší zpětnou kompatibilitu. Spíš to dopadne tak, že k těm starým a špatným věcem přidají paralelně nové a lepší věci. V praxi se pak bude používat oboje a jazyk bude velice komplikovaný (na to, co umí, je komplikovaný už nyní).

Například do ES 6 přidali generátory, což je IMO krok špatným směrem, uvažuje se o přidání async a await, což je IMO další krok špatným směrem. Pak třeba zjistí, že oboje vede na duplikaci kódu (viz příklad s IEnumerable z mého zápisku Algebraické efekty), a přidají vymezené kontinuace, které subsumují generátory i async a await.

[Bystroushaak]

Například do ES 6 přidali generátory, což je IMO krok špatným směrem, uvažuje se o přidání async a await, což je IMO další krok špatným směrem.

Proč? Ten blog jsem více/méně četl, ale stejně mi to z toho není jasné.

[Radek Miček]

První způsob generování prvků: Obyčejná funkce, která pro každý prvek zavolá předanou funkci (např. jako Array.prototype.forEach).

Druhý způsob generování prvků: Generátor – vrací objekt iterátor, jehož metodu next můžeme volat, když chceme další prvek.

Výhodou prvního způsobu je, že takové funkci je snadné programovat. Jeho nevýhodou je, že cizí funcke řídí náš kód (inversion of control) – v některých případech může být těžké takovou funkci použít.

Naopak výhodou druhého způsobu je snadnost použití generátorů, jeho nevýhodou je, že se generátory těžko programují.

Aby ECMAScript odstranil nevýhodu druhého způsobu, přidal speciální podporu pro generátory. Tato podpora umožňuje psát generátory jako funkce z prvního způsobu – hlavní rozdíl je, že místo volání předané funkce voláme yield a funkce je deklarována pomocí function*.

Tato speciální podpora však neřeší nevýhodu prvního způsobu. Pokud máte například API, kde je pouze map, tak vám podpora generátorů nepomůže – musíte počkat, až autor API přidá generátor.

Existuje však jiné řešení, které žádné generátory nepotřebuje a odstraní obě nevýhody. Tím řešením je převést první způsob na druhý. Je mj. snadné převést druhý způsob generování na první způsob. Převod naopak lze uskutečnit pomocí vymezených kontinuací nebo pomocí vlákna, mutexu a proměnné sdílené vlákny. Pokud ECMAScript bude podporovat green thready, nepotřebuje generátory.

To, co mi tedy vadí na generátorech je, že řeší problém jen napůl (neodstraňují nevýhodu prvního způsobu generování), komplikují jazyk a možná budou zbytečné, protože stejnou službu udělají green thready.

Kromě toho jsou tu otázky ohledně časové složitosti – jakou bude mít například ES analog následujích enumerátorů časovou složitost? Lineární nebo kvadratickou?

        static IEnumerable<int> LeftAssocEnum(int i)
        {
            var acc = Enumerable.Empty<int>();
            while (i > 0)
            {
                acc = Enumerable.Concat(acc, new int[] { i });
                i--;
            }
            return acc;
        }

        static IEnumerable<int> RightAssocEnum(int i)
        {
            var acc = Enumerable.Empty<int>();
            while (i > 0)
            {
                acc = Enumerable.Concat(new int[] { i }, acc);
                i--;
            }
            return acc;
        }

Mj. v C# mají oba enumerátory kvadratickou složitost a oba z nich způsobí přetečení zásobníku pro dostatečně velké i. Nicméně v rozumné implementaci by RightAssocEnum měl mít lineární časovou složitost a k žádnému přetečení zásobníku by u něj dojít nemělo.

[Bystroushaak]

Proč by bylo lepší mít green thready, než generátory?

[Radek Miček]

V green threadu si můžete uložit zásobník pro libovolný výpočet – stačí, když ten výpočet zavolá vaši funkci (díky tomu převedete první způsob generování prvků na druhý způsob). Generátor (v ES) vám rovněž umožní uložit zásobník, ale jen pro funkce označené function*, navíc se takto označené funkce chovají jinak než klasické funkce označené function. Green thready jsou tedy obecnější.

Když mám green thready, nemusím dopředu rozhodovat, zda nějaká funkce bude generátor – například map mohu, jak jsem zmínil, použít jako generátor (bez toho abych něco přepisoval) – tj. vytvořím funkci, která vrací iterátor a tento iterátor uvnitř používá map.

[little.owl]

Mam pocit, ze michate design jazyka s implementacnimi detaily. Green thread je implementacni vec, ktera ma sve limity a uskali, a kterou se standardem kompatibilni implementace nemusi pouzivat, zatimco generator je neco, co mate. Stejne tak preteceni zasobniku - implementace muze pouzivat segmented stack a tim se presune problem s alokaci do heapu.

[Radek Miček]

Jen říkám, že to, co dělají generátory, můžete udělat pomocí green threadů nebo vymezených kontinuací a navíc bez toho, abyste měnil samotné funkce, tj. lze to použít pro všechny existující funkce a nemusíte je přepisovat pomocí function*.

Stejne tak preteceni zasobniku - implementace muze pouzivat segmented stack a tim se presune problem s alokaci do heapu.

Oboje lze implementovat s konstantním zásobníkem a s lineární časovou složitostí. Je jen otázkou, jak chytrá je implementace. Příkladem takové implementace je knihovna scalaz-stream.

[little.owl]

Navic poznamka s komplexitou je usmevna - novy standard programovani vyrazne zjednodusuje.

[Radek Miček]

novy standard programovani vyrazne zjednodusuje

Možná zjednodušuje programování, nicméně pochybuji, že zjednodušuje jazyk. Například verze 5 specifikuje jazyk na 100 stranách, verze 6 na 260 stranách.

[little.owl]

Mozna koukate na jiny standard, ale verze 5.1 ma 258 stran, a verze 6.0 ma 566 stran. To ale neni podstatne. Snad zadny jazyk v prubehu sve evoluce neubira stranky standardu, pokud chce zachovat urcitou zpetnou kompatibilitu. V pripade ES6 jde velka cast pridanych stranek na vrub upresneni stavajiciho standardu, kdy se nechava mene volnosti implementacim, coz zjednodusi prenositelnost a popisu standardni knihovny. Zmeny ve vlastnim jazyku jsou jednoznacne pozitivni a cela rada starsich technik je v podstate v "deprecated modu", kdy v dalsich revizich muze byt vyjmuta.

[Radek Miček]

Mozna koukate na jiny standard, ale verze 5.1 ma 258 stran, a verze 6.0 ma 566 stran.

Bral jsem jazyk bez standardní knihovny – přijde mi to lepší pro odhad složitosti jazyka – a také jsem se spletl, v případě ES 6 to je více stran. Například oproti specifikaci Standard ML, která má pod 100 stran, je to celkem výrazný rozdíl.

v dalsich revizich muze byt vyjmuta.

Jen dobře, pokud bude.

[little.owl]

Například oproti specifikaci Standard ML, která má pod 100 stran, je to celkem výrazný rozdíl.

To je nesmysl srovnavat podle stran, nebot se nejedna o dokumenty vytvorene pro jednu standardizacni instituci podle stejnych pozadavku. Lepsi priklad by byl treba Dart.

[little.owl]

Koukal jsem na to a není mi jasné, jak budou fungovat parametrizované typy (například generika)?

Pouzijete guards, ktere zajisti, ze v danem bloku kodu se pouziva pouze deklarovany trademark (typ). Kompilatoru pak zoptimalizuje genericky blok kodu pro dane typy. Stale je to otevrene, ale staticke typy v nejake forme budou.

a jazyk bude velice komplikovaný

Horsi nez C++ ci rust to nebude.

Například do ES 6 přidali generátory, což je IMO krok špatným směrem, uvažuje se o přidání async a await, což je IMO další krok špatným směrem.

Vsechno to ma byt postavene nad spawn, ktery ma bezet na green threads, takze blokovani neni az tak velky problem.

[deda.jabko]

Pokud zarizeni nepodporuje WebAssembly - bude jich jeste dlouho plno, je Javascript fallback a nikdo to nebude psat dvakrat.

Jako fallback muze byt interpretace WebAssembly pomoci JS. Nebo JIT preklad WebAssmebly do JS, ktery pak bude prolozeny JIT do nativniho kodu. ;-]

Spise to vypada, ze oni ten jazyk opravi.

IMHO je JS FUBAR. Jak uz psal Radek Micek, ten jazyk obsahuje spoustu spatnych vlastnosti od zacatku a nikdo nebude mit odvahu rozbit zpetnou kompatibilitu... uz jenom kvuli tomu velkemu mnozstvi programatoru. Leda, ze by zavedli nejakou direktivitu (ala Perl), ktera by rikala, ze kod je napsany pro konkretni verzi JS.

[unicode]

"use more strict"

[little.owl]

WebAssembly je jen zkompreseny AST, neni to neco jako JVM ci CLR.

IMHO je JS FUBAR.

To jsem si myslel take, a kdyby se mi zdalo o programovani v javascriptu, musel bych memit pyzamo, jak bych byl zpoceny hruzou. Rozdil oproti jinym jazykum je v tom, ze JavaScript se zatim pouziva v prostredi, kde zivotnost aplikaci beze zmen je v radu mesicu, zivotnost zarizeni v radu let, a prohlizec se updatuje kazdy mesic. To jim umoznuje delat i zpetne nekompatibilni zmeny, kde se kompatibilita docasne vyresi, jak bylo naznaceno vyse, pridanim dalsi direktivy.

[Bystroushaak]

Pokud zarizeni nepodporuje WebAssembly - bude jich jeste dlouho plno, je Javascript fallback a nikdo to nebude psat dvakrat.

Dneska je v módě psát překladače do javascriptu.

[kralyk z abclinuxu]

Pokud používáte staticky typovaný jazyk, tak kód budete moci psát v něm, přeložit do WAsm a ono to poběží rychleji, než kdybyste to napsal přímo v ECMAScriptu. Kdo by pak používal ECMAScript?

Určitě se počítá s tím, že JS se bude do WebAsm taky překládat.

Jinak JS mi přijde jako celkem dobrý jazyk. Má svoje mouchy, ale určitě to není špatný jazyk ve smyslu skutečně špatných jazyků, jako třeba PHP...

[xm]

JavaScript má sice některé dobré koncepty (třeba celý prototype-based programming je úžasný), ale celkově je to příšerný jazyk kvůli obrovské hromadě různých "quirks". Jako člověk který programuje primárně v Pythonu vždy když něco musím psát v JavaScriptu u toho bytostně trpím

Jinak doporučuji tento článek: Why Does JavaScript Suck?

[xm]

Btw. je to tu teď sice OT, ale článek Why Does PHP Suck? od stejného autora také stojí za přečtení, člověk občas neví zda se smát nebo brečet (v PHP jsem léta programoval)

[Bystroushaak]

Tohle taky: PHP: a fractal of bad design

[mirec]

V čom sú prototypy dobré? Neberte to ako hate príspevok, len ma to zaujíma. V js istý čas robím, čítal som mnoho blogov ako v tom napr. napísať dedičnosť a stále neviem ako na to.

[kralyk z abclinuxu]

Jinak doporučuji tento článek: Why Does JavaScript Suck?

Mně právě tyhle quirks vůbec nepřijdou tak hrozné. Když píšu v JS, používám kontrolu typů, operátor === a podobně. Souhlasim s tim automatickým středníkem, to mě taky onehdá vytočilo. Ten scoping nevidim jako problém - stejně je to jazyk s GC. Ten odstavec o globálních proměnných mi přijde přehnaný, nevim o tom, že bych musel používat globální proměnný vyjma window. Jako jo, v JS určitě jsou nepříjemnosti, ale ten jazyk alespoň celkově nějak dává smysl a má nějakou koncepci narozdíl od PHP.

[R]

Takze namiesto (obfuskovaneho) javascriptu to bude blob...

[Radek Miček]

Ne nutně, viz Text Format.

[deda.jabko]

Jojo, to by mohlo byt nadejne. Uz ted vznikaji ruzne prekladace pres LLVM do JS, takze by se to mohlo uchytit. A treba by to pomohlo i jazykum typu Dart, kdy jsou prakticky podporovany jen posledni verze prohlizecu, coz jej dela prakticky nepouzitelnym.

[Bystroushaak]

Uz ted vznikaji ruzne prekladace pres LLVM do JS

To je hrozně pomalé a výsledná velikost je většinou taky dost špatná. O dost použitelnější jsou překladače přímo do JS, jako třeba brython.

[tacoberu]

Tohle je hezký!

[Bystroushaak]

Psal jsem o tom i blogpost, ale už je brutálně zastaralý.

[finc]

Cetl jsem, ze narust vykonu oproti plain-textu (js souboru) je az 23x nasobny.

Navic sami se obhajuji tim, ze se NEMA jednat o nahrazeni javascriptu, ale spise o jeho doplneni. Tedy pro jednoduche ukoly zustane js, pro sofistikovanejsi veci vyuziti WA.

To, ze se tyto firmy vubec dohodli je ukazka toho, ze jim skutecne vadi soucasna situace. Google i Microsoft se jiz snazili uvest svuj vlastni zpusob, ale diky ignoraci ostatnich hracu se opet vratili na stromy.

Je treba si uvedomit, ze soucasny web development se pomalu ale jiste zene smerem: pure js app s rest backendem, takze proc se nepokusit i ten blaznivy js nahradit? Navic by to byl dalsi argument pro firmy, ktere odmitaji Angular ci React a to jen z toho duvodu, ze tvrdi, ze cast aplikacni logiky maji v citelne podobe na klientske strane.