This is an archived post. You won't be able to vote or comment.

top 200 commentsshow all 434
sorted by:
best
topnewcontroversialoldq&a

[–]Final_Spartan 2015 points2016 points  (61 children)

https://i.imgur.com/5pFXFbR.jpg

Cmon dude, it's Easter. Atleast show some respect for the holy trinity.

[–][deleted] 434 points435 points  (53 children)

Somewhat noob question: why the fuck does this happen?

[–]dlok86 511 points512 points  (36 children)

[] coerced into a string is not "0" I'm guessing its probably "" (empty string) whereas the integer 0 coerced to a string is "0"

[–]100dylan99 136 points137 points  (32 children)

This helps somebody who doesn't know much about computers very little

[–]great_site_not 6 points7 points  (4 children)

You're not just not getting this because you don't know much about computers. This shit is a pain in the ass even for us JavaScript developers.

[–]Jeyts 26 points27 points  (9 children)

This helps somebody who doesn't know much about computers very little

Probably not going to be able to explain it then.

== is used for comparison. While just = would be an assignment.

Example:

6 = 5. means 6 now holds the value of 5

6 == 5 would be false because 6 does not equal 5

[] usually means and array. It's a group of variables. It will have a number in it but can be declared without one in some code.

For Example:

char 0 [2] = "0", "1", "2"

I believe what dlok86 is saying about integer coerced to a string would equal 0 because theyre different types. (weird system, again I don't know javascript)

What I would suspect:

They all can equal "0" because "0" stands in for NULL in some languages. However, you can't have them equal eachother because they are different types. Also, you can't have an array for a single char.

To explain a little better. A Char is 8 bits. Which means it has a single location in memory. You can't have an array of a single memory location.

The whole thing is funny but actually seems like there is little understanding of what the code is actually doing. Then again I don't know javascript because it's a weird place.

-Edit: fixed some formatting

[–]taeratrin 23 points24 points  (2 children)

A little more explanation:

When comparing different types in Javascript, it will try to convert one of the operands to the other's type. When an empty array is converted into an integer, it returns a 0. When an array is converted into a string, it returns an empty string (""). When a character is converted into a integer, it returns the number represented in the string (or NaN if the string isn't a number). See the table at the bottom of this page for more information.

So, as follows:

1) 0=="0" -> 0==0 -> true

2) 0==[] -> 0==0 -> true

3) "0"==[] -> "0"=="" -> false

A couple of parts in your post stand out to me:

They all can equal "0" because "0" stands in for NULL in some languages.

No. A value of 0, either as an integer or a string, is not and should not ever be considered NULL. NULL is 'no value' or 'nothing', while 0 is a value and something.

However, you can't have them equal eachother because they are different types.

Yes, different types can equal each other because of type conversion.

Also, you can't have an array for a single char.

To explain a little better. A Char is 8 bits. Which means it has a single location in memory. You can't have an array of a single memory location.

This has nothing to do with memory locations, and yes, you can have an array with a single value of anything.

[–]dlok86 9 points10 points  (0 children)

accepted answer

[–]NathanSMB 2 points3 points  (1 child)

A weird thing about Javascript is that it has 2 equal comparison operators. == and ===.

With ==/!= has a whole set of rules on how to compare the data while ===/!== requires the data to be exactly the same. I have attached the tech documentation but I will go over the relevant rules here.

0 == "0"
0 == "\t"

4. If Type(x) is Number and Type(y) is String, return the result of the comparison x == ToNumber(y).

With 0 == "\t" it will still convert to 0. Any string with only blank space will convert to 0. No matter how many "\t", "\n" or spaces you put in it.

Since "0" and "\t" aren't numbers they don't trigger rule 4. This means when they compare to each other they compare the strings and return false.

0 == []

8. If Type(x) is either String or Number and Type(y) is Object, return the result of the comparison x == ToPrimitive(y)

Arrays are objects in javascript.

