Problémy s JavaScript v praxi

[eee]

Typicky tohle
[1,2,3,15,30,7,5,45,60].sort();
// = [1,15,2,3,30,45,5,60,7]
je volant (řidítka, knipl, cokoliv), co otáčí dopravní prostředek na druhou stranu, než je přirozené a než všichni očekávají.

Když na to narazíš poprvé, zjistíš si, že pro čísla je správná syntaxe např:
[1,2,3,15,30,7,5,45,60].sort((a, b) => (a - b));
a příště už to neřešíš a jen používáš.

Já bych to uzavřel - kdo vidí JS poprvé (asi většina z přítomných), toho spousta věcí překvapí, kdo v něm pracuje pravidelně, tak automaticky píše syntaxi tak, aby to fungovalo správně.

To je pěkný bullshit. Javascript používám, od časů Netscape a IE 4.0, tedy od jeho počátku. Znám většinu jeho temných zákoutí i jeho historický vývoj. Už v roce 2002, tedy ještě před ajaxem, jsem s ním pracoval tak, že jsem si posílal do prohlížeče surová data a v js z nich generoval stránky, implementoval jsem v té době i interaktivní weby napsané čistě v js. Hodně věcí se mi na js líbí, ale to nic nemění na tom, že je to špatně navržený jazyk, který spoustu svých dětských problémů nedokázal odstranit a který spoustu jednoduchých a základních věcí neumí, nebo je dělá špatně, takže je zbytečně těžkopádý.

[Reklama]

[eee]

Je volant (řidítka, knipl, cokoliv), co otáčí dopravní prostředek na druhou stranu, než je přirozené a než všichni očekávají.

Já vás svým způsobem chápu, ale "je to trochu jinak, než jinde a já jsem líný si přečíst dokumentaci" je takový dost slabý argument. To nevztahuju jenom na JavaScript, ale celkově.

To není argument, jsem líný si přečíst dokumentaci, o lenosti nebylo ani slovo. A tím že špatné řešení zdokumentuji z něj dobré neudělám.

[eee]

Na porovnani identity objektu mas operator ===. Na porovnani obsahu objektu mas ==

V JS se objekty porovnávají striktně. Operátor === jenom vynechává konverze. Jak a tak b jsou objekty, proto je úplně jedno, jestli použiješ == nebo ===.

Nemusíš mi vysvětlovat jak to je udělané, já to vím, jen říkám, že je to udělané blbě. Z toho blbého návrhu pak plyne spousta logických nesmyslů, třeba tohle:

'x' == 'x'  // true
new String('x') == new String('x') // false

To na co upozorňuji je, že v JS nemá operátor na porovnání dvou stejných hodnot.

[eee]

Na porovnani identity objektu mas operator ===. Na porovnani obsahu objektu mas ==, ale v JS je spatne implementovan. Ale tak hlavne ze porovnava cislo se stringem.

Co mi napíše java nebo c# na (volná syntaxe)?:

var x = new object(bla bla bla);
var y = new object(bla bla bla);
(x == y)

taky false, protože neporovnává obsah, ale zda jde o totožný objekt (stejně jako v JS).

=== to nevylepší, protože k předchozímu jen přidá porovnání typu proměnné (zde object).

Proto java i c# na skutečné porovnání obsahu používá .equals() které JS nemá, ale není problém si ho přidat z nějaké knihovny nebo dopsat (anebo použít to výše uvedené porovnání objektů převedených na JSON stringy) .

Ano, java je zrovna tak těžkopádný jazyk, ale ta je aspoň statická a má alespíň nějaké standardní řešení. Mimochodem i v C je porovnání polí vždy false, ale a) hodí warning, když to programátor zkusí, b) má memcmp().

Mimochodem, víte že v JS se může vyhodnocení změnit z true na false, když k jedné straně přičtete nulu?

[eee]

Jestli to není spíš jako jet na motorce a divit se, že tam nejsou pedály :-)

Typicky tohle
[1,2,3,15,30,7,5,45,60].sort();
// = [1,15,2,3,30,45,5,60,7]
je volant (řidítka, knipl, cokoliv), co otáčí dopravní prostředek na druhou stranu, než je přirozené a než všichni očekávají.

Protože řadí lexikograficky...? Většinou očekávám, že výsledek lexikografického sortu, bude lexikograficky seřazený vstup...

Ano, proto. Že lexikografický sort řadí lexigraficky očekává každý, ale nikdo neočekává, že by default se bude na pole čísel aplikovat lexikografický sort.

[Reklama]

[Jano7]

Ramda je veľmi prepracovaná, tam je toho veľa. Natívne sa dá spraviť všetko, akurát to nemusí byť také elegantné a krátke.

Kdybys uvedl i očekávaný výstup, jistě bych ti místo toho napsal nativní zápis v Javascriptu, který bude kratší a přehlednější. Zkusím odhadnout, co Ramda dělá:

Kód: [Vybrat]

// console.log(R.compose(Math.abs, R.add(1), R.multiply(2))(-4));
console.log(Math.abs(-4*2+1))

// var f = R.pipe(Math.pow, R.negate, R.inc);
// console.log(f(3, 4));
var f = (a, b) => -(a^b)+1
console.log(f(3, 4));

// console.log(R.range(1, 10));
console.log(Array.from({length: 10}, (x,i) => i+1));

// console.log(R.sum(R.range(2, 8)));
console.log(Array.from({length: 7}, (x,i) => i+2).reduce((a, b) => a+b));

