But what we have here is an expression where entities are being implicitly converted into intermediate values, along with operators that do different things based on the values they are given. For example, the behaviour of the “+” infix operator in JavaScript could be replicated in any strongly typed language that has pattern matching:

  x:string + y:string -> concat(x,y)
  x:stringable + y:string -> concat(toString(x), y)
  x:string + y:stringable -> concat(x, toString(y))
  x:numeric + y:numeric -> sum(x,y)
  ...

Back in the day when I wrote C++ (by gaslight, after I rode my penny farthing to the office), any one-argument constructor was presumed to be an implicit conversion unless you provided the “explicit” keyword.

UPDATE (and thanks to the hacker who pointed me in this direction):

http://en.wikipedia.org/wiki/Strong_typing

It seems that the expression “Strong typing” subsumes both the concept of static typing (variables and/or values do not change their types) and of coercion. (Along with other issues such as whether programmers can deliberately evade restrictions).

If I were to rewrite my question, I would ask if this is a strong typing problem overall or just the subset of strong typing issues concerning coercion?

So part of the issue with this code is implicit coercion, which is not “strong typing,” but the other is polymorphic operators like “+”, which are independent of strong vs. weak typing.

http://en.wikipedia.org/wiki/Weak_typing

Update to your update:

Strong typing does not subsume static typing. Ruby, for example, is dynamic and quite strongly typed. You can't bypass the type system at all, and the only real coercion is to boolean, which follows a very simple rule.

The mandatory requirement, by a language definition, of compile-time checks for type constraint violations. That is, the compiler ensures that operations only occur on operand types that are valid for the operation. However, that is also the definition of static typing, leading some experts to state: "Static typing is often confused with StrongTyping”...

Fixed and invariable typing of data objects. The type of a given data object does not vary over that object's lifetime. For example, class instances may not have their class altered.

http://en.wikipedia.org/wiki/Strong_typing

I guess this is one of those things where the correct response to any claim about “Strong,” “Static,” “Weak,” or “Dynamic” typing is to ask the speaker what, specifically, he is thinking of.

In this case, you and I are exploring the subject in some depth, but the person who originally used the phrase “Strongly Typed” is silent, so neither of us has any idea what he had in mind.

http://blog.steveklabnik.com/posts/2010-07-17-what-to-know-b...

Most people are not trained to notice these kinds of problems, or the simple checks that can stop them from confusing a list of lists and a list of lists of lists. But if you take a step back and think hard about what's happening to your time, you'll find that many hours are sunk chasing problems that are, in many ways, simple. Having static checks is like always having someone to read code over your shoulder.

If you're more productive in JavaScript, it's probably not because you can write a function that converts either an string or an integer to an array2. More likely, it's because you don't need to manufacture a new class every time you want a one-line handler.

Right which was my point in my other post where I said I just don't run into it that much. It is rare that we run into situations where we have to do tricky stuff with the type system. If we do we usually hide it behind a well tested API so that it is isolated and reusable. It's just not the problem domain that we solve for (most of the time) in web and mobile development. As such for my work flow the type safety of a languadge, does not factor in all that much. At least until I hit the middleware layer then I tend to use Java, but much of that decision is out of comfort and volume of libraries available.

Maybe you've created a button that puts some text in an element, but, in some rare cases, due to other events on the page, that element doesn't exist. The user clicks the button, document.getElementById returns null, and a nice error message pops out.

In JavaScript, you might discover this after a lot of testing. In DynXML, you would never be able to make that bug in the first place -- you'd get a type error.

(JavaScript has the advantage, though, of not being vaporware. As the low-paid undergraduate doing the implementation work on DynXML, this is my fault.)

Remember, being able to write a function that converts either a string or an integer to an array is exactly the kind of thing that dynamically typed languages let you do that statically-typed languages don't. If you're not doing that kind of thing, you're better off with a statically-typed language (when available).

Moreover, despite being a strongly-ish typed language, C++ has pretty ridiculous implicit conversion semantics, only statically rather than dynamically.

I agree that 'magic code' and obfuscation is pretty much ego stroking, but this doesn't seem like a good argument against the whole idea of using weakly typed languages.

A bad craftsman always blames their tools.

And sometime smart people tend to think they're invincible/bullet-proof. Not too many people have high-level discipline. And those that have high-level discipline tend to be shunned by "hackers" because "hackers" hate "processes". They just want to write fun code.

Hence the circle of evil.