JavaScript is not confusing. It's confusing for people who didn't read specification, don't understand type coersions and how weak typing works, don't understand closures, etc. Then, of course, you can give an example of:
0=="0"0==""""!="0"
But actually there is nothing confusing here. JavaScript uses number coersion when comparing things of different types, but "" and "0" are both strings so JavaScript just compares them straightway.
It might be daunting to know those things, but it's certainly not confusing when you know them!
Furthermore, you shouldn't even use code like that in production in the first place.
Talking about this weirdness:
{[{}]:10}["[object Object]"]
It does make sense. JavaScript is not a human language, it's a programming languge with strict rules and syntax and, in my opinion, a developer should think in those rules. Here you create a new object defining ES6 computed property as an empty object. In JavaScript object keys can only be strings, so the method toString() is being called on {} which by default produces [object Object] string. So basically you are doing this:
Again, the fact that it's possible to write code like this doesn't mean you should do it. But it is great to understand how the language works! So it shouldn't be confusing for a developer.
Of course, that's just my opinion on that. I love JavaScript ❤️
UPD: I actually got inspired by this thread and wrote a little guide about JS type conversions:
As I mention, all of these behaviors have fairly concise explanations. However, having to know dozens of bizarre edge-cases that do come up in real code reduces the space you have in your head for thinking about the important problems in front of you (and instead you have to spend time thinking about language trivia).
These complexities are not inherent to implicit type coercion, dynamic typing, closures, etc. Lua has all of these things, and none of the gotchas that JavaScript has.
For example, in Lua, tables are simply mappings from objects to keys. == is the same thing as what determines if two keys map to the same value (so, e.g., {[{}] = true} actually does do what it says it does; 1 == "1" is false, t[1] isn't the same thing as t["1"]; but you can write 1 + "1" == 2 yet 1 .. "1" == "11").
The fact is, that many of JavaScript's complexities/gotchas/points of confusion are unnecessary. The fact that they can be overcome is secondary to the fact that you have to overcome them: if JavaScript were designed slightly differently, you would not have to worry about them (and this can in most cases be done without sacrificing any linguistic power and convenience)
The actually confusing part here is trying to understand, why did they even design a language this way, and why people still insist on using it.
Weak typing does not necessarily mandate type coersion. There's a lot of dynamically typed languages that make sense, that did not opt out for insane rules.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
JavaScript is not confusing. It's confusing for people who didn't read specification, don't understand type coersions and how weak typing works, don't understand closures, etc. Then, of course, you can give an example of:
But actually there is nothing confusing here. JavaScript uses number coersion when comparing things of different types, but "" and "0" are both strings so JavaScript just compares them straightway.
It might be daunting to know those things, but it's certainly not confusing when you know them!
Furthermore, you shouldn't even use code like that in production in the first place.
Talking about this weirdness:
It does make sense. JavaScript is not a human language, it's a programming languge with strict rules and syntax and, in my opinion, a developer should think in those rules. Here you create a new object defining ES6 computed property as an empty object. In JavaScript object keys can only be strings, so the method toString() is being called on {} which by default produces [object Object] string. So basically you are doing this:
Again, the fact that it's possible to write code like this doesn't mean you should do it. But it is great to understand how the language works! So it shouldn't be confusing for a developer.
Of course, that's just my opinion on that. I love JavaScript ❤️
UPD: I actually got inspired by this thread and wrote a little guide about JS type conversions:
Understanding JavaScript type conversions
Anton Melnyk ・ Aug 31 ・ 4 min read
As I mention, all of these behaviors have fairly concise explanations. However, having to know dozens of bizarre edge-cases that do come up in real code reduces the space you have in your head for thinking about the important problems in front of you (and instead you have to spend time thinking about language trivia).
These complexities are not inherent to implicit type coercion, dynamic typing, closures, etc. Lua has all of these things, and none of the gotchas that JavaScript has.
For example, in Lua, tables are simply mappings from objects to keys.
==is the same thing as what determines if two keys map to the same value (so, e.g.,{[{}] = true}actually does do what it says it does;1 == "1"is false,t[1]isn't the same thing ast["1"]; but you can write1 + "1" == 2yet1 .. "1" == "11").The fact is, that many of JavaScript's complexities/gotchas/points of confusion are unnecessary. The fact that they can be overcome is secondary to the fact that you have to overcome them: if JavaScript were designed slightly differently, you would not have to worry about them (and this can in most cases be done without sacrificing any linguistic power and convenience)
The actually confusing part here is trying to understand, why did they even design a language this way, and why people still insist on using it.
Weak typing does not necessarily mandate type coersion. There's a lot of dynamically typed languages that make sense, that did not opt out for insane rules.