It also makes a lot of conditional expressions less complicated because comparisons of all kind against NaN return false.

Math.min isn’t the minimum integer; it’s the minimum of a list (and max visa versa)… the min/max of an undefined list is the same… IDK what it is, but this probably the most reasonable of the “WTFs” they could have put there i think… other languages would throw an exception or not compile (which JS definitely SHOULD do instead of this, buuuuut lots of JS has aversions to errors)

*edit: okay the curiosity was killing me: Math.min() is Infinity and Math.max() is -Infinity

Tony Hoare: “Introducing NULL was a billion-dollar mistake”

Brendan Eich: “Hold my undefined”

“This comparison appears to be unintentional”

nah, it’s more fun this way.

It’s not true in a normal programming language. If it is true in yours, you should stop using it immediately.

probably not true in most other langauges. although I’m not well versed in the way numbers are represented in code and what makes a number “NaN”, something tells me the technical implications of that would be quite bad in a production environment.

the definitive way to check for NaN in JS would probably be something like

// with `num` being an unknown value

// Convert value to a number
const res = Number(num);

/*
 * First check if the number is 0, since 0 is a falsy
 * value in JS, and if it isn't, `NaN` is the only other
 * falsy number value
 */
const isNaN = res !== 0 && !res;

Yep, it’s C

I’m guessing there’s a reason they wanted min() to be able to be called without any arguments but I’m sure it isn’t a good one.

It not a totally unreasonable definition. For example it preserves nice properties like min(a.concat(b)) == min([min(a), min(b)]).

Obviously the correct thing to do is to return an optional type, like Rust does. But … yeah I mean considering the other footguns in Javascript (e.g. the insane implicit type coersion) I’d say they didn’t do too badly here.

So, the language isn’t compiled (or wasn’t originally) so they couldn’t make min() be an error that only a developer saw, it has to be something that the runtime on the end-user system dealt with. So, it had to be assigned some value. Under those restrictions, it is the most mathematically sound value. It makes miniumum-exactly-2(x, min(<…>)) be exactly the same as min(x, <…>), even when the “<…>” has no values.

As a developer, I see a lot of value in static analysis, including refusing to generate output for sufficiently erroneous results of static analysis, so I don’t like using JS, and the language that I tinker with will definitely have a separate compilation step and reject the equivalent of min(). But, if I HAD to assign something like that a value, it probably would be a representation of infinity, if we had one (probably will due to IEEE floats).

HTH

It’s pretty easy to avoid all of these, mostly by using ===. Null being an object is annoying and is one of the reasons ‘typeof’ is useless, but there are other ways to accomplish the same thing.

JavaScript has a lot of foot guns, but it’s also used by literally everyone so there is a lot of tooling and practice to help you avoid them.

I don’t think my sanity can take all of these explanations.

Though I just spotted one that’s worse than null being an object …

typeof Nan
"number"

I mean, come on… it’s even in the fucking name!

Notch? The guy who codes in java?

Math.min.length is 2, which weakly signals that it’s designed to handle at least two parameters

Why would they even define this value?

Note: I’m not a js dev, do most functions have length?

That is not a fun fact. How do I unsubscribe :D

But B is true