Problémy s JavaScript v praxi

[Cikáda]

Funny je, že musí přijít @Kit a mluvit k tématu. Zase se po nějaké době shodneme.

[Reklama]

[BoneFlute]

Možná to díky citacím vypadlo z kontextu, ale "uvnitř" je tu použito ve smyslu "uvnitř proměnné". Nevím, co je zlého na tomto:

Kód: [Vybrat]

let x = 100;
let y = "ahoj";
typeof x;
typeof y;

A v jakém smyslu se to liší od tohoto?

Kód: [Vybrat]

if (ptr == NULL)

Z jakého důvodu by to ze mě mělo dělat špatného programátora?

Tak takhle je to v pořádku. Zdá se, že jsem tě špatně pochopil. Omlouvám se.

Narážel jsem na tohle:

Kód: [Vybrat]

def format(a, b):
    return a + b

format(1, 2)
Špatný název protože "tak se kouknu dovnitř, co to dělá, že jo".

[BoneFlute]

Funny je, že musí přijít @Kit a mluvit k tématu. Zase se po nějaké době shodneme.

Kit a k tématu? Ano, to je Funny.

[Cikáda]

Narážel jsem na tohle:

Kód: [Vybrat]

def format(a, b):
    return a + b

format(1, 2)
Špatný název protože "tak se kouknu dovnitř, co to dělá, že jo".

Ne, to by bylo fakt nepěkné.

Funny je, že musí přijít @Kit a mluvit k tématu. Zase se po nějaké době shodneme.

Kit a k tématu? Ano, to je Funny.

Možná, ale často tu měl teď point.

[eee]

Třeba v tom, že to je 1) nepodstatné a 2) bezpředmětné. Ad 1) Hlavní rozdíl mezi statickým a dynamickým je v tom, že statické typy se kontrolují už při překladu. Ad 2) javascriptu není vyčítáno to, že nemá statické typy, ale jeho hloupé chování v řadě případů.

Takže když do staticky typovaného jazyka narveš nevalidní data, tak nespadne?

Kde jsi takovou blbost vyčetl?

To není blbost, ale řečnická otázka. Při překladu nevalidní vstupní data nezkontroluješ, musíš je zkontrolovat až za běhu.

Ptáš se způsobem, jakobych takovou blbost napsal já. Při překladu se kontroluje práce s typy, nikoliv validita vstupních data. To porovnáváš hrušky a jabka.

Vstupní data přece také musí být nějakého typu.

To je a) marginalni, pri validaci dat kontrolujes predevsim hodnoty, b) vstupni data jsou vetsinou text, ktery po jejích valádaci teprve prevadis na prislusne datove typy.

[Reklama]

[eee]

Jinak je ti doufám jasné, že i v JavaScriptu taky můžeš hlídat, jestli jsi dostal číslo, nebo string

Jen za běhu. Fakt budeš "kopat" základy lžičkou, když můžeš použít bagr?

Jistě, v interpretovaných jazycích se tak nějak věci za běhu kontrolují...

Interpretovanost nijak nesouvisí s typováním.

Ano, dobrý point - chtěl jsem napsat dynamických (~dynamicky typovaných). Moje chyba.

Pak to ale není argument. 1. “Java umí kontrolovat typy na vstupu při překladu - před během.” 2. “V JS taky jdou kontrolovat typy na vstupu.”

Zaprvé se koukni na to, jak šly "argumenty" po sobě. Zadruhé Java je dynamicky typovaná?

Jednak si můžeš zjistit, co uvnitř je, ...

Tohle by slušný programátor nemohl ani vyslovit!

Pročpak? A co je to "slušný programátor".

Pokud by mi těžce šlo o to, aby oba parametry byly Stringy, tak si to prostě ověřím a případně vyhodím výjimku (když už na tom tak trváte). V C si taky ověřuji, jestli pointer není NULL.

Však C je také slabě typovaný jazyk. Prpblém v JS, že samotné ověřování typů není dostatečné, protože JS s nimi pracuje špatně, viz řada už uvedených příkladů:

'aa' == 'aa'
'aa' == new String('aa')
new String('aa') == new String('aa')
{} == {}

Problém je, že tvrdíš, že ověřování typů není dostatečné, ale jako příklad uvádíš něco, co typ neověřuje...

To jsi to zase nepochopil. Takže srozumitelněji, problém v js je, že ani ruční ověřování typů není dostatečné, protože JS s těmi datovými typy stejně pracuje špatně. Prostě problém JS jení v slabém typování, ale v tom, že ho má špatně implementované, je nekonzistentní a s datovými typy zachází nesmyslně.

[Kit]

Vstupní data přece také musí být nějakého typu.

To je a) marginalni, pri validaci dat kontrolujes predevsim hodnoty, b) vstupni data jsou vetsinou text, ktery po jejích valádaci teprve prevadis na prislusne datove typy.

