JavaScript Coercions Grid
getify.github.io
getify.github.io
Are there any better options for dynamic languages when a weird coercion is going to be done? Throw an exception? Exit with an error? Convert to some special invalid_coercion value similar to NaN?
It's another reason static type checking (i.e. don't let the code run) is a no-brainer to me.
Seems like the best choice rather than plowing ahead with assumptions
Discovering how the sort function works was also not fun.
That's what strict mode was for.
I also think `true + 0 == 1` is perfectly reasonable, but I get that this might not be reasonable for everyone. All the other fixes look like genuine improvements.
Yes, two numbers of different signs added together are supposed to be 0, but... a number is never supposed to change (sign or magnitude) when you add 0 to it, and here it does... so... it's a strange corner case that I think defies intuition.
Given the two precedences that are incompatible, I think far more people are likely to think "anything + 0 ======= anything" than they are to think "anything + -anything ========== +0". So that's why I marked it as a WTF.
In the “real numbers”, zero doesn’t have a sign at all, and -0 and 0 mean precisely the same thing. Floating point is an approximation which needs to make some choices about edge cases, for the sake of practical uses (for instance it is useful to distinguish negative underflow from positive underflow, so there is an extra -0 value included).
The behavior that 0 - 0 or -0 + 0 produces 0 as output is not an unreasonable choice (it is what I would expect, as someone with a decent amount of mathematical experience). I would not expect very many people to have the “intuition” that -0 + 0 or 0 - 0 should produce -0 as a result, assuming they had any intuition at all about what should happen in this edge case.
I think if someone is careful it should be possible to make an implementation of complex square root on top of IEEE floats such that √(–a² + 0i) == ai, whereas √(–a² – 0i) == –ai, representing the two sides of a branch cut.
Yes, √–0 should be 0. File a bug against whatever implementation returned –0 for that one.
In the context of that paper it seems to me that √(–0 – 0i) should be 0 – 0i and √(–0 + 0i) should be 0 + 0i, but under no circumstances should the result be –0 ± 0i, which is on the wrong branch.
The obvious extension to real-valued square root would be √(–0) == +0.
-0 + 0; // 0
-0 + (-0); // -0
-0 - 0; // -0
----
Consider the counter-argument, that it's intuitive/correct because in math `X + (-X) = 0`:
3 + (-3); // 0
-3 + (3); // 0
-0 + (0); // 0
0 + (-0); // 0
X + (-X) = 0 // -->
X = 0 - (-X) // -->
X = 0 + X
The author might want to add !!foo as an additional type of coercion (to bool).
In the right timeline, a deeply flawed language like JavaScript would never have been successful and we would use a decent application delivery mechanism that is platform-sensitive and not a hypertext document browser with a document model unsuitable for interactive apps.
But here we are: Never bet against JavaScript
but in that same timeline, we had Java, which was touted to solve all of those problems, vs Javascript which was touted to add slight interactivity. We took a step sideways, instead, with Java offering a lousy user experience for what it promised, and Javascript getting progressively better, while promising nothing in the early days.
The other competitor, Flash, ended up flawed in its own right.
And here we are.
From the start Javascript was built in to browsers and even as it grew it was running in the context of a web page. By the time Javascript had grown large enough that people were looking for other languages it had become too entrenched.
Besides, Javascript is good enough for most websites. It's only larger web apps where it becomes more of a problem.
which is pretty much where we are today, especially with wasm and bundles. we just went around the virtual machine and byte code before coming back.
from Javascript's start, it was embedded, but Java applets were pretty early as well. The core problem was direct interactivity with the browser, which Javascript had a small amount of initially, and Flash/Java tried to subsume. The difference was how the browser itself was treated.
Wasm was built from the ground up to be run in the context of a browser. It's also implemented by browser vendors so they can take responsibility for security. In essence, the difference is that it's made to be sandboxed from the rest of the system.
But that was Netscape's initial decision. There was nothing stopping a browser vendor from embedding Java into the browser the same way. Microsoft ended up doing that for VBScript in IE. Lotus Notes was embedding Java on their clients in the mid 90s alongside LotusScript. In addition to that, you could even copy/paste a Java applet from the web into Lotus email, and it would run, although that was different from having Java embedded as a language.