let nums = [4, -5, 3, 2, -1, 7, -6, 8, 9];
// let [ neg, pos ] = R.partition(e => e < 0, nums);
let neg = nums.filter(e => e<0);
let neg = nums.filter(e => e>=0);

To poslední se mi dělat nechce, ale bude to něco podobného.

No dobrá, poslední tři mám o něco delší, ale stejně jsi mě nepřesvědčil o užitečnosti Ramdy.

Odhadol si to dobre, akurát tam v druhom príklade bolo treba dať ** operátor.

Ramda má veľa šikovných funkcií a čím zložitejší problém, tým je úspora kódu vyššia.

[aaa]

Mimochodem, víte že v JS se může vyhodnocení změnit z true na false, když k jedné straně přičtete nulu?

Ono to má svůj důvod. Že tě to pořád baví, vysmívat se vlastní neznalosti. Ano, není to Java, není to Python a není to céčko. To jsi poznal, za to máš bod.

[andy]

Mimochodem, víte že v JS se může vyhodnocení změnit z true na false, když k jedné straně přičtete nulu?

Ono to má svůj důvod. Že tě to pořád baví, vysmívat se vlastní neznalosti. Ano, není to Java, není to Python a není to céčko. To jsi poznal, za to máš bod.

On to právě ví, takže to není neznalost... jen mu to asi připadá trošku směšné, že se takhle jazyk chová...a že to je dokonce podle specifikace....

[agent]

Mimochodem, víte že v JS se může vyhodnocení změnit z true na false, když k jedné straně přičtete nulu?

Co by podle tebe mělo být správným výsledkem {}+0 ?
Pokud pominu, že je nesmyslné sčítat číslo a objekt, tak JS se s tím vyrovnává převedením obou operandů na string před sečtením místo vyhození chyby (viz dokumentace "The general rule for addition in JavaScript is simple: You can only add numbers and strings, all other values will be converted to either one of those types.").

A {}+0 == {} (což je totéž jako "[object Object]0" == {} ) mi stejně true nevrátí. 

[agent]

Když to celé čtu, mám z toho pocit, že uživatelé mají největší problém s tím, že JS dělá v určitých případech automatické konverze typů.

[andy]

Když to celé čtu, mám z toho pocit, že uživatelé mají největší problém s tím, že JS dělá v určitých případech automatické konverze typů.

Což je něco, co se už se hezkých pár let považuje za anti-pattern, s možnou výjimkou int->float konverze...

[vokurky]

Pan EEE - s tim vsim co tady psa, ma naprostou pravdu, bez vyhrad souhlasim, jako clovek co je  vpodstate 100% ziven javascriptem a mam ho rad, tak tyhle chyby tam jsou, a je treba si to priznat.

[Meh]

Podle mne nejvetsi problemy JavaScriptu v praxi jsou:

1) V eshopu si chcete koupit vyrobek, ktery ma parametry A, B a C. Ve filtru kliknete na A, roztoci se kolecko, JS zacne drtit a po nekolika desitkach vterin, az vysype stranku s vyrobky s parametrem A, lze zaskrtnout B. Opet kolecko, JS drti desitky vterin, dalsi stranka a konecne lze zaskrtnout C. Nevim, co je tak tezkeho na tom udelat stranku, kde si zakaznik nejprve naklika A, B, C, pak to teprve odesle a dostane vysledek na prvni pokus, ne na treti.

2) 99% JS je reklamni a smirovaci hnuj.

[Fernet]

Podle mne nejvetsi problemy JavaScriptu v praxi jsou:

1) V eshopu si chcete koupit vyrobek, ktery ma parametry A, B a C. Ve filtru kliknete na A, roztoci se kolecko, JS zacne drtit a po nekolika desitkach vterin, az vysype stranku s vyrobky s parametrem A, lze zaskrtnout B. Opet kolecko, JS drti desitky vterin, dalsi stranka a konecne lze zaskrtnout C. Nevim, co je tak tezkeho na tom udelat stranku, kde si zakaznik nejprve naklika A, B, C, pak to teprve odesle a dostane vysledek na prvni pokus, ne na treti.

Není na tom nic těžkého. A nemůže za to JS, ale debilní vývojáři a ještě debilnější UX "designéři".

[Meh]

Podle mne nejvetsi problemy JavaScriptu v praxi jsou:

1) V eshopu si chcete koupit vyrobek, ktery ma parametry A, B a C. Ve filtru kliknete na A, roztoci se kolecko, JS zacne drtit a po nekolika desitkach vterin, az vysype stranku s vyrobky s parametrem A, lze zaskrtnout B. Opet kolecko, JS drti desitky vterin, dalsi stranka a konecne lze zaskrtnout C. Nevim, co je tak tezkeho na tom udelat stranku, kde si zakaznik nejprve naklika A, B, C, pak to teprve odesle a dostane vysledek na prvni pokus, ne na treti.

Není na tom nic těžkého. A nemůže za to JS, ale debilní vývojáři a ještě debilnější UX "designéři".

To jiste, ale pak se nabizi otazka, vzhledem k rozsirenosti tohoto jevu, proc je mezi JS vyvojari a designery tak hrozive % debilu, potazmo odpovedi, ze bud je ten jazyk laka, nebo vyrabi. Nebo kombinace obojiho, ale tak jak tak z toho JS nevychazi dobre.