Wikipedia has a good page on this subject. In a nutshell, "strong/weak" typing is not formally defined. Usually languages are called weakly typed when they allow a lot of implicit type coercion or just don't strictly enforce types. It's not at all unique to dynamically typed languages. C is pretty weakly typed, for example. And a static language could just as easily have a quirk like this JavaScript thing.
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.
While the phrases don’t seem to have strict definitions, by the Wikipedia description of Strong Typing ,there is an overlap with Static Typing:
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.
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.
The thing is in a weakly typed language you can implement functions that do coercion, while a strongly typed language will not let you as generally there is a fixed type (or type class) to each parameter. That does not mean the standard built in or library functions have to do javascript levels of coercion though, I think there are better balances.
Comments
Wikipedia has a good page on this subject. In a nutshell, "strong/weak" typing is not formally defined. Usually languages are called weakly typed when they allow a lot of implicit type coercion or just don't strictly enforce types. It's not at all unique to dynamically typed languages. C is pretty weakly typed, for example. And a static language could just as easily have a quirk like this JavaScript thing.
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.
While the phrases don’t seem to have strict definitions, by the Wikipedia description of Strong Typing ,there is an overlap with Static Typing:
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.
The thing is in a weakly typed language you can implement functions that do coercion, while a strongly typed language will not let you as generally there is a fixed type (or type class) to each parameter. That does not mean the standard built in or library functions have to do javascript levels of coercion though, I think there are better balances.
I wrote an article where I tried to lay out the definitions of these terms: http://alexgaynor.net/2010/nov/19/programming-languages-term...