"Without automatic testing dynamic languages are not very productive because they do not catch type mismatch errors during compilation time (there isn't one). With statically typed languages you get a lot of tiny issues taken care of once you hit magic "compile" button and compiler does some basic sanity checks."
You're just exhibiting a basic dislike of dynamic languages. Type mismatch errors are mostly orthogonal to testing.
"Without solid unit tests backing you, activities like removing "obsolete" methods or renaming classes/modules turn into nightmare with duck typed languages."
This is a nightmare regardless of typing. If you remove a method that is still used somewhere, you've broken something, and you may not spot it until after it ships to customers. It doesn't matter whether you have type checks or not. A compiled language that links in those classes and methods at compile time does resolve this issue, but it's not related to types (and you have to wait on the bloody thing to compile every time you change one character in the file). Testing does resolve this problem--but it's not a problem specific to dynamic languages.
If you get a warm fuzzy feeling from type checking from your compiler, then by all means, enjoy it. But there are tools for most mature dynamic languages (Perl and Python for example) that will do that checking without having to write tests manually. But, having never found type errors to be a problem in my Perl or Python code, I've never used them. Some problem sets are more prone to type mismatch bugs than others, and I guess my areas of interest are among the ones that are rarely effected.
You say that type mismatch errors are orthogonal to testing. This may be the case in languages like Java, which has a strong but not very expressive type system. In strongly typed functional programming languages like ML and Haskell, though, you can, with a bit of good design, capture a lot of information about what you want your program to do in the type system, to be checked automatically. Take, for example, the comment on this page by somebody who says that the only testing s/he does is XHTML validation. With strongly typed functional programming, it is possible, and not really even all that hard, to write an embedded combinator library for XHTML such that programs that generate improper XHTML don't type check in the first place.
A compiled language that links in those classes and methods at compile time does resolve this issue, but it's not related to types (and you have to wait on the bloody thing to compile every time you change one character in the file).
How is it not related to the compile-time name resolution and type checking? In a compiled typed language, you would get a compile or link error if the symbol is not found. I regularly write and refactor C++ by inducing compile or link errors to identify the spots in the code where a specific method is called from.
"How is it not related to the compile-time name resolution and type checking?"
Please re-read, carefully. I said that compiled and strongly typed are two orthogonal language characteristics, and that each of those characteristics solves one set of problems (while introducing some of its own).
I specifically said exactly what you've said about compiled languages identifying missing methods. But it's not because it is a strongly typed language, it's because it is compiled.
What's so bad about having a little clarity in our use of terms and concepts?
A bit of semantics: what we are talking about here is the difference between statically typed and dynamically typed languages, not strongly and weakly typed. Python is strongly dynamically typed. Java is strongly statically typed. C is (arguably) weakly statically typed (because it let's you treat anything as anything through casts, void pointers, etc).
The point jey was trying to make is that only languages that are both statically typed and compiled can catch missing methods. Consider for example a piece of code:
a.doB();
If the language is not statically typed, then the compiler does not know the type of "a" at compile time, and therefore doesn't know what class to check for method "doB". This is why even if you were to compile python you would still end up getting missing method error messages occasionally.
You're just exhibiting a basic dislike of dynamic languages. Type mismatch errors are mostly orthogonal to testing.
"Without solid unit tests backing you, activities like removing "obsolete" methods or renaming classes/modules turn into nightmare with duck typed languages."
This is a nightmare regardless of typing. If you remove a method that is still used somewhere, you've broken something, and you may not spot it until after it ships to customers. It doesn't matter whether you have type checks or not. A compiled language that links in those classes and methods at compile time does resolve this issue, but it's not related to types (and you have to wait on the bloody thing to compile every time you change one character in the file). Testing does resolve this problem--but it's not a problem specific to dynamic languages.
If you get a warm fuzzy feeling from type checking from your compiler, then by all means, enjoy it. But there are tools for most mature dynamic languages (Perl and Python for example) that will do that checking without having to write tests manually. But, having never found type errors to be a problem in my Perl or Python code, I've never used them. Some problem sets are more prone to type mismatch bugs than others, and I guess my areas of interest are among the ones that are rarely effected.