a type system of sufficient power can express your program just fine so long as you declare to the type checker that you're not just making a silly mistake
Sure, if I know in advance what types I want to mix. But suppose I don't? Or suppose I start out with one type mix, and then discover I need to change it? With static typing, I have to do a custom type declaration for each mix, and keep it up to date.
Your intentions changed, so of course you need to communicate that. In real programs (like the Haskell compiler), the programmers simply make the change they'd like to make at one point. The compiler then spits out a list of issues the change caused and provides a possible fix for each one. They continue the dialogue with the compiler by making the suggested fix, or by making one of their own devising. The end result is a program that's free of entire classes of stupid bugs.
Also, if you're just changing type mixtures, you probably just need to make the type more polymorphic. You rarely need to be very specific, and good type inference systems will automatically infer the most general type possible.
Your intentions changed, so of course you need to communicate that.
But in a dynamically typed language, I don't have to communicate anything; it all happens automatically.
The end result is a program that's free of entire classes of stupid bugs.
A good test suite achieves the same objective with a dynamically typed language. There are tradeoffs both ways; I'm not saying dynamic typing is always better. But I don't think static typing is always better either.
good type inference systems will automatically infer the most general type possible.
With dynamic typing, no inference is necessary at all.
> But in a dynamically typed language, I don't have to communicate anything; it all happens automatically.
Nothing happens automatically, the compiler/interpreter just doesn't check. Eventually you hit the bit of nonsense code your change caused and then the program dies.
> A good test suite achieves the same objective with a dynamically typed language.
With considerably more effort and with no guarantees that you've come even close to correct. A test suite on top of a powerful static type system at least guarantees that you've killed classes of dumb bugs, and you've thought through and tested more complicated issues.
> With dynamic typing, no inference is necessary at all.
If I have a function in Python that used to only return strings, and I re-code it so it returns None in some cases, I don't have to re-declare anything. The code just runs and returns None automatically, without me having to change anything about the function except the actual working code that determines what gets returned. With static typing, I need to re-declare the function's return type; it won't automatically return None if the type system thinks it can only return strings.
With considerably more effort
I don't understand this; you're comparing a test suite on top of dynamic typing, to a "test suite on top of a powerful static type system", so you're expending the effort on the test suite either way.
and with no guarantees that you've come even close to correct.
Static typing doesn't guarantee program correctness either; it just guarantees type correctness, so to speak. You can have a program that gets all its type declarations right but still has faulty logic. So you're still going to need a test suite either way, as I said above.
Eventually you hit the bit of nonsense code your change caused and then the program dies.
Why do you assume the code change produced nonsense code? If it doesn't--if I got the change right--then the program runs fine.
I assume what you really meant is, if I made a mistake, a dynamically typed language won't catch it until runtime, whereas a statically typed language will catch it at compile time. That's true; that's one of the tradeoffs I mentioned between static and dynamic typing. With static typing, I catch a certain class of errors earlier, but I pay for that by having to explicitly declare things. With dynamic typing, I don't catch those errors until later, but I can program faster (at least for certain kinds of applications) because I don't get bogged down in having to keep all the type declarations straight. As I said in another comment upthread, I'm not saying this tradeoff always works out in favor of dynamic typing; but it doesn't always work out in favor of static typing either. I think it depends on the type of application you're writing.
Sure, if I know in advance what types I want to mix. But suppose I don't? Or suppose I start out with one type mix, and then discover I need to change it? With static typing, I have to do a custom type declaration for each mix, and keep it up to date.