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.

I think it is rather bad semantics actually.

You always have the option to use

    Number(x) + Number(y)
    (+x) + (+y)
    String(x) + String(y)

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.

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.

These kinds of things are one of the reasons why I really don't like the idea of everything (including server-side and standalone apps) being written in JavaScript.

So for instance:

    var arr1 = [1,2,3], arr2 = [1,2,3,4];
    console.log(arr1 + arr2); // "1,2,31,2,3,4"
    arr1.valueOf = function () { return this.length; };
    arr2.valueOf = arr1.valueOf;
    console.log(arr1 + arr2); // 7

and a duckduckgo tip

    !cache http://blog.caplin.com/2012/01/27/the-why-of-wat/

http://webcache.googleusercontent.com/search?q=cache:http://...

JavaScript without type coercion would have been safer and saner in my opinion.

Compare with:

> UNIX was not designed to stop its users from doing stupid things, as that would also stop them from doing clever things. — Doug Gwyn

--

†except that you can generate NullPtrException in the pointerless Java. Ask yourself, WAT?

For example, string concatenation could have been handled by a separate operator.

A dull blade on a round onion is not safer than a sharp blade on that onion. Running your hand across a dull blade is safer than running your hand against a sharp blade.

Javascript in a nutshell.

Unbounded strings have much more complex and potentially less optimal semantics than bounded strings, need to be allocated in different ways, etc. C makes tight resource control possible, and to do that it sacrifices a lot of ease. You have to think about resources when programming. In many scenarios, this is a good thing.

I'm not a C programmer (yet), but I would say that depends on what you define as "easy" or "simple". What I am is an Arch Linux user, and I embrace KISS - Keep It Simple, Stupid. Arch understands "simple" as "technically elegant and uncomplicated", but that doesn't mean it's easy to understand or foolproof to use - for the inexperienced user, that is. C is an incredibly powerful tool exactly because it is this kind of simple.

What I also am is someone who learned programming with Python, and I initially couldn't understand the appeal of C-oid languages either. But I've since realized it's all about using the right tool for the job. A programmer is a mechanic, and a mechanic that only knows how to use a hammer is a pretty useless mechanic (in general, of course. If all you deal with are nails then it's not an impediment to your abilities).

But I agree we need various tools to cover the necessary ground.

Why do you feel the need to think about the variable's type on every line though? Since they're typed, you should pretty much know exactly what they are, instead of trying to figure it out. Since they're not dynamic, they're never changing.

So i need to stop and think how can i input a variable from user, which function should i use. I was just defending js. I don't oppose C, i am just saying its about perspective. C is as much crazy to me as is JS to some other people. this does not make C evil.

- 004412......... and 4412..... are completely different things. You care also about how you annotate base of integers, because anything starting with "0" might be an 8-base integer.

- Even if we assumed local numbers don't start with 0, there are some places where such number doesn't fit into an integer. 32b int is only 10 digits in dec base.

So yes - whether it's C or JS you should very much care what the actual type is. This isn't very theoretic either. Some time ago, twitter started using id which were larger than 32b fields. Even though people should've been treating those ids simply as opaque strings, some used integers, leading to twitter client update panic.

Again using phones example:

country + area + ending

is different depending on what the actual types are. This is simply an issue we cannot ignore. In this case I'm expecting the concatenation and the result cannot depend on "contents of the string".

It's not laughable. Most implementations of JS and PHP are probably written in C or C++. While using dynamically allocated strings in higher level languages like these are indeed easier than null terminated strings in C, at some point someone somewhere had to write code at a lower level to support this.

Yes that is something i totally agree with. In fact that's why i only supported js and not hate c. Because somewhere it has to be done and c is efficient in dealing with memory allocations whereas js deals with front-end mechanics. But to say that js is 'crazy' is something beyond me. every language has its ways and it depends on what 'level' (high, low, machine) that language works in computer hierarchy.

Comparing high level language like js to lower level language (like c++, java, etc) on their syntax or how it deals with objects/arrays makes no sense.

Does anyone have a mirror?

`+` in this context is the "Unary + Operator" which coerces a value to a number via the internal `toNumber` method of the operand.

It doesn't make the number positive:

    node> +-1 // -1

0. Is only marginally useful 1. You have to be careful with what are you loading, and where 2. Will sooner or later blow up in your face