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.

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

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

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

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

This makes Dreamberd look credible

I'm absolutely baffled that people expect "false" to be falsy. That's like expecting the string "JavaScript" to be a full Javascript interpreter. Just because you type out the characters doesn't mean it should behave the same way when represented as a totally different data type.

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.

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

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.

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.

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

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

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.

"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

Mandatory comment complaining about blocks being called closures in this video

Saying +"5" is a bad way to coerce and then suggesting parseInt is hilarious

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

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

I thought the double not operator converts values to their boolean equivalent so !!"false" would be true because a string is truthy. !!"" would be false because an empty string is falsy. Same thing for the !!null, that would be false because null is falsy. The explanations around all the double nots seem to be convoluted at best.

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.

Really this just shows that the mentality of "sensible defaults" rather than erroring is a terrible idea for language design and programming in general

> Why is `Number.MIN_VALUE` the smallest _positive_ value? Because the smallest _negative_ value is `-Number.MAX_VALUE`. As simple as that. Again, simple floating point practices, common to all languages I am aware of. The ways how JavaScript treats floating point numbers is actually *consistent* , even though they may look weird and illogical (and appear "truly JavaScript-y").

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

-0 and 0 are warts of IEEE754 Floating numbers and as such they exist in most programming languages. There's no -0 in integer numbers.

"the falseyness occurs before the number coercion...why?" I think you already know why, it's just about evaluation order. The real questions are why was it decided that the empty array is truthy and why was it decided that == coerces things to numbers.

I agree with most things but some stuff is really simple, such as 3:07, and I feel like you may be overexaggerating this a bit. !!"false" == !!"true" being true is completely normal. A non empty string is truthy. The first ! makes it false, and the second flips the false and makes it true. There is nothing wrong with this, and yet you make it seem like it's very strange, and that we are in "hell". 4:57, When checking if a boolean is equal to a string, it obviously wouldnt return true. Now given my previous point, you might then confuse why !!"true" is true, and that is because ! converts it to a boolean. So it goes !!"true" -> !false -> true, which also explains 5:03. I wouldn't say that is "dumb". 9:20 Now I know this one isn't intuitive to understand, but I will try to explain it in a way that hopefully the confusion would go away. I believe the reason why null == false is false but 0 == false and "" == false is true, is because null is loosely connected to undefined (which is also why at 10:28, document.all == null is true, while document.all == undefined would also be true, but document.all == false is fasle). Undefined is when the value isnt assigned, and null is when its been assigned but has no value, and so there is no type coercion. Strings and numbers go through type coercion but null doesnt, since it's not really a type. All you need to remember is that there is no type coercion for null and undefined and that should make sense of this. People should not be told these are challenging or strange. You can make simple things become difficult by simply pretending that they are. Many people including myself look up to you, and so I think we would all appreciate it if you would actually pause to think about these things instead of hopping on the "Yep there it is, JavaScript is dumb".

I'm so early, most of the comments are spam!

Honestly confused on why everybody hates this weird JS, you never run into these issues if you write good code

Prototype helps so much when I need an insert function bc somehow js doesn’t have it yet😢. Edit: nvm I bothered to do research but still, why is it an extra arg on splice with 0 in the delete count?

Honestly, I feel these issues are overblown by people who dislike javascript for entire different reasons. Most of these boil down to "don't use operators on non-primitive types". I genuinely don't remember last time I would trip on any of these in last 15 years writing JS.

15:57 sometimes I think that He doesn't know what he talking about ) so, basically what happened, first array is empty and when you try to access nonexisting key you will get undefined the same that you store in second array under existing key you can not get "empty" value from array

Repo: Consider this step-by-step Theo: "I don't want to consider this step by step" cracked me up

I'm wondering... What if I define a toString method which does not return a string? How will the + operator work then? Just try it: const a = { toString: ()=> 1, }; const b = { toString: ()=> 3, }; a + b;

Integer arrays being sorted alphabetically is remarkable...

your sarcasm actually breaks me