Jenže to už neuděláš při kompilaci, ale až za běhu. Teprve za běhu zjistíš, je je v nich chyba. Tohle ti statické typování neodchytí. No a pak je otázkou, zda tyto chyby odchytávat před voláním funkce, v dekorátoru nebo až ve funkci.

Myslím si, že marginální to není. Programátoři tohle řeší dnes a denně.

[Kit]

To jsi to zase nepochopil. Takže srozumitelněji, problém v js je, že ani ruční ověřování typů není dostatečné, protože JS s těmi datovými typy stejně pracuje špatně. Prostě problém JS jení v slabém typování, ale v tom, že ho má špatně implementované, je nekonzistentní a s datovými typy zachází nesmyslně.

Problém Javascriptu je hlavně v tom, že sis nepřečetl manuál.

[eee]

Vstupní data přece také musí být nějakého typu.

To je a) marginalni, pri validaci dat kontrolujes predevsim hodnoty, b) vstupni data jsou vetsinou text, ktery po jejích valádaci teprve prevadis na prislusne datove typy.

Jenže to už neuděláš při kompilaci, ale až za běhu. Teprve za běhu zjistíš, je je v nich chyba. Tohle ti statické typování neodchytí. No a pak je otázkou, zda tyto chyby odchytávat před voláním funkce, v dekorátoru nebo až ve funkci.

Myslím si, že marginální to není. Programátoři tohle řeší dnes a denně.

Co jsi nepochopil na vyjádření: Při překladu se kontroluje práce s typy, nikoliv validita vstupních data. To porovnáváš hrušky a jabka.

[eee]

To jsi to zase nepochopil. Takže srozumitelněji, problém v js je, že ani ruční ověřování typů není dostatečné, protože JS s těmi datovými typy stejně pracuje špatně. Prostě problém JS jení v slabém typování, ale v tom, že ho má špatně implementované, je nekonzistentní a s datovými typy zachází nesmyslně.

Problém Javascriptu je hlavně v tom, že sis nepřečetl manuál.

Za prvé to nevíš, za druhé lžeš a za třetí problémy JS jsou nezávislé na mě a na tom, co já si přečtu nebo ne.

[asd]

Tady se přidám ke Kitovi - fakt si ten manuál přečti.

V JS operátor == nemá význam "porovnej 'a' a 'b' podle obsahu", ale "porovnej 'a' a 'b' a v případě potřeby je přetypuj". V tom je jádro problému.

'aa' == new String('aa')

Tady porovnáváš hodnotu s objektem. No a objekt není hodnota. Je to sice nešťastné, ale je to tak právě proto, že to je konzistentní se zbytkem. Samozřejmě by to mohlo být lepší, ale na webu má zpětná kompatibilita takovou prioritu, takže třeba změny chování operátoru pro porovnání nepřipadají moc v úvahu. Pokud se s tím někdo smířit nedokáže, tak má na výběr ze stovek transpilovaných jazyků. Každopádně vytvářet řetězce pomocí new String jsem snad ani nikde neviděl, nikdo to nepoužívá.

new String('aa') == new String('aa')
{} == {}

Tady zase porovnáváš objekt s objektem. No a shodné objekty to nejsou. Tzn. je to konzistentní.

[asd]

Omlouvám se, v prvním jsem přehlídl, že to není ===. Význam je ale pořád stejný.

[BoneFlute]

new String('aa') == new String('aa')
{} == {}

Tady zase porovnáváš objekt s objektem. No a shodné objekty to nejsou. Tzn. je to konzistentní.

Tady někde je tuším ta hranice, kdy se přepíná mezi porovnávání hodnoty, a porovnávání identity. Což je další matení nepřítele, že si se dvěma oparátory (== a ===) vlastně furt nevystačíš.

[Cikáda]

new String('aa') == new String('aa')
{} == {}

Tady zase porovnáváš objekt s objektem. No a shodné objekty to nejsou. Tzn. je to konzistentní.

Tady někde je tuším ta hranice, kdy se přepíná mezi porovnávání hodnoty, a porovnávání identity. Což je další matení nepřítele, že si se dvěma oparátory (== a ===) vlastně furt nevystačíš.

Ne, to bych neřekl. Ono totiž není úplně snadné říct, kdy jsou si objekty rovny...

[BoneFlute]

new String('aa') == new String('aa')
{} == {}

Tady zase porovnáváš objekt s objektem. No a shodné objekty to nejsou. Tzn. je to konzistentní.

Tady někde je tuším ta hranice, kdy se přepíná mezi porovnávání hodnoty, a porovnávání identity. Což je další matení nepřítele, že si se dvěma oparátory (== a ===) vlastně furt nevystačíš.

Ne, to bych neřekl. Ono totiž není úplně snadné říct, kdy jsou si objekty rovny...

A co by si řekl?

Pokud se nehraje na identitu, tak mi to přijde krásně čisté:

Kód: [Vybrat]

1 == 1
"1" == "1"
{} == {}
{x: 1} == {x: 1}
new String("x") == new String("x")

Má to spoustu pěknejch důsledků. (A taky pár podrazů.)