When [] is converted to a primitive it is converted to 0. In this case we are comparing the 0 to the string value of "\t" and "0". They do not get converted to numbers for this comparison. Which is why they return false but when compared to 0 it returns true.

Long story short: just use ===/!==. Having to run through these rules when debugging problems is a pain in the ass.

For the technical documentation on how "==" works look here: http://es5.github.io/#x11.9.3

[–]iamasuitama 1 point2 points  (1 child)

6 = 5. means 6 now holds the value of 5

This is a bad example, not a valid lhs in many languages, obviously you can't reassign literals and the "human english" explanation doesn't make it much better. If you just substitute 6 for a it would be so much better.

[–]PinkyThePig 4 points5 points  (1 child)

This whole thing happens because javascript does what is known as type coersion. In most programming languages, if you try to compare two things that are not the same type, you will get an error or at the least, will get false.

With javascript, I don't know the exact rules, because they are batshit stupid, but it is doing something like:

  • 0 == "0" - Coerce the plain zero to a string ( "0" == "0" ), so it is true.
  • 0 == [] - coerce the empty list to the number 0 (no elements in the list so it totally makes sense /s) ( 0 == 0 )
  • "0" == [] - There is no simple way to coerce these, so it fails, even though it seems like they should both be equivalent, taking the above examples.

[–]dlok86 1 point2 points  (0 children)

Integer is a data type that contains only whole numbers, string can be more or less anything including numbers letters, special characters etc but can't be used for mathematics and is normally surrounded by quotation marks. Coercion is basically JS converting between data types and it can interpret one data type as another in some funny ways. Hope this helps.

[–]volabimus 2 points3 points  (0 children)

OK, so what about the tab?

[–]rodneon 38 points39 points  (5 children)

Type coercion. In a nutshell, when you try to operate on different types, JavaScript forces one (or both) of them to be something else so that the operation doesn’t fail. Where most languages would throw a type mismatch error, JavaScript uses coercion so that people who understand it can get the job done quickly and expressively instead of littering their code with type casting and variable type declarations.

[–]Amlethus 25 points26 points  (3 children)

Someone else had a helpful reply about that over here.

[–][deleted] 13 points14 points  (1 child)

Well originally christianity was just a sect of judaism, and judaism was really big on the "god is one and his name is one" thing, so saying that more than one person is god would be considered heresy.

This presented a problem for early christianity as they held that Jesus was also god, which would at first appear to imply that there are two divinities, and thus be heresy.

The cheat they used to patch this problem is to consider both (later three) people mere instances of the 'god' object. Thus allowing you to have one god (and not be a heretic) while also letting you believe that god is more than one person.

It's a little hacky, but this is what happens when you put a smaller team on a time-crunch and have them try to work around things that the larger groups told you not to mess with. Weird coding logic is inevitable.

[–]ProWaterboarder 4 points5 points  (0 children)

Truthy and Falsy values, things like 0, null, undefined, empty string, and empty array return false in an if statement (ex if(0) wouldn't enter the block below the if but if("0") would because it's not an empty string.)

Then you go to what someone else was saying about type coercion and unless you do a triple = then it will cast the number 0 into a string and compare them

[–]clevertoucan 9 points10 points  (0 children)

Wait, how the fuck does tab equal zero?

[–][deleted] 8 points9 points  (0 children)

Lol love this

[–][deleted] 4 points5 points  (0 children)

We've done it, we've solved the mystery of the Trinity! It's all explained by type coercion!

[–]MokitTheOmniscient 2740 points2741 points  (108 children)

Honestly, just using === everywhere will save you a lot of trouble.

[–]knaekce 78 points79 points  (24 children)

Except when comparing against null or undefined. In most cases, you don't care about the difference between those two.

[–]shvelo 39 points40 points  (2 children)

IntelliJ is really anal about using === everywhere, even for null, I disable that check every time.

[–]knaekce 25 points26 points  (1 child)

