Problémy s JavaScript v praxi

[eee]

Vy jste hrozne nechapavi. Jako programator vis co mas v kodu, ale netusis a nemuzes tusit, kdo tu funkci pouzije a co ti do ni nacpe.

To je sice nepochopení, ale z tvojí strany. Pokud má funkce přijímat zásadně jen jeden typ, tak si to máš ověřit na vstupu.

Typická knížecí rada. 1) Data se kterými pracuješ ve funkci se do ní nedostávají jen na vstupu 2) tato data nemusí být jen jednoduché hodnoty, ale rozsáhlá pole hodnot či hůř zapouzdřených objektů.

Takže na vstupu si vše neověříš a nebo je to neefektivní, což znamená, že si je musíš ověřovat až při použití a doplnit tak do funkce mraky kontrol pro jistotu, co kdyby někdy někde něco náhodou. V podstatě tedy musíš jako programátor neustále nahrazovat absenci rozumné kontroly ze strany překladače/interpretu, čímž ti vzniká zbytečně rozsáhlý a nepřehledný kód plný kontrol, které přitom mohl dělat na pozadí a spolehlivěji 'jazyk' sám. To samo o sobě má řadu dalších negativních důsledků, třeba při změně programu, kde musíš náledně opravovat desítky až stovky těchto dodatečných kontrol v kvůli spoustě kontrol nepřehledném kódu, kde tyto úpravy dělá zpravidla někdo jiný, než původní autor.

[Reklama]

[eee]

No, mě na tom Javascriptu (a Pythonu do 3.4) vadí jiná věc.
Přeci jen je rozdíl mezi tím, když:
1. kontroluješ před spuštěním
2. kontroluješ za běhu
3. nekontroluješ vůbec, respektive ručně = všichni na to kašlou

Rozdíl mezi statickým a dynamickým typováním je v tom, že u staticky typovaných jazyků musíš data prověřit před vstupem do bloku, ale u dynamicky typovaných tu můžeš udělat v dekorátoru nebo až uvnitř bloku. Kontrolu před spuštěním můžeš udělat u všech.

Tak. Když už to chápe i Kit, tak v čem je tedy problém?

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ů.

[Kit]

No, mě na tom Javascriptu (a Pythonu do 3.4) vadí jiná věc.
Přeci jen je rozdíl mezi tím, když:
1. kontroluješ před spuštěním
2. kontroluješ za běhu
3. nekontroluješ vůbec, respektive ručně = všichni na to kašlou

Rozdíl mezi statickým a dynamickým typováním je v tom, že u staticky typovaných jazyků musíš data prověřit před vstupem do bloku, ale u dynamicky typovaných tu můžeš udělat v dekorátoru nebo až uvnitř bloku. Kontrolu před spuštěním můžeš udělat u všech.

Tak. Když už to chápe i Kit, tak v čem je tedy problém?

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?

[andy]

Takže nezkoušel.

Tak to jsme na tom v podstatě stejně, že.

Napsal jsem toho fakt hodně v pythonu. Což je dynamický jazyk, který se v těchhle podstatných věcech od JS neliší. Takže bych řekl, že na rozdíl od tebe v tomhle zkušenost mám.

Buď kecáš a Python neznáš, nebo nevíš jak je JS špatně navržený. Každopádně tvrzení, že se Python neliší od JS je hodně zcestný. :-)

Přečti si historii diskuze Byl jsem konfrontován s tím, že neznám moderní JS, takže neznám skvělé vlastnosti dynamických jazyků. Tudíž odpověď, že mám léta praxe v pythonu (s tím, že Python > JS) je IMO zcela na místě.

Ale jinak mi to připadá přesně takhle: ideální je kontrolovat všechno při překladu, a když to nejde, tak aspoň něco vynutit za běhu. Automatické přetypování je prostě anti-pattern, který by v jazyce být neměl, bez ohledu na to, jestli je něco kontrolované při překladu nebo ne.

[andy]

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

No, v principu by neměl, protože by to při chroustání těch vstupních dat mělo vyhlásit, že ta data jsou chybná. Což samozřejmě může klidně být uděláno i v dynamickém jazyku, akorát tam se to moc nevynucuje.

