The one thing JS has going for it is it's huge since it happens to be the language of the web, which means lots of time goes into optimizing the hell out of it, which means these days it's fast (but only thanks to ridiculously complex, massive, incomprehensible JIT engines).
-
Yes, the ECMAScript spec says toString must be implemented in this (broken) way. This is insane, and no other sensible language does this. It is misleading and wrong. https://tc39.github.io/ecma262/#sec-tostring-applied-to-the-number-type …
Numbers are floats in Lua <5.3 too, but it never pretends floats are integers that they aren't. Smaller exact-int floats are stringified as integers, then after a threshold (lower than the 53-bit limit) it switches to exp notation. string.format will give you all the digits.pic.twitter.com/cimunNayeM
-
-
Ultimately this is a problem of the principle of least surprise. To any reasonable human, a string of digits with no decimal point is an *integer*. However, to JavaScript, it's a *float*. JS is abusing this point to produce unexpected results from toString.
-
Yes, the output string equals the float when spat back into a JS interpreter, but that's besides the point. It's not what a *human* expects. This is like the people complaining about things like undefined behavior in C. Except the latter is at least often useful for performance.
- Show replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.