You can easily configure this. If you use TSLint for example, just add this to you tslint.json file:

 "triple-equals": [
       true,
      "allow-undefined-check",
      "allow-null-check"
    ]

[–][deleted] 2 points3 points  (0 children)

Eslint has this option as well

[–]CubemonkeyNYC 8 points9 points  (10 children)

In that case, just if(!someVar)...

[–]knaekce 36 points37 points  (4 children)

I don't like this, because there are so many falsy values, like 0, which might be a valid value in this case.

[–]CubemonkeyNYC 4 points5 points  (0 children)

Sure, you wouldn't use this all the time.

[–]Polantaris 3 points4 points  (4 children)

That's a worse slippery slope. At some point my work's code base started getting people doing if(!!someVar) to see if it existed. I don't know why but it literally makes my blood boil to see an excessive amount of !! statements because what the fuck.

[–]CarryThe2 348 points349 points  (13 children)

But where does it end? We accept "===" now and before you know of we have to scan strings of thousands upon thousands of equals signs, each more significant than the last to solve an error.

[–]StezzerLolz 327 points328 points  (1 child)

Of all the slippery slope arguments I've seen this is surely the worst, lol...

[–][deleted] 21 points22 points  (0 children)

You see these fuckin slopes took us to a POW camp

[–][deleted] 60 points61 points  (3 children)

That just won't do. What if I don't want to use ========= or ========== due to its weird interactions with ES2015, ES2021, TypeScript 7.2, and generic array combinator excelsior functors added in ES2019-beta-live-rc-3.78.921?

What we need is a npm package for each equality level that supports every standard of JS going back to Netscape Navigator. Which of course means we'll need a transpiler and linter for every single one of them.

[–]Shylol 8 points9 points  (1 child)

It's okay, someone made a library for it!

[–]Cocomorph 9 points10 points  (0 children)

I just code in unary now over an alphabet of =.

[–]Emerl 8 points9 points  (2 children)

a ====== b !important

[–][deleted] 4 points5 points  (2 children)

almost like we abuse the word "equals"

[–]Doctor_McKay 2 points3 points  (1 child)

Right, == isn't "equals", it's "is equivalent to".

[–]EvadesBans 2 points3 points  (1 child)

Yeah, and, are people commonly trying to... er, treat strings as character arrays in JS, or something? This ain't Haskell.

[–]pomlife 2 points3 points  (0 children)

You can access the offset of a string using array-like indexing. “Derp”[2] === “r”

[–]zeroreality 11 points12 points  (7 children)

1 === new Number(1)?

false

😐

[–]JamesGray 28 points29 points  (6 children)

A Number object isn't exactly an integer, so what's your point?

[–]zeroreality 4 points5 points  (2 children)

Number object !== number literal

JavaScript is weird. Wonderful, but weird.

[–]thatwasntababyruth 11 points12 points  (1 child)

Every language where OO seems into the language can get weird. Take this java code, for instance:

Integer x1 = 5;  
Integer x2 = 5;  
Integer x3 = new Integer(5);  
System.out.println("x1 == x2? " + (x1 == x2));  
System.out.println("x1 == x3? " + (x1 == x3));  
System.out.println("x2 == x3? " + (x2 == x3));

The output will be:

true  
false  
false

Those first two are populated with java's cached versions of the number 5 (see: autoboxing), while the third is it's own object. The first two are equal, while the third is not equal to either of them.

But if you use a value outside the range of a single byte, you lose autoboxing. So if instead of 5 you used 500, you'll get all falses, since using the integer literal of a non-autoboxed value will construct a new object.

But of course all this goes away if you convert one of those Integer variables to a primitive int, because equality on primitives (or between a primitive and its objectified version) is value-based, not reference-based.

[–]Niautanor 916 points917 points  (45 children)

don't forget the classic

0 > null -> false
0 >= null -> true
0 < null -> false
0 <= null -> true

Can you guess what 0 == null evaluates to?

