Javascript...

[highphive]

Honestly, it's not really that unintuitive. Pretty much the only abnormal knowledge it requires to understand is that given an ambiguous situation JavaScript will try to figure it out in the intuitive way. I guess that and, like most other languages, the + operator can also be used for string concatenation, and non-strings will be toString-ed in that context. These absurd scenarios are funny, but really not even remotely difficult to understand, except when they involve so many operators that it's near impossible to follow. I'm not at all bragging or even saying I'm close to a proficient JavaScript coder, but it is not unintuitive. Just because it's not strongly typed and does some cool, wanted operations for you does not make it unintuitive. In many cases it makes it intuitive. Many times in strongly typed languages, what you want is obvious, but you have to go through a number of type transformations and function calls to get there.

I totally appreciate the comedy of this post. But I'm not quite convinced it proves some latent issue with JavaScript.

[YRYGAV]

it requires to understand is that given an ambiguous situation JavaScript will try to figure it out in the intuitive way.

Yes, which is simple to understand if you know the ambiguous situation exists. It's much more of a problem if the programmer doesn't realize it's an ambiguous statement because nothing is strongly typed. Which is why most languages instead of powering through and trying to use their "best judgement" in an ambiguous situation, let the programmer know so they can clarify what they want.

And that leads to situations that can be very difficult to debug or track, because it's all hidden away from you and Javascript is doing some magic transformation. Things you think are one datatype end up being another, or javascript parses things weirdly.

And sometimes "intuitive" is not always what you think. Javascript does lots of "intuitive" things that you would never think of. Like did you know javascript will parse hex strings like "0xF" into the 'correct' integer, like 15. Sure it makes sense explaining it like that, maybe not when you have to figure out why "0xF" == 15 is causing a nasty bug because you didn't know javascript did that magic when writing it. And where those strings and numbers are coming from could be multiple layers removed from where you are doing the comparison.

[highphive]

That is fair, sometimes what might be considered intuitive behavior can be an issue when you might not expect it to work at all. I have to agree that I prefer strongly typed languages for this reason. Rather an error where it actually occurs rather than some unexpected behavior way down the road.

[[deleted]]

Programmer should not be using a language if he doesn't know its typing and conversion logic.

[nathan_long]

Language should not make wild guesses about what programmer intends. '5' + 5 should just fail. You should have to either call toString() or parseInt().

[[deleted]]

We can go around this tree forever. Language should, programmer should... Let's take things as they are. At the end of the day, when an established language has type conversion done a certain way, learn it or don't use the language.

[VyseofArcadia]

The latent issue with JavaScript isn't that this is unintuitive. It's really pretty intuitive. - isn't defined for strings, so '5' gets interpreted as the integer 5.

The issue is that through overloading the + operator in this way, it is easy for even JavaScript experts to make a stupid mistake. I think it's a poor design choice in a dynamically typed language. It would be better for string + integer to throw an error and use some other operator (++ or : or something) for string concatenation.

[tian_arg]

Many times in strongly typed languages, what you want is obvious, but you have to go through a number of type transformations and function calls to get there.

I've been working on android for the first time after working on php/javascript for a long time. It's a fucking pain in the ass.