"It is experimentation and change that is slow in static typing."

It's all about the expressiveness of the language. If you can express more with less code, than it's also easier to change, to experiment.

If you change something in a dynamically typed language you still have to catch all places, where the change has consequences.

Only If you want to experiment with something locally without needing to update the rest of the code base, than dynamic typing has an advantage.

I think it's GHC 7.4, which allows something similar for Haskell, to have the typing checked at runtime, to allow this kind of experimentation.

I think that's the best of both worlds, because for the production code you can still activate the compile time type checking.

"I think it's GHC 7.4, which allows something similar for Haskell, to have the typing checked at runtime, to allow this kind of experimentation."

It will be in GHC 7.6.1 and the extension is '-XDelayErrors'.

http://hackage.haskell.org/trac/ghc/ticket/5624 http://hackage.haskell.org/trac/ghc/wiki/DeferErrorsToRuntim...

I do not believe so. In languages like ML, static typing is not just used for type safety. Proper use of static typing extends to be able to use it in establishing invariants all over your code. Now, your entire codebase becomes dependent on the type. No matter how expressive a language is, this causes a lot of friction.

If anything, it is my experience that static typing makes it much easier to refactor large amounts of code.

I remember numerous instances where I make a large change in one Haskell module resulting in a few changes in the module's external interface, the compiler systematically warns me of all the 20 other modules that needed changing, and lo-and-behold, if it compiles, it works.