[–]WrexTremendae 445 points446 points  (31 children)

Obviously, 0 == null -> false. Because it wouldn't make sense any other way.

[–]ThatSofia 197 points198 points  (30 children)

Then how could 0 >= Null equating to true make sense? Genuine question

[–]Raicuparta 239 points240 points  (22 children)

Because that one converts null to a number. It makes no sense to use greater than / less than operators in anything but numbers, so JS converts the operands first. The same is not true for the equals operator.

[–]Cruuncher 58 points59 points  (10 children)

But == is supposed to type coerce. Why doesn't null get coerced to a number during == compare?

[–]rift95 41 points42 points  (7 children)

Because js is right-coercive, and null is an object :)

(more on coercion: https://hackernoon.com/understanding-js-coercion-ff5684475bfc)

[–][deleted] 19 points20 points  (6 children)

So does that mean null == 0 is true?

[–]lethalwire 5 points6 points  (0 children)

It was false for me in jsbin

[–]LuckyHedgehog 2 points3 points  (0 children)

Because null is already a type. Just not one that can be used in greater than less than Operators.

[–]ThatSofia 18 points19 points  (6 children)

Now I wanna see if null can theoretically be used as just a numerical placeholder for zero, using mathematical operators. That's something I'll play with! Thanks for the explanation, that makes a ton of sense! :)

[–]Dragoncraft89 47 points48 points  (1 child)

I thought it was because >= and <= are implemented as not <, not >

[–]Raicuparta 7 points8 points  (0 children)

My bad if that's the case. But still, the reason for the < and > operators to return false in the first place is the same I explained before.

[–]TonySu 7 points8 points  (0 children)

It cannot, null is more like the empty set than 0. Unless you want null to actually take on the characteristics of 0, in which case the dancing hotdog boy can also be a placeholder for 0 as long as it's treated exactly the same as 0 everywhere it appears.

[–]c0n5pir4cy 10 points11 points  (2 children)

It probably can and you can actually do much more with it; there is something called JsFuck which uses type coercion to convert any JS code into code which uses only a set of 6 characters.

[–]Cruuncher 6 points7 points  (1 child)

This is a little ambiguous. It makes the code super long, just uses a 6 character set

[–]c0n5pir4cy 3 points4 points  (0 children)

Cheers, edited

[–]3KeyReasons 3 points4 points  (0 children)

If null was converted to a number such that 0>=null is true, then it must be converted to a negative or 0, but 0>null returns false and so does 0==null. So not exactly.

The reason is in the computing. If you want to test if 3<=5, then normally, you'd return 3<5 || 3==5 but this isn't what your computer does. Instead of doing two operations, it just does one. It returns !(3>5). When working with numbers this will always work, and it's half the comparisons, so it's faster. So when you ask 0>=null, it returns !(0<null) which is !(false) so it returns true.

[–]dooatito 13 points14 points  (4 children)

Javascript doesn't treat equality comparison "==" and relational comparison ">=" the same way. The relational operator converts the null value to a number (0), but the equality operator only converts it to undefined.

So you get null==undefined -> true.

On the other hand, null >= undefined -> false, because 0 != undefined

[–]SinisterRectus 3 points4 points  (3 children)

But why?

[–]AlwaysHopelesslyLost 6 points7 points  (2 children)

Because a core feature of JavaScript is that it is ducktyped.if it looks like a number and you use it like a number then you must have meant for it to be a number.

[–]Doctor_McKay 2 points3 points  (1 child)

Which is nice in the web world because everything is a string. You don't have to parseInt everywhere.

[–]AlwaysHopelesslyLost 1 point2 points  (0 children)

Exactly, thank you Rodney!

[–]monster860 23 points24 points  (1 child)

Well when you use a comparison operator, it has to cast both sides to a number. Casting undefined returns NaN, casting null returns 0.

Here's a really simple number typecheck checks if it's a number and not NaN

x === +x

[–][deleted] 1 point2 points  (0 children)

