Zkušenosti s TypeScriptem

[Cikáda]

No a třeba Céčko je založené na transpilaci kódu do strojáku. Je to taky zhovadilost?

psal jsem o JS, ne o céčku ;-)

No právě. Kompilace se používá naprosto běžně, tak jsem chtěl vysvětlení, proč je v tomto jednom případě fuj a v jiných OK.

Asi kvůli výstupu.

Naopak jsem měl možnost pracovat na dvou projektech v TS, které psali rusáci a indové. Větší hnusy jsem snad neviděl. Z 95% všude bylo any nebo tsignore.

Pak ty projekty nebyly z 95% v TS, ale v čistém JS, který tak velebíte

To by asi spadlo na SyntaxError. 

K tomu mě napadá opět jeden klasický citát, kterým se s vámi rozloučim:

Neexistuje programovací jazyk, ve kterém by se nedal napsat špatný program.

Tak to je vskutku objev.

[Reklama]

[kotelgg]

Zajímalo by mě, kde se reálně využije dynamičnost kódu? Z integer je kdesi v kódu najednou string a na základě toho se program větví jinak nebo co? Mě neskutečně irituje, že jsem některé projekty v php nepředělal na striktní typy, protože se pak všude musí dělat harakiry, aby se mi int porovnával opravdu jako int. Na chybu se pak přijde třeba za rok nebo vůbec.

[Zabanovaný Anonymní Troll]

Zajímalo by mě, kde se reálně využije dynamičnost kódu? Z integer je kdesi v kódu najednou string a na základě toho se program větví jinak nebo co? Mě neskutečně irituje, že jsem některé projekty v php nepředělal na striktní typy, protože se pak všude musí dělat harakiry, aby se mi int porovnával opravdu jako int. Na chybu se pak přijde třeba za rok nebo vůbec.

U malych projektu typy nepotrebujes. U vetsich projektu tez ne:

Step 1. To rychle nadevelopis
Step 2. Pak das rychle vypoved, jako vymluvu uvedes ze jsou moc pozadu technologicky
Step 3. A v nove praci si das bacha abys taky jen developil.
Step 4. Na Root.cz nasledne prohlasujes ze skriptovaci jazyky jsou the best.
Step 4. Repeat.

[Ink]

Zajímalo by mě, kde se reálně využije dynamičnost kódu? Z integer je kdesi v kódu najednou string a na základě toho se program větví jinak nebo co? Mě neskutečně irituje, že jsem některé projekty v php nepředělal na striktní typy, protože se pak všude musí dělat harakiry, aby se mi int porovnával opravdu jako int. Na chybu se pak přijde třeba za rok nebo vůbec.

Je to vývoj. V době, kdy psát typy byl neskutečný opruz, byly jazyky jako Python živá voda. Pak se v mainstreamu objevila typová inference a dobré vlastnosti z Pythonu a dalších jazyků a naopak Python umožňuje typy psát a kontrolovat pomocí statické analýzy. Na druhou stranu si nedělejme iluze, že kontrola v době kompilace nebo nějaký linter objeví všechny chyby a některé nebudou na vhodnou chvíli čekat i ten rok.

V dynamických jazycích lze psát poměrně robustní kód i bez typových anotací, ale je to náročnější na code review a chce to cvik. Ty anotace se budou určitě ve větších projektech používat víc a víc.

[BoneFlute]

Samozřejmě. Znamenalo by to, že si pouze myslíte, že jste odstranil 100 % (všimněte si mezery za číslem) chyb, ale ve skutečnosti vám jich tam ještě 50 % (opět si všimněte mezery za číslem) zůstalo.

V tom případě 50% nalezených chyb v době kompilace je super, a beru to.

Výborně. Tak teď, když už víme, že nám typová kontrola (zdaleka) nepochytá všechny chyby, je na čase zvážit, zda se nám vyplatí ji na chytání chyb zavádět a zvyšovat tím složitost kódu a snižovat jeho dynamičnost a obecnost.
Neřešte to znovu, už se to tu řešilo, a zjistilo se, že každý soudruh to má jinak. Věnujte se místo toho raději pravopisu, ten by naopak měl mít každý soudruh stejný (= dle pravidel).

Nutno ale podotknout, že v dnešní době chytrých jazyků s typovou inferencí už typová kontrola přináší jen benefity (žádné zvyšování složitosti kódu ani snižování dynamičnosti či obecnosti se již nekoná).

To je pravda, ale s tou výhradou, že plně automatickou inferenci udělat nelze.

Nestalo se mi, že by mě obtěžovalo napsání Typové signatury. Zato se mi bolestně běžně stává, že mi absence typů schází. Čímž se kruhem dostáváme k tomu, že někdy to fakt záleží na preferencích. Pro někoho napsání těch několika málo typů může být stopka.

[Reklama]

[BoneFlute]

To je pravda, ale s tou výhradou, že plně automatickou inferenci udělat nelze.

Ještě takové drobné pošťouchnutí. Pokud bychom to vzaly trochu obecněji, tak plně automatická inference existuje, a používá se například u Javascriptu (pravděpodobně nejen). Ten vezme ten kód, celej se přeloží do nějaké té interní reprezentace, všechny typy se zahodí, a podle logiky toho kódu se vymyslí nové.

[BoneFlute]

