>>It's possible to do whole-program inference, but it's expensive. I think many people see functional programming languages employing type inference and consider that dynamic languages are as suitable for the application of similar techniques, but the scale of dynamicity undermines these techniques: assumptions that hold for languages like ML are gone in languages like Python.
A mix of type inference littered with bits of type specification where applicable works quite well in properly designed languages.
There are always going to be languages where it's unsuitable and I'd argue that's a pretty good sign (not a conclusive one though) that the programming language is shit.
Yes whole program compilation is expensive... but so is repeatedly calling an interpreter or a JIT.
>>Tests based on type declarations only cover a certain class of errors, as almost everyone should know by now. Dynamic languages obviously save the programmer from having to specify apparently obvious boilerplate, potentially permitting behaviour that would be awkward to define in many statically typed languages. However, restricting the dynamicity of such languages can lead to useful inference about program characteristics and can reveal errors, too.
Yes tests based upon type declarations only reveal certain classes of errors but they are errors that I as a programmer don't need to worry about. The compiler tests give far better coverage when it comes to those errors than any manual testing strategy that programmers practically implement.
This is where type-inference comes in , when you combine that with selective typing you can get the benefits of both. When you add templates and inheritance to the mix than very few things are hard to implement that are easy in other languages.
People will undoubtedly bring up C++ typing here. The c++0x standard addresses problems with the language standard to a large degree with the 'auto' specifier. A lot of the other errors and the difficulty with them rest at poorly implemented compilers. I've got high hopes here for LLVM.