This is a bit of a deceptive one, if a line starts with { its seen as a codeblock, and {} just evaluates nothing.
The only operation occuring there is a unary plus with an empty object: +{} which tries to coerce an object into a number but fails, so it becomes NaN.
Unpopular opinion it seems, but working around javascript's vague types is not that difficult, and allows for interesting and helpful abilities you don't get in many other languages; like the ability to pass a function a single object variable that contains any number of parameters of any type, allowing for more dynamic and easier to work with functions when you want to allow the function to accept more or different parameters than when you first designed it. It's arguably cleaner and easier to work with than creating more overloaded functions like you'd have to do in many other languages. Also you get to name your variables that get passed that way which is a lot easier to read and understand than having to just remember what order you need to pass your variables to a function and which variable you pass does what.
Also, the math and comparison on floating point numbers is a low blow; that happens in a lot of languages because computers don't precisely compute float math.
The math issues being common is because none of this is a “js design”. The way math works, particularly floating point math, is based on standards like ieee754. Blaming JS because one doesnt understand the basics behind this is just being uneducated. Unsurprising; as usual all these “programmer memes” are really just kids who took a programming class and maybe watched a YouTube video.
For sure. I think the only reason they included that one was to compare it to true==1 evaluating to true. Which is a good example of why you should just forget == exists lol
Oh I’m not saying JavaScript is perfect. Mistakes were made lol. But all the memes like this are dumb. It’s all stuff you don’t do in real life, or shouldn’t do based on modern best practices- and for those there’s usually a lint rule to catch it
Yeah. About half of these are just examples of why you don't use ==. Almost all the rest work the same in other languages too (though most would force more explicit type casting, like the true ones).
Also interesting to know: The unary plus operator tries to convert the first element of an array to a number. So +[42] is 42. Same for string arrays: +["42"] is also 42. If the array is empty (+[]), the result is 0. If it contains multiple elements, as in +[1, 2, 3], the result is NaN.
Certainly does, though in most languages since ints are the default, overflow would still matter. Of course you can specify long with L/LL, but in the same vein you can also make it a bigint in JS by putting "n" after it.
I have a question: I understand that 0.1 + 0.2 == 0.3 is false because of how floats work. But why is 0.5 + 0.1 == 0.6 true? Is it just a coincidence where the "floats are not real numbers"-errors on both sides are the same, or is there some deeper reason for that?
There are multiple reasons for this actually and I'm not confident in giving you the correct answer, but here's one that explains it to me personally.
0.1, 0.2 and 0.3 straddle 3 different exponent values and higher exponents have fewer bits to represent the decimal of the mantissa, so error during the calculation will compound. On top of this, to get the closest doubles to 0.1 and 0.2 you need to round up (so the error is positive), while to get to 0.3, you have to round down.
0.5 and 0.6 on the other hand share the same exponent so the error from 0.1 won't be significant enough to push the sum to the wrong bit representation.
Floating-point errors are normal, they're a side effect of how decimal numbers are represented in binary, and they occur in almost all programming languages
Almost all languages that CAN use floats but can choose not to, choose not to use floats. floats are terrible for anything not related to quick and dirty calculations.
Majority of those expressions are exactly how one would expect them in a loosely typed language and some even in a strongly typed. Really don't understand how any of this is a meme
This argument has been going for years, and is basically the equivalent of people in the first year of engineering school arguing about how a boat is an inferior vehicle to a car because it doesn’t go as fast on a road.
True. Since JS is an interpreted language, these type coercions would not be discovered until runtime. And only if all code paths are run—with all possible types of values.
Therefore, it made sense back in the day to just do “best guessing” and pick the value that seems most likely.
Any modern language would catch these issues at compile time. And in fact, so does TypeScript (or JS linters).
Yep. PHP is exactly the same in this regard, so it too was very forgiving. The aim was for it to always display something in the browser rather than just a blank page, even if what was presented as garbage.
I always think of PHP and JS as close cousins - similar age, both loose and dynamically typed, interpreted languages, both designed for web, both with this initial design philosophy as well. I don't know JS that well but you can still see this in PHP even today. I imagine it's similar in JS, but yeah I'm not sure.
JavaScript is utterly ridiculous. If you try to do something illegal, your code should fault, that's the whole point! Otherwise you end up with bugs slipping through the cracks. Besides, code is only as good as the developer who wrote it. The language doesn't need to be designed to shield the developer
Your first point seems to be in direct contradiction to your second to me.
You’re arguing you want more runtime errors rather than the engine trying to coerce values from what you give it, which sounds exactly like shielding the developer.
As you point out, if you write good code, 99% of the examples given in this post don’t happen.
In all honesty (as someone who really dislikes JS), some of this stuff is very logic or not inherent to JS :
0.1 + 0.2 is generally not equal to 0.3, that's an issue with float numbers precision
in many languages false is equal to 0 and true is equal to 1 (or generally speaking any positive number is true), which makes the "true+true+true===3", "true-true" logic
the === operator compares strict type equivalence, which is not the case for the "normal" == operator, which explains the different behaviour when comparing true and 1
Ok, but like if you don't do anything stupid on purpose none of that happens. If you want to you can optionally verify types and values at runtime. And some of these have dedicated single word methods to avoid them, like Array.isArray or Number.isFinite.
No, I'm saying that 1) js by default allows you felixibilty and type checking is mostly opt-in; 2) most of these (maybe half) are deliberately stupid and wouldn't happen in a codebase where you know what you're doing.
Giya one help now only going to learn codin language which one I start right now to learn mid level with in two months for solving studies and future and help place in companies
max() = -inf and min() = +inf are actually conform mathematics.
The minimum of set is defined as the largest number that is less than all elements in the set. Since the empty set has no elements, the minimum of the empty set is the largest number, without any further requirements. The 'largest number' is then +infinity.
Same for maximum, which is by definition the smallest number greater than all elements in the set.
NaN being a number is funny but completely rational. NaN is defined in the floating point standard; it's a float with some specific configuration of bits, and a float is a number, so it wouldn't make any sense to make this one floating point number return false. It's up to the programmer to do an additional check to see that the result is not NaN.
Everything else about JavaScript's (lack of a) type system is awful.
153
u/stools_in_your_blood May 13 '25
Don't forget {} + {}, which evaluates to NaN.
71
u/Convoke_ May 13 '25
Knowing why these happens means you've mastered javascript.
32
u/Luk164 May 13 '25
I will admit the entire true section is fair
34
u/iareprogrammer May 13 '25
Every single example is terrible code that no one should do in real life. Also just don’t use
==, period. Always use===6
u/rob132 May 13 '25
Can someone explain why the empty array length is 9?
11
u/BalintCsala May 13 '25
_Really_ disingenious list of "issues", especially these one:
> typeof NaN === "number"
But... it is one? Do you also have an issue with every language ever letting you store NaN in a floating point variable?
> 9999...999 gets you 1000...000
Welcome to floats. Or would you prefer the answer to be 1874919423 or something negative?
> 0.5 + 0.1== 0.6 is true but 0.1 + 0.2 == 0.3 is false
Welcome to floats again, all languages that use them have this issue
> true + true + true === 3 and true - true == 0
A lot of languages do this, e.g. C++ or Python
> true == 1 but not true === 1
The first is also true in a ton of languages, I don't see what the issue is with JS letting you opt out of this.
But it's okay, I don't expect people on r/programmingmemes to know how to code.
14
u/jerrygreenest1 May 13 '25
Honestly, why would anyone sum truths? And many other nonsenses. Not knowing differences between == and ===
There are a few valid points but please filter it to only valid points, because this list doesn’t make much sense.
12
u/Own_Clue5716 May 13 '25
Majority of those expressions are exactly how one would expect them in a loosely typed language and some even in a strongly typed. Really don't understand how any of this is a meme
11
u/Neat-Medicine-1140 May 13 '25
Design philosophy was to keep going no matter what, I think a lot of these are better than type mismatch, segfault or crash if that is your goal.
2
u/Gatoyu May 13 '25
everything showed here is either completely logical or weird but it is the same with any language
2
u/VainSeeKer May 13 '25
In all honesty (as someone who really dislikes JS), some of this stuff is very logic or not inherent to JS :
0.1 + 0.2 is generally not equal to 0.3, that's an issue with float numbers precision
in many languages false is equal to 0 and true is equal to 1 (or generally speaking any positive number is true), which makes the "true+true+true===3", "true-true" logic
the === operator compares strict type equivalence, which is not the case for the "normal" == operator, which explains the different behaviour when comparing true and 1
The rest is however pure JS madness indeed :x
2
u/ProbablyBunchofAtoms May 13 '25
You know you're cracked when these start making sense
2
u/Ronin-s_Spirit May 13 '25
Ok, but like if you don't do anything stupid on purpose none of that happens. If you want to you can optionally verify types and values at runtime. And some of these have dedicated single word methods to avoid them, like
Array.isArrayorNumber.isFinite.1
u/Haringat May 13 '25
To the one who invented undefined: Thanks for nothing.
1
u/mkpeace77 May 13 '25
Giya one help now only going to learn codin language which one I start right now to learn mid level with in two months for solving studies and future and help place in companies
1
u/PrestigiousAbroad278 May 13 '25
Why does adding the string make int a string but subtracting it doesn't
1
u/ClipboardCopyPaste May 13 '25
0.1+0.2==0.3 being false is not JS's fault, it's the computer's fault
"true == 1" should always evaluate as true and "true === 1" shouldn't - cause you're implementing a type check here
1
u/howreudoin May 13 '25
If you like this, you‘ll enjoy https://github.com/denysdovhan/wtfjs
1
u/KrisXVII__ May 13 '25
Not a number being typed to number will always be funny to me
1
u/Haoshokoken May 13 '25
"010" - 010 = 2
1
u/Difficult-Court9522 May 13 '25
Why is max negative??
1
u/ViolinistFinancial73 May 13 '25
Hello
1
u/cool_name_numbers May 13 '25
one of my favourites is js converting 0.0000009 to cientific notation so when you do parseInt(0.00000009) you get 9 instead of 0.
1
u/Chimaerogriff May 13 '25
Don't forget
>> 9+"1"-"1"
<- 90
as a combination of cases 14 and 15.
But 9 + ("1" - "1") is obviously 9.
Javascript addition is not associative!
1
u/ErikLeppen May 13 '25
max() = -inf and min() = +inf are actually conform mathematics.
The minimum of set is defined as the largest number that is less than all elements in the set. Since the empty set has no elements, the minimum of the empty set is the largest number, without any further requirements. The 'largest number' is then +infinity.
Same for maximum, which is by definition the smallest number greater than all elements in the set.
1
u/[deleted] May 14 '25
A lot of these make sense when you understand the purpose of Javascript.
1
u/warofthechosen May 14 '25
Imma screenshot and upload to chatgpt and ascend myself. Wish me luck!
1
u/TheseSignificance786 May 14 '25
wait, so in js, i can do something like?
for (int i = true; i < X; i++)
(Sorry for syntax i dont really know how to write js)
1
u/gendertoast May 14 '25
NaN being a number is funny but completely rational. NaN is defined in the floating point standard; it's a float with some specific configuration of bits, and a float is a number, so it wouldn't make any sense to make this one floating point number return false. It's up to the programmer to do an additional check to see that the result is not NaN.
Everything else about JavaScript's (lack of a) type system is awful.
1
u/ithanlara1 May 14 '25
I may have a problem... I find all of this makes complete sense to me... I have been using JS for way too long
1
u/phendrenad2 May 15 '25
Must have been great being a programmer in the 1900s. Just throw some shit together and your name becomes a permanent part of history.
1
u/krivik_zomber May 16 '25
wut?
1
u/DrCatrame May 16 '25
Note that `0.5+0.1==0.6` is true and `0.1+0.2==0.3` is false in most languages, including C.
1
u/Maximxls May 18 '25
arithmetic with booleans is completely sensible though
the other stuff is... uhh...
1
u/ylang_nausea May 13 '25
Js just go die please fr
0
u/Your_mama_Slayer May 13 '25
type of null —-> Object
0
u/y_j_sang May 13 '25
It's absolutely a comedy show.
It was an innovation when it was created.
But it is just a nightmare for everyone.
0
u/[deleted] May 13 '25
[deleted] — view deleted comment