Zajímalo by mě, kde se reálně využije dynamičnost kódu? Z integer je kdesi v kódu najednou string a na základě toho se program větví jinak nebo co? Mě neskutečně irituje, že jsem některé projekty v php nepředělal na striktní typy, protože se pak všude musí dělat harakiry, aby se mi int porovnával opravdu jako int. Na chybu se pak přijde třeba za rok nebo vůbec.

Je to vývoj. V době, kdy psát typy byl neskutečný opruz, byly jazyky jako Python živá voda. Pak se v mainstreamu objevila typová inference a dobré vlastnosti z Pythonu a dalších jazyků a naopak Python umožňuje typy psát a kontrolovat pomocí statické analýzy. Na druhou stranu si nedělejme iluze, že kontrola v době kompilace nebo nějaký linter objeví všechny chyby a některé nebudou na vhodnou chvíli čekat i ten rok.

V dynamických jazycích lze psát poměrně robustní kód i bez typových anotací, ale je to náročnější na code review a chce to cvik. Ty anotace se budou určitě ve větších projektech používat víc a víc.

Dále, napsat jazyk bez statických typů je mnohem jednodužší (krásný příklad budiž Lua, kde díky tomu, že typy hodili na bedra uživatelů, tak mohli zkrouhnout jazyk a engine do fantasticky malé libky). Kvalitní typy jsou další svět sám pro sebe, a aby to bylo užitečné,  tak tomu dotyční, kteří jazyk vymejšlejí musí rozumět. Což není samozřejmé, a navíc se to historicky taky vyvíjí.

[Idris]

plně automatická inference existuje, a používá se například u Javascriptu (pravděpodobně nejen). Ten vezme ten kód, celej se přeloží do nějaké té interní reprezentace, všechny typy se zahodí, a podle logiky toho kódu se vymyslí nové.

V tom žádná inference není.

[Idris]

To je pravda, ale s tou výhradou, že plně automatickou inferenci udělat nelze.

Ještě takové drobné pošťouchnutí. Pokud bychom to vzaly trochu obecněji, tak plně automatická inference existuje, a používá se například u Javascriptu (pravděpodobně nejen). Ten vezme ten kód, celej se přeloží do nějaké té interní reprezentace, všechny typy se zahodí, a podle logiky toho kódu se vymyslí nové.

Jinak ten problém s kovariantním polem hezky ukazuje, kde se dynamický runtime hodí. Typová kontrola v tomto případě ověří přiřazení a za běhu program nepadne. Je to vykoupeno nevýhodami jinde, ale jako příklad hezké.

[BoneFlute]

plně automatická inference existuje, a používá se například u Javascriptu (pravděpodobně nejen). Ten vezme ten kód, celej se přeloží do nějaké té interní reprezentace, všechny typy se zahodí, a podle logiky toho kódu se vymyslí nové.

V tom žádná inference není.

Samozřejmě. Protože všechno je plně automatické :-)

Jinak ten problém s kovariantním polem hezky ukazuje, kde se dynamický runtime hodí. Typová kontrola v tomto případě ověří přiřazení a za běhu program nepadne. Je to vykoupeno nevýhodami jinde, ale jako příklad hezké.

V tomto se neshodnem. Respektive se mi zdá, že si každý pod pojmem dynamický/statický představujeme něco jiného.

Co jsou zač ty nevýhody?

[Idris]

Co jsou zač ty nevýhody?

Dynamický dispatch je pomalejší.

[BoneFlute]

Co jsou zač ty nevýhody?

Dynamický dispatch je pomalejší.

Ech. Něco jiného než rychlost?

[Idris]

Co jsou zač ty nevýhody?

Dynamický dispatch je pomalejší.

Ech. Něco jiného než rychlost?

Ne.

[qelurg]

Nestalo se mi, že by mě obtěžovalo napsání Typové signatury. Zato se mi bolestně běžně stává, že mi absence typů schází. Čímž se kruhem dostáváme k tomu, že někdy to fakt záleží na preferencích. Pro někoho napsání těch několika málo typů může být stopka.

Nechápeš to. Nejde jen o to, že musíš napsat anotaci, ale že tě statické typy hrubě omezují v návrhu programu. Je to neflexibilní, a jakákoliv snaha dostat do návrhu flexibilitu je těžkopádná  a zkostnatělá.  A nechápeš to proto, že prostě neumíš myslet v dynamicky typovaném jazyku, neumíš myslet dynamicky. Proto ti v něm chybí statické typy, bez nich neumíš dobře programovat a naopak neumíš využít výhod jazyku dynamického.

[qelurg]

Výborně. Tak teď, když už víme, že nám typová kontrola (zdaleka) nepochytá všechny chyby, je na čase zvážit, zda se nám vyplatí ji na chytání chyb zavádět a zvyšovat tím složitost kódu a snižovat jeho dynamičnost a obecnost.
Neřešte to znovu, už se to tu řešilo, a zjistilo se, že každý soudruh to má jinak. Věnujte se místo toho raději pravopisu, ten by naopak měl mít každý soudruh stejný (= dle pravidel).

Ještě je nutno zmínit, že omezující typový systém je sám o sobě zdrojem zbytečných chyb.

Ano, omezeny typovy system zpusobuje zbytecne chyby. Kvalitni typovy system pomaha chybam predchazet.

Kazdy typovy system je omezeny, omezovat ma primo v popisu prace. Typovy system sam o sobe je zdrojem chyb. Predchazet chybam se da ruze, treba neprogramovanim. To ze neco predchazi chybam jeste nutne neznamena ze to je dobre a uzitecne.