Hm, playing devil’s advocate, I think it is because the minus has not been defined as a string operation (e.g. it could pop the last char), so it defaults to the mathematical operation and converts both inputs into ints.
The first is assumed to be a concat because one of the parcels is a string…
It’s just doing a lot of stuff for you that it shouldn’t be in first place 🤭
Given it’s JavaScript, which was expressly designed to carry on regardless, I could see an argument for it returning NaN, (or silently doing what Perl does, like I mention in a different comment) but then there’d have to be an entirely different way of concatenating strings.
I’m surprised they didn’t borrow OnErrorResumeNextfrom Visual Basic. Which was wrongly considered to be the worst thing in Visual Basic - when the real worst thing was OnErrorResume. OnErrorResumeNext at least moved on to the next line of code when an error occurred; OnErrorResume just executed the error-generating line again … and again … and again … and again …
You’re right. I’ve got too much Perl on the brain and forgot my roots. There is a language that does what you’re talking about with the ‘+’ operator: BASIC
Good luck getting the same thing retrofitted into JavaScript though. I can imagine a large number of websites would break or develop mysterious problems if this (mis)behaviour was fixed.
It is ‘comprehensible’ in the sense that it’s possible to figure out how it happened, but it absolutely does not “make sense” in terms of being a reasonable language design decision. It’s 100% incompetence on the part of the person who created Javascript.
It makes perfect sense if the Lang objective is to fail as little as possible. It picks the left side object, checks if the operand is a valid operand of the type. If it is, it casts the right variable into that type and perform the operand. If it isn’t, it reverses operand positions and tries again.
The issue here is more the fact that + is used both as addition and as concatenation with different data types. Well, not an issue, just some people will complain.
Computing a nonsensical result is itself a failure. Continuing to run while avoiding giving an error in that case accomplishes nothing but to make the program harder to debug.
Perl is an old but notable exception. + is purely for addition in the base language.
If you try to add two strings with it, they’ll be converted to numbers based on any number-like characters they have at their left hand ends, and, if warnings are enabled (and you should definitely do that), you’ll get runtime warnings about it if there’s even anything vaguely non-numeric about them.
e.g. “1”+“11” will get you 12 with no complaint, warnings or otherwise. Not even the string “12” either, although it’s hard to determine one from the other in Perl. It’s a need-to-know kind of thing. And you generally don’t.
“a”+“bb” gives 0 as the result because they’re not numbers and “1a”+“11bb” will give 12, but these latter two will give warnings. Two each, in fact, one for each dodgy parameter.
String concatenation is done with the dot operator instead. “1”.“11” gives “111”. This comes with it’s own minor problems, but at least + is safe.
That’s because Perl doesn’t do operator overloading in general. Even the equality operator is different for strings (eq instead of ==). As a language, it may look pretty weird and lack some modern features, but the underlying design is surprisingly intelligent and consistent in many ways.
Perl’s default bitwise operators do differentiate between numbers and strings that look like numbers in a way that addition doesn’t*, and the readline/glob operator <> does different things depending on what (if anything) is between the signs.
There’s also the whole overload pragma for objects, which doesn’t affect default data types, but if you’re sufficiently perverse, you can define a String class that uses ‘+’ like JavaScript.
* in 2015, they added new operators so that those and the original operators don’t overload and have only one specific purpose if the bitwisepragma Edit: feature is turned on. You might know all this already though.
This is too stupid so I had to check.
Fuck me.
Hm, playing devil’s advocate, I think it is because the minus has not been defined as a string operation (e.g. it could pop the last char), so it defaults to the mathematical operation and converts both inputs into ints.
The first is assumed to be a concat because one of the parcels is a string…
It’s just doing a lot of stuff for you that it shouldn’t be in first place 🤭
Yup. It’s completely inconsistent in its interpretation of the + operator.
Yeah, I actually had to try 1+“11” to check that it didn’t give me 12, but thankfully
it commutesit’s consistent 😇Maybe the behaviour with regard to type conversion, but not for the operation itself.
“13”+12 and 12+“13” don’t yield the same result.
Nor would I expect “1312” to equal “1213”… Still that operator with these operands should just throw an exception
Given it’s JavaScript, which was expressly designed to carry on regardless, I could see an argument for it returning NaN, (or silently doing what Perl does, like I mention in a different comment) but then there’d have to be an entirely different way of concatenating strings.
I’m surprised they didn’t borrow
On Error Resume Nextfrom Visual Basic. Which was wrongly considered to be the worst thing in Visual Basic - when the real worst thing wasOn Error Resume.On Error Resume Nextat least moved on to the next line of code when an error occurred;On Error Resumejust executed the error-generating line again … and again … and again … and again …Why would you need an entirely different way of concatenating strings? “11” + 1 -> exception. “11” + to_string(1) = “111”
You’re right. I’ve got too much Perl on the brain and forgot my roots. There is a language that does what you’re talking about with the ‘+’ operator: BASIC
Good luck getting the same thing retrofitted into JavaScript though. I can imagine a large number of websites would break or develop mysterious problems if this (mis)behaviour was fixed.
Yeah, this looks dumb on the surface, but you’ve got bigger problems if you’re trying to do math with strings
Better than doing physics with strings
Kinda like log4j!
From all the Javascript quiks this is the least stupid and the most obvious.
pro tip:
"ba" + 0/0 + "a"This has got to be baNaNa
That is absolutely
(n > 1) * ("ba" + 0/0 + "a")Uncaught ReferenceError: n is not defined
?
🫣
Unfortunately, it makes sense if you know what + means, which is concatenate. - is strictly a math function though.
Not saying that makes this better. It just makes sense.
It is ‘comprehensible’ in the sense that it’s possible to figure out how it happened, but it absolutely does not “make sense” in terms of being a reasonable language design decision. It’s 100% incompetence on the part of the person who created Javascript.
I mean, I’d never try to do this anyway because if the types aren’t the same unexpected things can happen. That’s like programming 101.
Exactly, which is why designing the language to allow it is incompetence.
Fair enough.
It makes perfect sense if the Lang objective is to fail as little as possible. It picks the left side object, checks if the operand is a valid operand of the type. If it is, it casts the right variable into that type and perform the operand. If it isn’t, it reverses operand positions and tries again.
The issue here is more the fact that + is used both as addition and as concatenation with different data types. Well, not an issue, just some people will complain.
Computing a nonsensical result is itself a failure. Continuing to run while avoiding giving an error in that case accomplishes nothing but to make the program harder to debug.
Thanks for saving me the typing.
It’s an issue with most if not all languages that aren’t strongly typed.
Perl is an old but notable exception. + is purely for addition in the base language.
If you try to add two strings with it, they’ll be converted to numbers based on any number-like characters they have at their left hand ends, and, if warnings are enabled (and you should definitely do that), you’ll get runtime warnings about it if there’s even anything vaguely non-numeric about them.
e.g. “1”+“11” will get you 12 with no complaint, warnings or otherwise. Not even the string “12” either, although it’s hard to determine one from the other in Perl. It’s a need-to-know kind of thing. And you generally don’t.
“a”+“bb” gives 0 as the result because they’re not numbers and “1a”+“11bb” will give 12, but these latter two will give warnings. Two each, in fact, one for each dodgy parameter.
String concatenation is done with the dot operator instead. “1”.“11” gives “111”. This comes with it’s own minor problems, but at least + is safe.
That’s because Perl doesn’t do operator overloading in general. Even the equality operator is different for strings (
eqinstead of==). As a language, it may look pretty weird and lack some modern features, but the underlying design is surprisingly intelligent and consistent in many ways.Not strictly true.
Perl’s default bitwise operators do differentiate between numbers and strings that look like numbers in a way that addition doesn’t*, and the readline/glob operator
<>does different things depending on what (if anything) is between the signs.There’s also the whole
overloadpragma for objects, which doesn’t affect default data types, but if you’re sufficiently perverse, you can define a String class that uses ‘+’ like JavaScript.* in 2015, they added new operators so that those and the original operators don’t overload and have only one specific purpose if the
bitwisepragmaEdit: feature is turned on. You might know all this already though.I think I’m on the side of “if you do this in your code, you deserve what you get.”