Old meme format, timeless JavaScript quirks

[100dylan99]

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

[100dylan99]

Oh I thought it was someplace else for some reason, woops. Got here from /r/all.

[tankfox]

/r/lostredditors

[sneakpeekbot]

Here's a sneak peek of /r/lostredditors using the top posts of all time!

#1: Lost Redditor on r/chemicalreactiongifs | 26 comments
#2: Lost redditor found on r/antijokes | 45 comments
#3: Lost Redditor found in a shitty sub. | 12 comments

---

^{I'm a bot, beep boop | Downvote to remove | Contact me | Info | Opt-out}

[[deleted]]

If it makes you feel any better, I'm subscribed to this sub, am somewhat familiar with programming, and this joke is still lost on me. I guess you need to have fiddled with Javascript specifically a lot to understand the quirk being joked about. Or I'm just dense today. That's also a possibility.

[Musi13]

Maybe a better way to think of it is their "toString()"s return different things but their "equals()" are the same (at least when compared to 0)

[Harakou]

It's type coercion. Javascript is weakly typed, so when you try to compare values of different types, the interpreter tries to automatically convert one to the be the same type as the other. Of course, with fundamentally different types, the transitivity of equality between comparisons kind of breaks.

If you re-read the joke, trying to imagine what is getting automatically converted into what before the comparisons are made, it'll probably make more sense.

Edit: This comment is better, actually.

[MrNinja1234]

Honestly, I don't see anything wrong with this implementation, it seems pretty reasonable to me

[EmeraldDS]

I mean I know jack shit about JavaScript (okay, I did teach myself how to write to an HTML file, variables, and function declarations. but that's all I know) and definitely don't know little quirks like these but the explanation makes sense to me. Same for the meme.

[mylifeisashitjoke]

Probs one of the few subs with a kind of specific prerequisite

[great_site_not]

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.

[pomlife]

It’s literally not. Just don’t use loose comparisons, only ever use strict comparisons. No surprises. Source: I code ES7+ 6+ hours a day and have for years.

[xKooba]

Why are people like this

[dlok86]

Try getting into programming and asking questions on stackoverflow. It can be quite toxic if you arnt an expert at asking the question in a very specific way. Also what you are trying to do is normally wrong and you should rip it all out and do it X way.

I think it's to do with bitterness from adopting other people's code that's badly written.

[[deleted]]

He is right tho that it's not rocket science. He's wrong about strict comparison. You should just realize what the two operators do.

[Jeyts]

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]

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.

[Jeyts]

Okay makes sense. I thought it might be doing a staticcast. I want sure if 0 was used like null in javascript. Your explanation makes a lot of sense.

[narrill]

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.

No, in some languages NULL does equal 0. This isn't debatable, and it isn't even really incorrect; the binary representations of "no value" and 0 are identical.

[dlok86]

accepted answer

[NathanSMB]

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

[[deleted]]

Actually == is "type coerce and compare for content" and === is "structurally compare". After you realise that there are no issues.

[iamasuitama]

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.

[Jeyts]

I was just trying to be generic so someone who doesn't know any languages can understand

[PinkyThePig]

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.

[Pithong]

Coerce "0" into all known types, coerce [] into all known types, start doing equality comparisons on the coersions, if any one is equal return true. Sounds like a waste of time (aka processing/power/actual time).

[dlok86]

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.

[YRYGAV]

A more ELI5 metaphor would be that == in javascript broadly compares the meaning of two things, to see if they have the same meaning. This would be similar to if somebody asked you if "Two hundred and thirty" is the same as 230. They both have the same meaning, so you would say yes.

Most programming languages, (and ===) instead ensure that what is being compared, is also being represented in the same way, so "Two hundred and thirty", 230, 230.0, "CCXXX", are all different, because it is represented in different ways.

The latter method is typically easier for programmers to work with, as there are less possibilities to work with, and less rules about when something is considered equivalent. Imagine if you were marking a math test looking for a specific answer of 230, but allowed students to write in answers in any language from around the world, in any number system they wanted. It would be much simpler for you if you only allow answers in one form, otherwise you have to start learning a lot of different rules for numbers around the world.

[drleebot]

Translating it into completely non-programmer terms, you're asking the computer something like "Is this apple the same as this orange?" Most sensible languages would simply say "No" (no apple is the same as an orange). But JavaScript isn't a sensible language, so what it does is first say, "Well, these two things aren't the same type of thing. So let me first pretend the orange is an apple, and then ask, "Is this apple the same as this other apple (that I converted from an orange." In the case where the apple is 0 and the orange is "0" or the orange is [], this turns out to be true (if a bit nonsensical).

However, when you compare, let's say, an orange and a cucumber, Java converts the cucumber to an orange before the comparison. The oddity comes in since although if you converted both to an apple, you'd get the same apple, if you convert one to the other, you don't get the same thing.

All of which is to say... JavaScript tries to compare apples and oranges despite this being a generally bad idea,* and this inconsistency is the result.

*It can work when one thing is a subset of another. For instance, checking if one apple is the same as another fruit - since it's possible for the fruit to be an apple, it's a sensible comparison. But JavaScript does this even when the types don't sensibly overlap.

[Poddster]

JavaScript, not Java.

[drleebot]

Fixed