3 ms·

One thing I wonder is how could this have happened. It seems that this what a herd of absolute beginners would come up with: strong inconsistency and a bunch of

One thing I wonder is how could this have happened. It seems that this what a herd of absolute beginners would come up with: strong inconsistency and a bunch of heuristic that are not composable. But I imagine this was not the result of a bunch of beginners, what were the forces that lead to such a situation?

xmprt 1y ago
When a language allows operator overriding or doesn't have static typing, you can end up with situations like this where a single method does 10 different things for 10 different use-cases. Even Java and C++ aren't a stranger to APIs like this (although not nearly as bad).
stevage 1y ago
To be somewhat fair, most of what this is poking fun at is the parsing of strings that do not remotely resemble actual dates. It's very edge case behaviour. Yes, it'd be nice if the edge cases did something more predictable, like all just fail with an error, but unless you're doing something silly like passing whatever a user writes straight into Date.parse() it isn't going to matter. Realistically, you're going to use an actual date library, because even the good bits of Date are pretty bad.
- vander_elst 1y ago
  > parsing of strings that do not remotely resemble actual dates. But this is somehow my point, what were the reasons that lead to parse those strings as dates. I guess the answer is usually legacy, but in that "legacy" why did someone need to take those decisions? My naive way of parsing dates would be to reject everything that doesn't have a well defined format while the format is well defined and at least somehow composable, but here someone had the need (I hope the had the need) to parse these seemingly random strings, I wonder why.
samwho 1y ago
A couple of other comments have noted, and Brendan Eich himself actually replied on Twitter (https://x.com/brendaneich/status/1944156296212886005?s=46 https://x.com/brendaneich/status/1944156296212886005?s=46), to say that it was a copy of Java’s Date class behaviour. I haven’t dug into the history of that, though.
- BrendanEich 1y ago
  Thanks. More info in this thread: https://x.com/BrendanEich/status/1752615257615528205 https://x.com/BrendanEich/status/1752615257615528205

xmprt 1y ago

When a language allows operator overriding or doesn't have static typing, you can end up with situations like this where a single method does 10 different things for 10 different use-cases. Even Java and C++ aren't a stranger to APIs like this (although not nearly as bad).

stevage 1y ago

To be somewhat fair, most of what this is poking fun at is the parsing of strings that do not remotely resemble actual dates. It's very edge case behaviour. Yes, it'd be nice if the edge cases did something more predictable, like all just fail with an error, but unless you're doing something silly like passing whatever a user writes straight into Date.parse() it isn't going to matter. Realistically, you're going to use an actual date library, because even the good bits of Date are pretty bad.

vander_elst 1y ago
> parsing of strings that do not remotely resemble actual dates. But this is somehow my point, what were the reasons that lead to parse those strings as dates. I guess the answer is usually legacy, but in that "legacy" why did someone need to take those decisions? My naive way of parsing dates would be to reject everything that doesn't have a well defined format while the format is well defined and at least somehow composable, but here someone had the need (I hope the had the need) to parse these seemingly random strings, I wonder why.

samwho 1y ago

A couple of other comments have noted, and Brendan Eich himself actually replied on Twitter (https://x.com/brendaneich/status/1944156296212886005?s=46 https://x.com/brendaneich/status/1944156296212886005?s=46), to say that it was a copy of Java’s Date class behaviour. I haven’t dug into the history of that, though.

BrendanEich 1y ago
Thanks. More info in this thread: https://x.com/BrendanEich/status/1752615257615528205 https://x.com/BrendanEich/status/1752615257615528205