Think of types as logical propositions, and type systems as theorem provers. The stricter and more powerful the type system, the more exact and precise the proof will be, and the more you can be guaranteed that things won't go wrong.
That may be true for some dynamic languages with primitive tools and implementations, but is not inherent in dynamic languages. For example, SBCL will alert me to branches that are impossible to take, adding strings and numbers, and even more if I've specified types (which is optional). As an added bonus, if I'm using SLIME in emacs, the s-expressions in question will be highlighted with a note. Factor and Scheme will perform similar tricks, and there's even Typed Scheme, which lets you convert your dynamically-typed code to statically-typed code incrementally.
This is a common misperception:
http://pychecker.sourceforge.net/ http://www.logilab.org/857 (pylint) http://www.jslint.com/
And to head off the common "But but but it's not the compiler", I contend you're doing something wrong if you're not also running lint against a C program, as C compilers do not catch tons of things that people do wrong, but lint does.
Both types of languages have common type errors. Some can only be caught at runtime in both, but some sorts of errors (signature errors), static type checkers can catch them.
I work in both types of languages. In the amount of time I spend fiddling with type system stuff in objective C, I could write 2 test harness classes in python, and happily would.
Now if you're talking Erlang, et al, then we can talk about static type systems. But for the algol languages, I don't think they have all the benefits of a strong, static type system that outweigh the productivity of dynamism.
If you use docstrings, doctests, etc, you can find quite a nice enterprise coding language in there. Remember dynamic are more expressive (by definition almost)than static languages per line of code. So that 20k Line java/C# program is something like 3-13k lines of python or 2-9k lines of ruby.
The dominant reason to use static languages usually has little to do with their static nature with regards to errors: They are often faster at execution time. Also, they tend to have cheaper programmers. Both of these often dominate any code quality issues.
I personally advocate mixed language situations (like python weave) for most situations like that so inner loops can get the speed of C, and the rest gets the development speed of a dynamic language.
I understand that strict typing works by guaranteeing some things won't go wrong, but I can't see many meaningful situations where it wouldn't generate a runtime error in a scripted language, or at least results that make the source of the error painfully obvious.
Ahh, but that's not the problem. It's easy to test the code your changing, it's a much harder problem to find and test all the code that depends on that code. Having the compiler spit out every instance everywhere that you need to fix due to a new type-mismatch makes this significantly easier.
Some dynamic languages will happily convert values from one type to another even when that's not the desired result -- you might not get an error at all, just some bad data you might not find until much later.
This happens with algol style static languages too (And is one of the reasons I find people arguing for Erlang instead of python more persuasive than those instead arguing C++ instead of ruby).
You are confusing strong types with dynamic variables. Most of the algol languages have weak to medium type strength.
For instance, python has much stronger types than C. However, it's variables are all dynamic references.
We try to check everything, and we have decent unit test coverage, but there are bound to be places we don't hit instantly - and running the tests takes longer than compiling does.