161–170 of 383 posts
I recently tried to make a simple flask app to sort pictures on my computer. I used file:/// since there were a lot of them.
I was quite unhappy to discover that CORS is quite restrictive...
Earlier quoted context omitted.
Webassembly is too recent. It needs to catch on. The momentum behind Javascript/Node is huge beyond comprehension. The engineering that has been poured into the JIT is also quite something. Just scrapping all of this and starting again with Wasm is not going to get traction from anyone.
Can you explain “Javascript/Node”? I thought Node.js was a JS interpreter but not the interpreter used in the major web browsers. Rather, that Node is an interpreter that’s used to run Js in (typically) headless (server) environments, allowing both sides to be written in JS. Is that accurate?
Earlier quoted context omitted.
Can anyone explain this to me?
Looks like the `true` and `false` _bindings_ in Go are mutable and can be re-assigned. The same thing was possible in Python 2, IIRC: False, True = True, False # Have fun debugging!
There are some real problems with the quirks of Javascript too even if the examples are not that common. Some JS coders for instance use the oneof pattern and if you then forget somewhere to check if you got a Number instead of a Boolean you can end up with something weird. I have seen it several times.
Biggest problem for JS, from the beginning was people start writing without completely understanding it. Even myself seeing my initial JS code feel embarrassed. Noone understand what is or handle loose typing, prototype, closures, functional concepts like currying before coding. I took almost an year to understand same. Although that time there are hardly my resources like now. But I still see, people directly jumping into JS.
0.2 + 0.1 === 0.3 That's not really a JS problem, that's a floating point problem. Plenty of languages will have the same issue. +!![] "" - - "" (null - 0) + "0" Calling these things weird is fair enough but I can't help thinking this is code you'd never actually write outside of the context of a "Look how weird JS is!" post. It's like picking examples from the Annual Obfuscated C Contest to show how hard it is to un…
Some of them are stretched examples, others comes from other languages/constraints (floating point, octal, ...), but some other are legitimately weird and error prone: [1, 2, 3] + [4, 5, 6] // -> "1,2,34,5,6" [,,,].length // -> 3
I don't think this is too weird if you think about it. JS allows trailing commas, so the last one is ignored. Effectively this is `[ undefined, undefined, undefined, ]`. A syntax error would have made sense here, but the length of three is a result of the usual syntax rules, not a particular strange quirk of JS.
Earlier quoted context omitted.
I think the situation is a bit different. This situation looks different in reality. The result may be (null-0)+"0", but the actual code will be foo()-bar()+baz(). And C will at least give you warning about types, even if NULL-0+"0" could give you an address. Plain JS without extra tooling would happily give you the unexpected result. Some other dynamic languages would at least throw an exception about incompatible t…
We've had these exact same sorts of issues in PHP. It can go undetected for awhile and cause subtle bugs. A good type system helps a lot. I appreciate that Kotlin is more stringent than Java with no implicit conversions between Int/Long/Float/Double.
Turns out several months before, someone was doing some refactoring, moved some methods around, but also changed a "==" to a "===" in the process. Generally a good idea, but it slipped through to production without anyone noticing or breaking any tests.
The issue ended up being that a rare code path in a tangentially related method would cause that method to return a float instead of an int. This propagated through, eventually causing a check of 0.0 === 0 to fail where previously 0.0 == 0 passed.
Earlier quoted context omitted.
Both of these examples are well-known (and not unexpected) behaviours. I assume you already know why it behaves like that. If not, I can explain it. > [1, 2, 3] + [4, 5, 6] // -> "1,2,34,5,6" What would you expect instead? > [,,,].length // -> 3 Is there any use case where you would want to deal with sparse arrays?
> Is there any use case where you would want to deal with sparse arrays? Not really. Now explain why [,,,].map((e,i) => i) is [,,,] instead of [1,2,3] please ;)
Array(4) // [empty × 4]
a=[]; a.length=4; a // [empty × 4]
Array(4).map(n => n) // [empty × 4]
[,,1,,].map(n => n) // [empty × 2, 1, empty]
Array.from(Array(4)).map((n,i) => i) // [0, 1, 2, 3]
Array(4).fill(1) // [1, 1, 1, 1]Earlier quoted context omitted.
The same for “== considered harmful”. I scanned the entire comparison table and the only unobvious or error-prone cases are those you never really do in programming. https://stackoverflow.com/a/23465314 For me it’s only rows [[]], [0], [1], i.e. array-unfolding related, but all others are regular weak-typed comparisons like in perl and other dynamic semantics. Edit: just realized “if (array)” is okay, nevermind.
undefined and null sometimes make problems. IMHO it's good that undefined == null but some people don't realize.
object.someField === null || object.someFeild === undefined
We could do an exception for null === undefined, but it’s against its spirit and will not be accepted.
^ languages that treat non-existent key as undefined are usually doomed to introduce Null atom in some form, or to work around that limitation constantly in metaprogramming
const
x = [1, 10, 2],
y = x.sort();
0.2 + 0.1 === 0.3 That's not really a JS problem, that's a floating point problem. Plenty of languages will have the same issue. +!![] "" - - "" (null - 0) + "0" Calling these things weird is fair enough but I can't help thinking this is code you'd never actually write outside of the context of a "Look how weird JS is!" post. It's like picking examples from the Annual Obfuscated C Contest to show how hard it is to un…
The same for “== considered harmful”. I scanned the entire comparison table and the only unobvious or error-prone cases are those you never really do in programming. https://stackoverflow.com/a/23465314 For me it’s only rows [[]], [0], [1], i.e. array-unfolding related, but all others are regular weak-typed comparisons like in perl and other dynamic semantics. Edit: just realized “if (array)” is okay, nevermind.
You never do them on purpose. The problem is when you do them by accident because of a mistake in your code, and the error slips through unnoticed, doing the wrong thing.
> weak-typed comparisons like in perl
Perl has separate operators for working on strings vs numbers, so you are always explicit about performing a numerical vs string comparison etc. Not so for JavaScript.