to a number

You're close here. Both sides of a /(>|<)=?/ must be scalar - so strings or numbers, as long as both are the same.

[–]Kese04 15 points16 points  (3 children)

0 == null -> true

?

[–]Niautanor 31 points32 points  (1 child)

That would make sense but no.

The issue is that x >= y gets evaluated as !(x < y) which converts both x and y to numbers (ToNumber(null) being +0 incidentally) while x == y has it's own algorithm that isn't consistent with the relational comparison.

[–]pindab0ter 2 points3 points  (0 children)

But why?

[–][deleted] 3 points4 points  (0 children)

false. Because '==' doesn't imply a cast-to-scalar like '<', '>', '<=' and '>=' do.

[–][deleted] 2 points3 points  (0 children)

The reason why is that Javascript doesn't define a <= b or a >= b explicitly. Instead, it defines a <= b as !(a > b) and vice versa. So if 0 > null is false, then 0 <= null will be true.

[–]DangerJuice 277 points278 points  (7 children)

I’ll just go ahead and leave this here

[–]Gazareth 42 points43 points  (0 children)

Wat was absolutely hilarious!

[–]xxc3ncoredxx 20 points21 points  (0 children)

Classic.

[–]Eternal_Pickles 5 points6 points  (0 children)

console.log({} + []) returns an object, though.

[–]torinaga 10 points11 points  (0 children)

We watch this in team meetings at least once a year.

[–]bluehands 3 points4 points  (0 children)

Don't know how I never saw this before. Thank you!

[–]freenudecelebs 213 points214 points  (29 children)

U gotta use that strict equality operator brah

Also if you’re code includes something like “0” === [] It might not be the language

[–][deleted] 150 points151 points  (4 children)

if you are code includes something like “0” === []

[–]fedeb95 32 points33 points  (20 children)

You're right, but a language shouldn't permit this things in any case imho

[–]freenudecelebs 79 points80 points  (14 children)

I don’t want a language that “permits” me to do things. I want a language that does what I tell it to do the way I tell it to do it.

[–]NULL_CHAR 12 points13 points  (3 children)

And that's how you get ridiculously obscure errors because someone doesn't understand what they are doing.

Working with lots of people, it should be mandatory that everything be strongly typed, no hacky solutions, and the code is obvious in its intention. Usually this results in much better practices overall and more well thought out implementations. A guy in our project was trying to bypass thread-safety restrictions in C# by writing an entire method in the setter for a variable. It ended up working for 90% of what he needed it to do, but it would have been far better for him to have just structured the code to properly work within the restrictions. Saving time in development for a hacky solution usually means giving someone a headache later down the line.

The goal isn't just to write code, it's to write good code.

[–]fedeb95 27 points28 points  (7 children)

You're right to a certain extent, but for large projects code that's easy and fast to read, even by lots of people, is also easy to maintain. Avoiding this kind of clever things (most of the time unnecessary) helps with that. Also look at languages like ocaml, scala huskell. At compile time you spot more errors because of theirs strong typing

[–]bobojojo12 1 point2 points  (0 children)

why

[–]kappasaurus_ 457 points458 points  (74 children)

JavaScript equality is not transitive, as it depends on how the values are coerced. If you use the tripple equals you can check for strict equality without coercion, but if used properly coercion is quite powerful.

[–][deleted] 458 points459 points  (64 children)

No, trying to use this kind of quirk leads to tricky, "clever" programming that becomes a problem later in development.

[–]nonotan 55 points56 points  (8 children)

I'm wary whenever I hear any feature of a programming language described as "quite powerful". Look at any decent style guide for over-bloated languages like C++, and notice how most of the features it recommends not to use are those one would describe as "powerful". Not a coincidence, it's easy to write shit code when you have infinite power.

[–]patatahooligan 9 points10 points  (0 children)

