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](http://www.muthukadan.net/docs/zca.html) is a decent optional type system for Python.