JavaScript
-
This post did not contain any content.
That is just the tip of the iceberg:
-
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.
-
Lol. In a dynamically typed language? I will do this always, that's why I am using it
You can have a dynamic language that is strongly typed to disallow stuff like this. Like Python for example
-
You can have a dynamic language that is strongly typed to disallow stuff like this. Like Python for example
Aand what is your point?
-
This is fair enough from an idealistic view. In practice, you don't want your entire website to shit itself because of a potentially insignificant error.
I'd rather have my website shit itself than have silent difficult to find errors.
-
That is just the tip of the iceberg:
F#? What? We can't curse on the internet? Self censorship at dictator levels here. /s
-
Well then, rage against the machine for the next 30 years and see if they kill it in favor of a nice, strict language that everybody loves. Maybe you could suggest one here for consideration.
So, all you've mustered is some lame-ass whataboutism?
Have a good day -
This is fair enough from an idealistic view. In practice, you don't want your entire website to shit itself because of a potentially insignificant error.
Look! I bought this for free on capybaras website, there's a glitch!
capybara: at least it didn't throw an error.
/ jk
-
This post did not contain any content.
Obligatory link to wat? video
-
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.
I don't think there's a way to retrofit JS - but php versions are deprecated all the time. Why not do the same with client-side script versions?
-
That is just the tip of the iceberg:
Oh wow, that's upsetting
-
It's not nonsensical, implicit type coercion is a feature of JavaScript, it's perfectly logical and predictable.
JavaScript is a filthy beast, it's not the right tool for every job, but it's not nonsensical.
When you follow a string with a
+, it concatenates it with the next value (converted to string if needed). This makes sense, and it's a very standard convention in most languages.Applying arithmetic to a string would be nonsensical, which they don't do.
You are entitled to your opinion. implicit conversion to string is not a feature in most languages for good reasons.
-
That is just the tip of the iceberg:
Not just javascript: https://www.destroyallsoftware.com/talks/wat
-
That is just the tip of the iceberg:
Ugh, like... I get why it outputs like that, but I also absolutely hate that it outputs like that.
-
If you try what I wrote it will throw a NaN. I was asking about the first part of the proposal.
The NaN isn't an thrown. It's just silently put into the result. And in this case it's completely unintelligible. Why would an operation between two strings result in a number?
"Hello" - "world"is an obvious programmer mistake. The interpreter knows that this is not something anyone will ever do on purpose, so it should not silently handle it.The main problem here is downward coercion. Coercion should only go towards the more permissive type, never towards the more restrictive type.
Coercing a number to a string makes sense, because each number has a representation as a string, so
"hello" + 1makes intuitive sense.Coercing a string to a number makes no sense, because not every string has a representation as a number (in fact, most strings don't).
"hello" - 1makes no sense at all. So converting a string to a number should be done by an explicit cast or a conversion function. Using-with a string should always result in a thrown error/exception. -
That is absolutely
(n > 1) * ("ba" + 0/0 + "a")(n > 1) * ("ba" + 0/0 + "a")
Uncaught ReferenceError: n is not defined
?
-
That's the case in many languages, pretty much in all that don't have a separate string concatenation operator.
Yeah, and almost all languages I know then would throw an exception when you try to use
-with a string, and if they offer multiple operators that take a string and a number, they always only perform string operations with that and never cast to a number type to do math operations with it.(e.g. some languages have
+for string concatenation and*to add the same string X time together, so e.g."ab" * 2 => "abab". It's a terrible idea to have+perform a string operation and-performs a math operation.) -
Yeah, and almost all languages I know then would throw an exception when you try to use
-with a string, and if they offer multiple operators that take a string and a number, they always only perform string operations with that and never cast to a number type to do math operations with it.(e.g. some languages have
+for string concatenation and*to add the same string X time together, so e.g."ab" * 2 => "abab". It's a terrible idea to have+perform a string operation and-performs a math operation.)Sure, but then your issue is with type coercion, not operator overloading.
-
Sure, but then your issue is with type coercion, not operator overloading.
Because there's in fact no operator overloading happening, true, but that's mostly an under-the-hood topic.
It should not happen no matter why it does happen under the hood.
Operator overloading for
string - stringis wrong and type coercion to implicitly cast this toint(string) - int(string)is just as wrong. -
Because there's in fact no operator overloading happening, true, but that's mostly an under-the-hood topic.
It should not happen no matter why it does happen under the hood.
Operator overloading for
string - stringis wrong and type coercion to implicitly cast this toint(string) - int(string)is just as wrong.wrote on last edited by [email protected]There is operator overloading happening - the
+operator has a different meaning depending on the types involved. Your issue however seems to be with the type coercion, not the operator overloading.It should not happen no matter why it does happen under the hood.
If you don't want it to happen either use a different language, or ensure you don't run into this case (e.g. by using Typescript). It's an unfortunate fact that this does happen, and it will never be removed due to backwards compatibility.