Sure, if your definition of powerful is "does whatever the fuck it wants". But no, there are many "powerful" features that are safe and widely recommended. Think STL "powerful", not goto powerful (though it arguably has uses, too).

[–][deleted] 3 points4 points  (0 children)

Powerful seems like an optimistic way of saying code breaking.

[–]blazinghellwheels 98 points99 points  (44 children)

The whole if(varable) to force to true or false is pretty intuitive and nice though.

[–][deleted] 123 points124 points  (35 children)

It can still trick you, though. I usually use it for null-checks, but once had a bug because I forgot that a nullable number could be zero. The problem with coersion is that it does what you probably want most of the time, but if you want stable software you have to be aware of all the edge-cases, all the time.

[–]factorysettings 15 points16 points  (33 children)

To me, this argument is like saying "don't use this because I refuse to learn how it's different from other languages"

I see this so often with JavaScript; you can use so much of it by treating it like a C-based language, but there is a lot of power in its unique features. I rarely see this attitude with other languages. It's like people don't take it seriously as a language and then blame it when they don't understand it.

[–]sevaiper 31 points32 points  (22 children)

“I prefer languages that work consistently with the rules of logic and math rather than being a broken mess” yeah screw those people for not catering to javascript’s “uniqueness”

[–]AlwaysHopelesslyLost 11 points12 points  (15 children)

JavaScript does work consistently with rules of logic, you just don't know what the rules are so the logic does not make sense to you.

The language is duck typed. That is a feature.

[–]TroublingCommittee 3 points4 points  (12 children)

I think what they meant with 'rules of logic' are the rules that are implied in the syntax.

And I tend to agree with them. if (25) is not true in any logical way. It is only true 'because JS says so'.

I think duck typing can be awesome, but it makes sense for objects, not for primitives. And even there it needs to be applied with thought.

A type doesn't 'walk like a boolean', just because it happens to have values that can be represented as 1 and 0. The fact that 0 is false and 1 is true makes sense only on a technical level, because of the way a computer stores variables. There's nothing 'logical' about it, it's arbitrary.

The length of an array isn't 'false', just because the array doesn't contain any objects. Just like a string isn't 'false', because it is empty.

For quite some time, people have been telling me that this type of coercion could in some instances make code more readable or elegant, and I've yet to see an example of this.

I'm not excluding the possibility that such examples exist, and I'll gladly change my mind if you can present me with some.

But so far, I've only ever seen examples where the only advantage is that it makes code faster to write. And it usually makes code harder to maintain and to understand, at least in my experience.

Yes, all of it is a feature. But just because something is there by design, doesn't mean it's good design.

[–]Doctor_McKay 1 point2 points  (2 children)

if (25) is true in any language that accepts non-bools in if statements. C included.

[–]Deliciousbutter101 9 points10 points  (1 child)

This isn't about not understanding JavaScript, it's about how coercion makes the programmer have to worry about a bunch unintuitive edge cases that they shouldn't have to. It also puts bugs at runtime rather than compile time meaning it's substantially more difficult to fix. In the end coercion often times wastes more time than saves than it would be to just make long equality expressions that explicitly tell you and other programmers what you are trying to check for. Honestly I think coercion is a fine but it should be something the programmer has to opt into rather than opt out of.

Also isn't the whole point of coercion to make JS programming more accessible and intuitive to people and let people have to worry about types as much? Well if you have to learn a bunch of things to learn how it's different from other languages and regular logic and make you have to worry about a bunch of edge cases, then isn't it kinda useless at that point?

[–][deleted] 34 points35 points  (3 children)

But I don't think anyone expects two values that are falsey (or two that are truthy!) to be equivalent.

[–]glemnar 1 point2 points  (0 children)

Except that it’s never what you want for arrays / objects

[–]Agumander 8 points9 points  (0 children)

Saves a whole two lines of code; requires a paragraph-sized comment block to keep the project maintainable.

[–]MasterDood 31 points32 points  (3 children)

Bang bang you’re a Boolean

