Jay Fields wrote a post named “Static typing considered harmful” where he gets to some interesting conclusions.

Type verification provides very little confidence that an application works. The little confidence it does provide comes at the cost of being confined by the type system. Verifying types is better than testing nothing at all. But, only verifying types is insufficient for application development.

The post provoked a big discussion among ThoughtWorkers and although I’ve read all arguments I couldn’t get to a real conclusion on this topic. Given the same overall performance and the same development tools I don’t think that static typing (like implemented in Java, C++ or C#) has any advantage over dynamic typing (and agree with Jay) but I wouldn’t be that assertive. I think static types are just a different way of thinking about types and have its own advantages and disadvantages. Probably will be ideal for a given problem and terrible for others.

The problem is that I can find scenarios where it does a poor-but-acceptable job and scenarios where it does a terrible job; but couldn’t find a real case here it would be ideal. I’m not saying that it doesn’t exist, only that I couldn’t think of it.

The only thing I thought was about long feedback cycles. Dynamic language development relies on short feedback cycles. You should write code and immediately run your tests. If all the tests you need to run to verify the behaviour of your classes take longer than seconds you will have problems.

You can’t really be productive using a dynamic language when a typo, missing/wrong parameter or other simple error conditions would take minutes to be detected, only after minutes of test running. In that situation a statically typed language would provide faster feedback: before your tests run your code would be compiled and verified. Those simple errors would be caught before the tests and you will save lots of time in the long run.

But, wait a second… Why do you have long feedback cycles in the first place?

You shouldn’t. Even if the compiler could find those little typos and mistakes before even running your first test this shouldn’t be needed. If we are talking about a language like Java, knowing that a given object is from a given type will not ensure you that it fulfils the class’ contract at all. You still need test to verify pre-conditions, post-conditions and invariants or those.

If you are in a long feedback cycle type systems is not the problem you should be worried with. Rationalize tests, avoid the desire of performing a full QA suite in your build, and make your tests effective and fast! By doing this you can verify often if your statically-typed objects actually do what they’re supposed to and -guess what?- once you get a fast contract verification you really don’t need the compiler check