Javascript has a reason for most of its weirdness. The reason some design decisions are criticized is that much like required reading in highschool, if you work with the web at any point, you have to deal with javascript. People just grow resentful they have no choice to use it, and making fun of certain features become memes. Because of its position as the main programming language of the web, it can't really do breaking changes, and undoing certain core design desicions isnt feasiable. When it was created, its creator had no idea of the scope it would eventually cover, and since the community grew so huge, contributors had to balance giving everyone enough features so that everyone was only half angry. But yes it is fun to make fun of all the quirks of the language, just don't forget that there is context to all of the design decisions you don't love. Also python, get some brackets, ruby, not everything has to be magic, Php, you're cool now.

"I hate everything. I'm going to become a farmer." I think about this often...

thank you for inspiring me to watch actual coding channels who know what they're talking about and also to join your nemesis as a member, he needs more funding to do what he's doing for the community :p

Theo, you are uniquely talented in both your ability to understand an process the examples quickly, and in not getting bogged down (as I believe most people would) in the endless details and potential rabbit trails that present themselves along with the seemingly inexplicable results. If I were to walk through this list of examples it would take me hours to complete the journey.

I feel like Theo is the kind of guy that if he ever used ActionScript3, he'd be stuck using it since its got most modern syntax features (E4X, JS typing, Embedding file) in an old language

You can attach properties to String objects but not native string instances. I've used this for templating meta information for database string templates.

18:54 I have not searched a lot but from messing a little arround I think that some very high exponents are reserved for NaN and Infinity. They are numbers because it is way back from c where you can obviously store NaN into a float, because, what other option does it have?

The more crazy js is, the more I like it. Awesome video!

12:00 This is an important concept in math. I was just reading about Kakeya’s Needle Problem today, and the goal in it is to minimize the area needed to sweep a needle of zero-width 180°. Various mathematicians found ways to minimize the area needed that approach zero at the limit, but the area can never actually _be_ zero. This would be a perfect application of Number.MIN_VALUE. The limit would be equal to it, and it would be greater than zero, for good reason. Meanwhile, negative infinity would be smaller than any number, and negative Number.MIN_VALUE would be the largest negative number before zero.

12:00 "Why is the smallest *_positive_* number? Why? I don't know what the use of that is" Clearly Theo has never dealt with the _joy_ of handling floating point numbers before

"why is there a -0" thats because how the sign is stored in memory.

Fun fact, -0 is actually part of the FP standard, a lot of languages have it! I've specifically used it as a special flag in games I've made.

