Good, I also used to think storing timestamps in UTC was sufficient. The examples really explained the problems with that well. One other issue to note is that, if you store dates in UTC, now the fact that they are in UTC is a tacit assumption, probably not recorded anywhere except in organizational memory.
So the new API will be a very welcome addition to the JS standard library.
However, and this is probably a bit off-topic, why are the ECMAScript guys not also addressing the fundamental reasons why JS continues to be somewhat a joke of a language?
- Where are decimals, to avoid things like `parseInt(0.00000051) === 5`?
- Why are inbuilt globals allowed to be modified? The other day a 3rd-party lib I was using modified the global String class, and hence when I attempted to extend it with some new methods, it clashed with that modification, and it took me and hour or two to figure out (in TS, no less).
- Why can't we have basic types? Error/null handling are still haphazard things. Shouldn't Result and Maybe types be a good start towards addressing those?
Being able to modify built-in types is extremely useful in practice. This allows you to backport/"polyfill" newer features, like for example improvements to Intl or Temporal to older runtimes. If all the built-in types were locked down, we'd end up using those built-in types less because we'd more frequently need to use userspace libraries for the same things.
Like, you are asking for a Result type. If this was added to the spec tomorrow and existing objects were updated with new methods that return Result, and you can't modify built-in types, then you can't actually use the shiny new feature for years.
On the specific point of Maybe type, I think it's not very useful for a dynamically typed language like JS to have "maybe". If there's no compiler to check method calls, it's just as broken to accidentally call `someVar.doThingy()` when `someVar` is null (classic null pointer error) versus call `someVar.doThingy()` when someVar is Some<Stuff> or None, in either case it's "method doThingy does not exist on type Some<...>" or "method doThingy does not exist on type None".
> Like, you are asking for a Result type. If this was added to the spec tomorrow and existing objects were updated with new methods that return Result, and you can't modify built-in types, then you can't actually use the shiny new feature for years.
And that's a good thing, because you know that with a specific version of JS, the inbuilts are fixed; no mucking around to know what exactly you have, and no global conflicts. I find it surprising that you would defend this insane state of affairs. If you have worked on really large JS projects, you would see my point immediately.
It is like saying the immutability of functional programming is a bad thing because it limits you. The immutability is the point. it protects you from entire classes or errors and confusion.
> If all the built-in types were locked down, we'd end up using those built-in types less because we'd more frequently need to use userspace libraries for the same things.
Because that was the original behavior, and you can't just change that behaviour, or half of the web will break (including that 3rd party lib and every web site depending on it)
> Why can't we have basic types? ... Shouldn't Result and Maybe types
Neither Result nor Error are basic types. They are complex types with specific semantics that the entire language needs to be aware of.
So clean the language up, call it a slightly different name if you want, and let those who want to go modern do so. For those who can't, offer maintenance but no major new features for the original version.
Being wedded to mistakes made in the past for fear of breaking current usage is the root of all programming language evil.
> - Where are decimals, to avoid things like `parseInt(0.00000051) === 5`?
I personally dislike decimals, I would prefer a full BigRational that is stored as a ratio of two BigInts (or as a continued fraction with BigInts coefficients.
Decimals solve the 0.1+0.1+0.1!=0.3 error but are still broken under division.
The same reason you couldn't in 1996: because the assumed entry point for the language is someone who can barely conceptually manage HTML; doesn't want to have to deal mentally with the fact that numbers and text are fundamentally different kinds of thing; and - most importantly - absolutely will not accept the page failing to render correctly, or the user being shown an error message from the browser, for any reason that the browser could even vaguely plausibly patch around (just like how the browser has to guess whether an unescaped random stray < is just an unescaped less-than symbol or the start of an unclosed tag, or guess where the ends of unclosed tags should be, or do something sensible about constructs like <foo><bar></foo></bar>, or....)
So the new API will be a very welcome addition to the JS standard library.
However, and this is probably a bit off-topic, why are the ECMAScript guys not also addressing the fundamental reasons why JS continues to be somewhat a joke of a language?
- Where are decimals, to avoid things like `parseInt(0.00000051) === 5`?
- Why are inbuilt globals allowed to be modified? The other day a 3rd-party lib I was using modified the global String class, and hence when I attempted to extend it with some new methods, it clashed with that modification, and it took me and hour or two to figure out (in TS, no less).
- Why can't we have basic types? Error/null handling are still haphazard things. Shouldn't Result and Maybe types be a good start towards addressing those?