I Tried Defending EVERY Cursed JS Behavior

Ok 0*-1 =-0 is the funniest thing I have ever seen

IIRC, NaN != NaN and -0 == 0 are part of the floating-point spec; most languages follow it.

I love how nearly all of these are impossible to do on accident if... - You use TypeScript - You don't do stupid shit

the reason -0 exists is because of IEEE 754. it makes sense, Floating point is an approximation of the real number line. -0 represents that the very small number we want to represent is negatice

half off video is Theo doesn't understand floating point numbers

Hey Theo! The creator of the wtfjs repo here 👋 Thank you so much for making a walkthrough of my examples. I really enjoyed watching it, and I think we should definitely add a link to this video in the README. You’ve made it both entertaining and interesting to watch. P.S: I noticed that you decided to cut out the repo banner asking for support for Ukraine. As someone still living in Ukraine, I experience the daily realities of missile and drone strikes, electricity outages, and all the other hardships that come with war. I, along with all Ukrainians, still need the community’s support.

+0 and -0 is not JavaScript thing. This is feature of floa ting point numbers internal format which is used by CPUs and GPUs for a very long time.

This makes Dreamberd look credible

The reason for NaN not being equal itself is that, if it was equal, then this would be true: Math.sqrt(-2) == Math.sqrt(-3) [NaN == NaN] where it is obviously false.

Honestly, almost all of these weird things come down to the same root cause: type coercion. JS is just far too willing to coerce types, so if you code in a way that avoids it, you'll probably be fine; explicitly convert types yourself, don't rely on JS to do it for you. Or, you know, use TypeScript.

"Ask stupid question, get stupid answer" - JavaScript truthy, probably

Dude, seriously. Read the floating point spec. Most if those "errors" are in all programming language and for good reason

These kind of videos serve mostly to show off the ignorance of the person looking at the examples. In the nineties and naughties, people had this silly idea that languages shouldn't trigger error messages when people did something wrong, but instead try to do what the programmer intended. I think that was a reaction to the cryptic core dumps and errors of languages of the seventies and eighties. People thought error messages was the problem so they avoided them. This is common to all languages of that era, JavaScript, PHP (which has exactly one good feature), Ruby, Python, CoffeeScript, jQuery... Some are worse than others, but all are infected with that mindset. And then people usually go on to complaining about floating point arithmetic to just really show off their ignorance.

Regarding the empty slots in array: They denote a missing index it's not a different type of `undefined`. Say you have the array `const sparseArray = [/* empty */, "1", 2]`, then you can check if a slot is empty by doing `0 in sparseArray` if the array doesn't have the property `0` it indicates an empty slot in index position `0`. The reason why the return type is a normal undefined is because if you access an attribute that's not there you simply get `undefined`. For example `const obj = { a: 1 }` then `obj.b` will yield `undefined`. Just like `sparseArray[0]` yields `undefined`. You are accessing a property that doesn't exist. If I would do `delete sparseArray[1]` then index `1` is now also an empty slot.

12:02 What do you mean why?? thats literally your epsilon

I swear there's a cron job somewhere that churns these articles out on a quarterly basis, complete with all the same convoluted examples.

Mandatory comment complaining about blocks being called closures in this video

I'm frankly more surprised how little he knows about how javascript works tbh.

"Why does -0 exist?", "Why is NaN so weird?", etc most of the weird things pointed out here are just actual parts of IEEE 754. IEEE 754 is what we usually call the floating point spec but its actually more than that its the floating point arithmetic spec and as such includes a bunch of things that are weird or confusing if you dont work on a very low level with floats. Things like NaN, -0, infinity and -infinity are all values that IEEE 754 have defined for good reason and their weird behaviours follow therefrom. NaN should not equal NaN since NaN is more of an error state than an actual value and are in spec returned from any "invalid" arithmetic operation (0/0, infinity * 0 that kinda thing). This is good! This makes float arithmetic algebraically complete that is every operation returns some value even if that value is kinda nonsense. This also means that there are multiple ways of getting NaN hence why it would make no sense for NaN to equal itself. Most other "weird" operations with these values have similar justifications. In my opinion the fault isn't in the fact that these values behave like this. They should behave like this there is a good reason they do and they don't (or at least they shouldn't but who knows what happens once JS type coercion is done destroying everyone reasoning abilities) show up in most code because they are edge case definitions. In general these values are very low level constructs so you could even argue about whether or not JS should even expose these directly instead of handling them in a more language appropriate way within the engine itself but it's too late for that now so. If you want a better understanding of why IEEE 754 is like it is go read the "Design Rationale" part of it's Wikipedia page or better yet go read the spec itself! It's a very interesting topic if you like these more low level things

"Array equality makes NO SENSE!!" and then array equality makes complete sense