I would assume (I haven't looked at the actual implementation) that values are stored in a way similar to this: struct Value { bool is_empty; enum { VAL_UNDEFINED; VAL_NULL; /* ... */ } type; void *value; } so when you set no value, it just sets is_empty to true, but when you set a value manually, it sets it to false, and then sets the type to undefined. I'm not sure why undefined doesn't just always set it to empty, or empty is just the undefined type, but maybe its because JS is old and people rely on it now.

It's weird because most people don't understand typecasting that's done by js when == is used instead of using ===.

I'm new to JavaScript and learning, I like it so far, coming from Java, But this looks scary lol! So should I even go further or do I still have time to change lol.

Your comments - especially the resignation and despair - were absolutely hilarious. Thank you... :D And just so you know, this is how I sometimes feel while writing PHP. xD You are not alone.

Your reaction thumbnail is spot on.

If you don't get -0, then you can't understand floating point. It's not a JavaScript thing at all. All floats are approximations. They have limited precision. And sometimes it matters if the result you get is slightly less than 0 or slightly more than 0. NaN !== NaN makes sense, too. NaN is a result you should not get. If two expressions fail, you don't really want them to be equal to each other. And I get why "false" != false. It's normal to check if a value has been input by doing "if (textbox)". It would suck if that failed because the user typed in "false." The idea that any non-empty string is true makes sense to me. I only find it weird when the DOM coerces false or undefined into "false" and "undefined". That's dumb, and should be the same as assigning the empty string. And of course string- number equal not a number. There is no defined operation for subtracting strings. What else could it return?

Pretty rough. Grateful someone else went through it, not me.

I think Google has a brain implant in me, I was just thinking about how cursed JS is, just a random thought, and I scrolled half a page, and here's this video. It's not even like I watch heaps of this channel 😂

Someone has probably already mentioned this, but JS actually can't take credit for the NaN != NaN thing. That's completely from the IEEE floating point spec. It's in basically every language and baked into the silicon.

Bro I genuinely didn't know abt the sort thing at 40:49 and now my code doesn't randomly function in dumb orders

TLDW Every few years someone makes this video. These issues do exist but they don't seem to manifest in real code.

I'm not a JS guru, but I'm using it for decades. For the vast majority of these quirks I never had a problem , simply by not relying on stupid syntax. I never use a string as a boolean value. Why would I? Even if I remembered the detailed implications, I would never expect the next guy working on my code to remember it. I don't use `+` to concatenate strings unless there is a good reason to. When I do, I start the expression with `"" + ...` to make sure the intention is clear. Why would I ever want to `str - number`? Why would I ever use an array in a scalar context? Knowing the semantics of `==` why would I ever prefer it over `===` unless I want the precise semantics of `==`, I can't remember such a use case. I don't remember the precise semantics of `==`, it's faster to express the semantics I need explicitly instead of looking up what `==` does precisely and burden my coworkers with the same task. I'm not stupid, neither am I malicious or irresponsible. I'm not saying JS is a great language. But for all practical purposes, it's by far not as bad as its reputation. Anybody who uses `false == "false"` to say anything about the language that is interpreting this code is not qualified. Such code should never have been written for any purpose other to condemn authors of such code to hell fire. However, if you are stupid, malicious or irresponsible, you can create the very same kind of confusion with any other language, Rust, Zig and Python included. Well maybe not the same kind, but the same headache resulting from where-ever your stupidity leads you to go.

typeof 1 == typeof "1" being false makes total sense because 1 is an int and "1" is a string

21:59 which javascript engine `{} + {} // -> '[object Object][object Object]'`? I get NaN in librewolf 127.0.1-1

I do have some cases where I add numbers in JS like if I want to have atleast 2 out of 4 things to be truthy I can cast them to bools add them and check if the sum is greater or equal to 2

2:32 Honestly, when the first example here is about asking "why?" does the order of operations matter in a programming language, I'm really not sure what the point of this video is

Fun fact, the empty items in an array are called "The Hole" within the V8 engine. "The Hole" falls into the "Oddball" category of types

About the new String thing: you can call the String and Number constructor with and without new: without new, it works just like you would expect, it converts the argument to the respective type, and typeof will give you a reasonable result. with new, you get a "String object" or "Number object", which is basically like a string or number, except that you can actually override functions and stuff, as you've shown with your "this is the wrong string" example.

Some of these are just normal programming things, and are quite intuitive if you understand a little bit of how computers work under the hood.

It seems like there is still an opportunity to create an npm package to warp these comparisons into custom comparators, just to break out of this madness

NaN != NaN is part of IEEE spec and same in other languages. It makes sense since something like 0/0 == parseInt(“hello”) would be crazy, and make debugging harder. Classic frontend script kiddie to blame standard floating point behaviour on js ;)

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 negative

36:09 - "We're moving on because nobody uses 'this' anymore." * _cries in Angular_ *

It’s so weird that toString unwraps an array of one element. No other language I know of does that.

5:42 "Why?" Because the "+" operator for a string function as a concatenation. String does not have any behaviour for a "-" so the only thing it can do is perform a subtraciton. A string is Not a Number (NaN) and NaN - 5 = NaN. Like what another commentor said. Nearly all of these are impossible to do accidentally if you don't do stupid shit.

the "wat" talk honestly summarizes javascript pretty well

"why is the internet slow?"

wait, in what unborn hell did no-one consider the additive concatenation of arrays _as arrays_ and here i thought js had that

Someone looked at DreamBerd spec and thought "hmm not scuffed enought", and then invented JavaScript

Somebody told me after Theo published this video four friendly men in white cloaks had to take him away in a “Love-myself-so-much” jacket.

my mind is going blank

I love reJular expressions lol

no negative zero? Rust: "hold my beer" *lets you divide by zero*

alternative title: theo grunting for 45 minutes straight

so many of JS's wonky-ahh casts makes me feel smug as someone who primarily uses ocaml (which is so strictly typed that float and int addition have to have separate symbols)

This stuff happens in any dynamic language where they decide you should be able to compare things that have different types and also that types should coerce automatically. The rules they decide usually make sense if you look at them in isolation of the original intent of the rule, but the resulting semantics is so broken that you can't rely on it because it quickly becomes mostly impossible to predict for a human. Basically showing that double equals shouldn't exist.