Např. ve staticky typovaném jazyku se JSON na vstupu dekóduje do nějaké Class. To je operace, která může selhat (třeba z důvodu chybějících políček, špatných typů apod.) a mělo by se to ošetřit. "Nedekódovat to" je v podstatě práce navíc. V dynamicky typovaném (JS) se udělá JSON.decode a je to. "Zkontrolovat to" je práce navíc.

[Reklama]

[eee]

No, mě na tom Javascriptu (a Pythonu do 3.4) vadí jiná věc.
Přeci jen je rozdíl mezi tím, když:
1. kontroluješ před spuštěním
2. kontroluješ za běhu
3. nekontroluješ vůbec, respektive ručně = všichni na to kašlou

Rozdíl mezi statickým a dynamickým typováním je v tom, že u staticky typovaných jazyků musíš data prověřit před vstupem do bloku, ale u dynamicky typovaných tu můžeš udělat v dekorátoru nebo až uvnitř bloku. Kontrolu před spuštěním můžeš udělat u všech.

Tak. Když už to chápe i Kit, tak v čem je tedy problém?

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?

[eee]

Takže nezkoušel.

Tak to jsme na tom v podstatě stejně, že.

Napsal jsem toho fakt hodně v pythonu. Což je dynamický jazyk, který se v těchhle podstatných věcech od JS neliší. Takže bych řekl, že na rozdíl od tebe v tomhle zkušenost mám.

Buď kecáš a Python neznáš, nebo nevíš jak je JS špatně navržený. Každopádně tvrzení, že se Python neliší od JS je hodně zcestný. :-)

Přečti si historii diskuze Byl jsem konfrontován s tím, že neznám moderní JS, takže neznám skvělé vlastnosti dynamických jazyků. Tudíž odpověď, že mám léta praxe v pythonu (s tím, že Python > JS) je IMO zcela na místě.

Ale jinak mi to připadá přesně takhle: ideální je kontrolovat všechno při překladu, a když to nejde, tak aspoň něco vynutit za běhu. Automatické přetypování je prostě anti-pattern, který by v jazyce být neměl, bez ohledu na to, jestli je něco kontrolované při překladu nebo ne.

Žádná historie diskuse tě neopravňuje k tvrzení, že Python se v podstatných věcech od JS neliší.

[Cikáda]

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.

[Kit]

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

No, v principu by neměl, protože by to při chroustání těch vstupních dat mělo vyhlásit, že ta data jsou chybná. Což samozřejmě může klidně být uděláno i v dynamickém jazyku, akorát tam se to moc nevynucuje.

Např. ve staticky typovaném jazyku se JSON na vstupu dekóduje do nějaké Class. To je operace, která může selhat (třeba z důvodu chybějících políček, špatných typů apod.) a mělo by se to ošetřit. "Nedekódovat to" je v podstatě práce navíc. V dynamicky typovaném (JS) se udělá JSON.decode a je to. "Zkontrolovat to" je práce navíc.

Takže když má funkce jako parametr string, ve kterém očekává číslo (např. z terminálu) a někdo tam zadá slovo, tak to stejně musíš uvnitř té funkce ošetřit, aby při konverzi na číslo ten proces nespadl.

Podobně je na tom i parametr int, ve kterém má být třeba číslo měsíce 1-12. Jen málo jazyků má pro tohle typ, např. Pascal a předpokládám, že i Haskell. Tím se ovšem přesouvá validace vstupu ven z funkce. Otázkou je: Opravdu chceme validovat vstupní data ještě před každým voláním funkce nebo si je raději zvalidujeme na jednom místě uvnitř?

Používám oba přístupy tak, jak to zrovna potřebuji. V PHP validaci uvnitř, v XSLT validaci venku.

[Kit]

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.

[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')
{} == {}

[BoneFlute]

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

Potřeba podívat se co je uvnitř je znakem blbě napsané rutiny.
Zvyk, dívat se dovnitř je znakem špatného programátora.

Ale obávám se, že toto nejde dokázat. Buď máte zkušenosti, a pak je vám to jasné, a nebo nemáte, a pak mi nevěříte.

[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.

[Kit]

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.

[Cikáda]

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...

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

Potřeba podívat se co je uvnitř je znakem blbě napsané rutiny.
Zvyk, dívat se dovnitř je znakem špatného programátora.

Ale obávám se, že toto nejde dokázat. Buď máte zkušenosti, a pak je vám to jasné, a nebo nemáte, a pak mi nevěříte.

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?