What it comes down to is that Haskell's type system eliminates whole categories of bugs because of the language. Having the correct way to use the language outside of the language itself, as an addition, in the case of Python or Ruby or (insert interpreted language here) makes for lots of extra debugging time.
When you use a programming language, you use its ecosystem. Haskell has its own tools and norms outside "the language itself" which I am obligated to take advantage of. If I develop software in Haskell, but completely ignore these tools, and make complaints which have DIRECTLY to do with my non-use of available facilities, I do not then have the right to say that Haskell is broken and objectively worse than language X. It does not follow.
Writing unit tests is not hard. Nor is it rare or exceptional. Wrestling Haskell's type system is not necessarily easy. Overall, making programs do the right thing is a big problem in any language, including Haskell, and one hopes that any system of significant size is being tested properly whether it uses a static type system or not.
The use of a type system is not in itself an objective slam dunk for Haskell over Python or anything else.
Have you coded in haskell? Really, the great-grandfather post that provoked this wasn't an attack on python, it's pointing out a difference between the type systems in ML, haskell, scala, and maybe typed racket, of the non-dependently type languages vs. all others.
I use Python + Pyramid daily; and I love it. However, I love Haskell more. Yesod/Snap/Happstack have quite a ways to go before they are on-par community and feature wise with Pyramid/Django/Rails/etc... but it's mature enough for production use.
With a little extra learning curve; it beats the pants off of Python + Pyramid + unit tests and lots of extra debugging time.
When you are spending a significant amount of time telling the type system which assertions to make about your program, the compiler is not doing that work for you.
I am concerned that it is forbidden even to question Haskell advocacy around here, even where it extends into pretty bald bashing of other languages.
Which is fine, because in Haskell you aren't spending all that much time telling the compiler which assertions to make. The compiler can infer essentially all the types in your program.
In fact, this is so useful that new versions of GHC are going to support "type holes". If you don't know what type you need in any particular part of the code, you can just write a _ there, and the compiler will tell you what type goes there! So really, you're not spending time telling the type system which assertions to make--the type system is telling you what you need.
This is going to enable a much more interactive development style that leverages the power of the compiler to help you write your program. I think a more interactive development system is the future, and this is a good (albeit fairly small) step in that direction.
Also, as an interesting aside, the type inference can actually make your code more expressive. In both Haskell and Python, you could write a function called toString that takes an argument and returns it as a string. However, the really cool thing is that in Haskell you can write the opposite function--fromString. This function takes a string and returns a value. The real beauty is that the compiler can infer what type you need and choose the appropriate parser; in Python (or, really, virtually any other language), you would have to specify whether you want an int or a double or a Foo or a Bar explicitly.
So: the types are inferred for you, you can use these inferred types to help you write your program and they actually make the code more expressive. I think it's a pretty good deal.
I am on the Haskell side of things here. But one small nitpick: You could write something somewhat like fromString in Python with some trickery. You would basically have to keep the string around and convert only on demand.
Types and tests give completely different assurances. Tests give you assurance that a particular code path works at least some of the time. Types give you assurance that an invariant is true all of the time.