I have 2 uses for the double equal: - x != null // check if variable x is defined - x == y // check if values are equal, when you KNOW they are either a number or a string, like for checks with input values

35:00 This is why you should turn off "allowUnusedLabels" in your tsconfig when you write TypeScript. () => { hello: "world" }; will report an error with that option set to false.

patching the Number prototype has a neat application: you can make numbers iterable (counting 0 to n-1), so you can "for...of" them or use them everywhere iterables can be used. i also added some forEach, map and reduce methods. for numbers that aren't positive intergers, the behaviour isn't quite so obvious but your also unlikely to use them for those. :P i get why expanding builtins is probably not something you should do in a professional setting, but it's a very nice feature to use and it may be a cool in other languages.

The String.split() behaviour is correct (at least the one shown here, it might do something weird in some other cases, it's JS after all): - There are empty strings between each character (conceptually), so splitting on "" must return an array of every character on the string. Since you are calling it on an empty string, that result will be empty. - Splitting by something not in the string should return nothing, because there's nothing to each side of that separator ( the case for "".split(" ") ). These are just edge cases, but the behaviour is logical.

15:09 is not about 3 different values for empty value, it's about setting length to 3, but array object have not keys "0" and "1" assigned. [undefined, undefined] assigns that keys to undefined. Array in JavaScript are just Objects with string keys and magical 'length' property.

−0.0 exists because IEEE floats are implemented as sign-magnitude pairs, so with magnitude 0, you can choose a positive or negative sign. A different approach to floating-point numbers is, effectively, using INT_MIN as NaN and using 2’s complement for negatives. That format exists and is called Unum.

37:40 so are you saying that the assignment operator evaluation order is left to right? foo.x = foo, then foo = {n:2} what about this then: var y=1; var x = y = 2; ???

I solved 5 levels of "return true to win" and I'm reconsidering my life choices now

I love the fact that javascript has a set of consistent logical rules, even when it this results in it acting absolutely absurd at times.

“I hate everything. I’m going to be a farmer.”

even though its totally obvious you are being sarcastic and having a fun, i still really appreciate your hint here at 1:45

best part is receiving bug reports that the app would randomly consume 100% cpu turns out it was a relative date component (i.e. turns new Date(0) into "54 years ago"), that updated in real time. turns out if the time until the next update (ie. 5.4 seconds ago is 600ms away from displaying "6 seconds ago") was greater than 24.8 days, or 2,147,483,647 ms it would call setState() or forceUpdate() or whatever it was in a loop

The only reason I watched this was to hear someone else explain the concept of the minimum of an empty set being ∞ and the maximum being -∞. But you didn't. Dammit.

There is a complicated table of how == equality works. But the truth is… you don't need it in reality, unless you're doing something strange. If you're comparing primitives they would be coerced to string or number depending on what you have passed in. So, it's handy to check for example == 2, when your backend may send "2" with no need of manual coercion Number('2'). I'd recommend to use strict comparing === to *true* or *false* , but that's a rare case, especially after defaults where introduced, and one can do something like function foo(bar = true) { if (bar) … // could be “if (bar !== false)” in the old days } Objects are compared their to strict identities between them, no matter are you using == or ===. [] != [] is same as [] !== [] and is true, since you're comparing two different freshly created arrays here. *null* and *undefined* are equal only to self, as already noted. So it's safe to compare anything with them. (Usually != null is handy and shorter.) The unexpected part begins when you're comparing any type of object to primitive, so it's a bad idea to do. Just don't do it. Why would you? Why would one compare *false* and an array? It's that case when explicit better than implicit. E.g. by using .toString(). But still it's quite a rare case too. Usually, objects compared to be same or being nullish. So, that WAT part is quite overhyped really. Yep, one cannot use + to concatenate arrays like in Python, [...array] spread or .concat() should be used for that. But you learn it when you learn basics about arrays and their methods. No big deal.

2:32 explanation here was slightly wrong as far as I can tell from the spec. LHS is interpreted as "+[]" because "![]" is a boolean value. If my understanding of the spec is accurate the breakdown should instead look like this: ``` [] == ![] [] == false +[] == false 0 == false true ```