Static vs dynamic typing, what's the deal with that?

Culturally, I'm into dynamic typing, since for a long time all the smart programmers I knew were also into that.

However, recently(ish), partly because of delving into Haskell and partly due to hanging out with some Googlers who genuinely like C++ and are articulate about it, I've realized I'm not so clear in my own mind about the relative merits of each.

Dynamic typing

Heterogeneous collections

Difficult to model with static type systems.

But what are they good for, really?

Unit testing

You have to write unit tests anyway, and they'll do the same correctness checking that the type system will, but why bother.

Documentation

Pretty much any serious Python project makes you document parameter and return types anyway.

Exceptions

I hated having to declare raised exceptions back when I wrote Java regularly. Now, I wonder. (And I have to document them anyway!)

Functional programming

Unquestionably easier with dynamic typing, because expressing the type of a function is often difficult (except in Haskell).

Do declared types complect things (ala Rich Hickey?)

Also, I tried to explain Haskell's open type system to a Go fan and found I couldn't. If I can't explain a thing, I probably don't understand it.

Static typing

Clutter

Done badly, they introduce a lot of unnecessary text java MyObject myObject = new MyObject();

Type inference goes a long way toward addressing this.

Patterns

Are any of the patterns in Gang of Four work-arounds for static types?

Testing

Particularly when writing Haskell code, my testing instincts are way off. I don't really do TDD with it, and by the time I've got the code to compile, I feel confident that it works.

How much unit testing does a type system let you avoid?

http://glyph.twistedmatrix.com/2008/07/static-on-wire.html

zope component architecture is a decent optional type system for Python.