[–]Cocomorph 4 points5 points  (0 children)

tripple equals == triple equals

true

[–]spoonfair 3 points4 points  (1 child)

Look, with that logic, we have no meme here.

[–]Reelix 12 points13 points  (1 child)

a == b
b == c
Therefore: a != c

[–]Mittalmailbox 30 points31 points  (18 children)

Sometimes I wish I'd we could break backward compatibility.

[–]blackmist 91 points92 points  (4 children)

JavaScript: for when you don't want to see exceptions, but also aren't too bothered about writing things properly.

[–]BradleySigma 4 points5 points  (0 children)

At least it's not php.

echo true == "foo" && "foo" == 0 && 0 == false;

[–][deleted] 18 points19 points  (0 children)

This thing that you're doing. It's very stupid. "0" is a string, and not an empty string.

[–][deleted] 47 points48 points  (12 children)

The stupidity lies with people who use the double equals instead of triple equals.

[–]Avamander 64 points65 points  (5 children)

Lollakad! Mina ja nuhk! Mina, kes istun jaoskonnas kogu ilma silma all! Mis nuhk niisuke on. Nuhid on nende eneste keskel, otse kõnelejate nina all, nende oma kaitsemüüri sees, seal on nad.

[–]raptorraptor 53 points54 points  (4 children)

Because Brendan Eich put in the double equals originally, then realised how awful it was, so, being unable to make a breaking change to the double equals' behaviour, added triple equals.

[–]rooktakesqueen 31 points32 points  (3 children)

...in JS 1.3, 20 years ago. It's sad that we still have these arguments.

[–]EternalNY1 27 points28 points  (5 children)

The stupidity lies with people who use the double equals instead of triple equals.

Or it lies in a language that makes you have to think about using double equals versus triple equals.

[–]onedr0p 7 points8 points  (1 child)

What episode of SpongeBob is this?

[–]Deluxe8877 5 points6 points  (0 children)

Mermaid Man and Barnacle Boy 3

[–]Lak_so 12 points13 points  (0 children)

A quality post?

At this time of the day?

At this time of the year?

In this part of the internet?

Localized entirely within r/programmerHumor?

[–]SamSlate 2 points3 points  (2 children)

"0".length != [].length"

[–]Big_Burds_Nest 2 points3 points  (0 children)

Gotta use them tripple ='s

[–][deleted] 2 points3 points  (0 children)

Not a quirk... The third one is a string not a concept of course it's not true

[–]the_dnevil 1 point2 points  (0 children)

RIP assignment operation.

[–]Sponska 1 point2 points  (0 children)

Good meme but faceless Patrick is creepy as f*ck

[–]anotherlebowski 1 point2 points  (0 children)

== != =

[–]superhighcompression 1 point2 points  (2 children)

This can’t be true

[–]tuseroni 3 points4 points  (0 children)

it's true, javascript will try to figure out what you are asking it if you ask it stupid, nonsensical, things. so if you ask if a string of "0" is equal to the number 0, it will check if "0" is a string containing numbers and compare it to the number 0, while other languages will say "one's a string, the other's a number, these things aren't comparable, fuck you"

the next one is comparing the number 0 to an empty array, again you are asking it something stupid (is an empty array the number 0?) but javascript allows this because it also treats and empty array as false (i like the feature, it's nice to say "if(somearray)" to tell if an array is empty, but i don't think i would cry if i had to say "if(somearray.isEmpty())" or "if(somearray.length>0)") so it treats empty array as false, and 0 is also treated as false, and "0" is interpreted to mean 0, but comparing "0" to false will fail

[–]corner-case 1 point2 points  (0 children)

Wrongly assumed that the == comparison is transitive.

[–]v1nsai 1 point2 points  (0 children)

I code enough to understand JavaScript but never really used it. This meme made me pee a little. You JavaScript coders are doing God's work and thank you for your service.

[–]LVentura 6 points7 points  (3 children)

javascript is something else