"10"+20+30 is "102030"
10+"20"+30 is "102030"
But ...
10+20+"30" is "3030"

One must love JavaScript

@Kushtrim and in a decent language (even decent dynamic ones like python) that shit simply isn't allowed.

Classic example of why untyped languages suck. You need to always use parseInt if you want to treat a numeric string as an integer and ""+ if you want to concatenate integers as strings.

This is one of the few times JS actually makes sense. I would expect that output.
But there are cases where JS does random shit

@danielspaniol Yeah, like when a string suddenly read out as "undefined" although it was actually null.

@danielspaniol Of course, output is quite expected. But, still ...

This makes total sense... order of operations is left to right. For the first addition, if the first or second operand is a string, then they are both converted to string and appended. Once that is resolved, the same is repeated to the second addition operation

"10" + 20 + 30 -> "1020" + 30 -> "102030";

10 + "20" + 30 -> "1020" + 30 -> "102030";

10 + 20 + "30" -> 30 + "30" -> "3030";

"10" + ( 20 + 30 ) -> "10" + 50 -> "1050";

easy peasy

@demiko except it is consistent

@demiko it's very intuitive. Left to right, just like order of operations. If there is a string it converts, otherwise it adds. Pretty simple!

Last example does make sense to me, the other ones on the other hands..

I don't mind weak types and polymorphism, but + as a concatenation operator is weird. You can't sum strings, you concatenate them.

If you think that it is ok for a language to give a different result for a + b + c than from c + b + a then you must have slept through math in school.

@demiko meh. There's a difference between intuitive and enforcement. Intuitive means you can reason about it and follow the logic without crazy jumps like "it'll always do this unless it's Sunday the 12th, then it does this". Simple, easy to follow rules are fine.
I'd rather having many ways of doing something then only having one "javascriptic" way like Python had "pythonic". No need to be so prescriptive.

@ItsNotMyFault this isn't a math expression if there is a string. An operator can have multiple uses.

It's logical, intuitive and useful. Just because you're used to different things doesn't mean that change is wrong. It works, it makes sense, why should I hate it?

I dig it. But unfortunately dealing with type bullshit in other languages has forced me to think in a different way.

@SoulSkrix The way I see it, its prone to errors.

@theuser only if you don't pay attention to what you're doing.

@AlexDeLarge +1 for functional here. The more generic the more composable and the more useful things can be.

@SoulSkrix when you replace the string literals with variables the fact that reordering the arguments can change the result can become non obvious. (Unless you use retarded variable prefixes) and in a large codebase managed by multiple developers that is a very bad thing.

When the data come from user supplied json it becomes a pain "count": "5" instead of "count": 5 and things get very funny (adding a bunch of boilerplate typechecks or explicit casts is not fun or productive).

Basically it is bad language design that only exists because fixing it would break old shitcode.

@ItsNotMyFault nah, it's lazy user who isn't making sure their data isn't in the form they expect. If you want numbers, you best be sure you're giving it numbers. Simple enough concept

@SoulSkrix Then someone wil make a mistake, stuff will fuck up and it ends up costing a lot of money.

This has noting to do with if a language is dynamicly typed or not.

This is also true in Java or c#.

In c# the + operator is defined for an string and an object, and calls the tostring method on the object to create the string. This can also be done in the earlier c# versions where dynamic didn't exist yet.

But about this example, this sounds very counter intuitive, but how many times do you have such an real life example. Most of the time I do something like this "the number is" + a, where a is an integer. Then this result is completely intuitive in my eyes.

I never understood why the dot is necessary. Most of the time the language simple add an operator while that is not necessary and not needed to understand the code.

that'll teach you how obtrusive and unnecessary strict typing is

I dont get why people blame the language if they write bad code. If you know what you are doing you dont need the language to keep track of your errors

Yeah your right, one need to know what he's doing otherwise it's a real mess..

It makes sense, but why the fuck would you use this code to achieve any of the results?

This actually makes perfect sense

Makes total sense.
Also this silly joke is being overused too much.

Use Joi and quit whining, its not the fault of JS but imbecile devs.

@nicholai Even non-imbecile developers make mistakes. Those who claim they never do are usually the worst.

Naturally

@Kushtrim Kotlin is statically typed which makes operator overloading less of an issue.

Its really only a problem in weakly typed dynamic languages(due to the implicit type conversions), most of which will use a separate operator for string concatenation for that very reason.

@AlexDeLarge I think you're bang on about typed vs untyped, though I think template strings are the way forward for concatenation.

I agree, at least it makes sense.

Even if js sometimes it has no sense I find it way better than Java

Java is the platform of software and the java script is the forum of making the help of component digestion with the attitude of plus. The article has the end point in the making of link in https://thebestessayservice.com/dis... for Java script version.