> ... he pokes fun at some apparently crazy behaviours in Ruby and Javascript.
I am sorry, but that still is crazy behavior. You can excuse it with a historical perspective ("well it had to hide errors from users") or by explaining "the why" like you do, that still doesn't make that behavior less crazy.
Not trying to defend the craziness, but, when you are trying to do []+{} and "foo"-1, you can kinda expect unexpected results if you know that JS does type coercion.
That is not the problem here. The problem is that this might by the code piece "x + y" where x and y is in your scope and happens to be [] and {}. The resulting value is then highly confusing to a programmer. A language that enforces explicit type conversion (some call these strongly typed languages) would not allow this, but require you to write something like "string(x) + string(y)" if you really wanted such behaviour.
"I can't imagine a single situation where you expect variables used in a sum operation to be arrays/objects."
That's precisely the problem. You don't expect them, but there's nothing to prevent it from happening, so it does.
Your proposed solutions don't solve the problem, they occur too late. By the time you're adding together two non-numbers (and non-strings) you've already lost, trying desperately to cast them to numbers first is also wrong, along with so verbose that nobody will ever do it.
Comments
> ... he pokes fun at some apparently crazy behaviours in Ruby and Javascript.
I am sorry, but that still is crazy behavior. You can excuse it with a historical perspective ("well it had to hide errors from users") or by explaining "the why" like you do, that still doesn't make that behavior less crazy.
Every single point in that article made complete sense, and yet it left me feeling even more convinced of Javascript's insanity.
Not trying to defend the craziness, but, when you are trying to do []+{} and "foo"-1, you can kinda expect unexpected results if you know that JS does type coercion.
That is not the problem here. The problem is that this might by the code piece "x + y" where x and y is in your scope and happens to be [] and {}. The resulting value is then highly confusing to a programmer. A language that enforces explicit type conversion (some call these strongly typed languages) would not allow this, but require you to write something like "string(x) + string(y)" if you really wanted such behaviour.
I think it is rather bad semantics actually.
I can't imagine a single situation where you expect variables used in a sum operation to be arrays/objects. That would be highly confusing.
You always have the option to use
"I can't imagine a single situation where you expect variables used in a sum operation to be arrays/objects."
That's precisely the problem. You don't expect them, but there's nothing to prevent it from happening, so it does.
Your proposed solutions don't solve the problem, they occur too late. By the time you're adding together two non-numbers (and non-strings) you've already lost, trying desperately to cast them to numbers first is also wrong, along with so verbose that nobody will ever do it.
Yeah, that was stupid.
What I mean though is I can't imagine code that gives chance for this to happen. Putting an array where a number should be is a very visible mistake.