Hacker News new | past | comments | ask | show | jobs | submit login

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.

This is the correct solution for now.


> - Where are decimals, to avoid things like `parseInt(0.00000051) === 5`?

There is a draft proposal for this: https://github.com/tc39/proposal-decimal

Additionally, BigInt has been available for years: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... (unfortunately does not serve as a u64 / i64 replacement due to performance implications and lack of wrapping/overflow behavior)

> - Why are inbuilt globals allowed to be modified?

> Error/null handling are still haphazard things.

How would you suggest addressing these in a way that is backwards compatible with all existing web content?


> How would you suggest addressing these in a way that is backwards compatible with all existing web content?

Version numbers. Solving the problem in the future but not the past is still better than leaving it unsolved in the future and the past.


> Why are inbuilt globals allowed to be modified?

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.


> For those who can't, offer maintenance but no major new features for the original version.

How do you imagine doing that?

> Being wedded to mistakes made in the past for fear of breaking current usage is the root of all programming language evil.

Ah yes, let's break large swaths of the web because progress or something


They could use new directive though, ie:

    "use awesomeness";


    from future import awesomness


> - 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.


>Why can't we have basic types?

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....)




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: