Why is Bruce Eckel arguing about typing?

In his article entitled "How to argue about typing", Bruce Eckel presents another argument against the downsides of Java's Strongly typed system. So let's analyze a few of the things he is most certainly right about:

• Checked Exceptions == Evil. No question.
• The fact that something like Eclipse generates code for you should not be an excuse for static typing. Code generation means duplication. In terms of DRY you are still repeating yourself whether it is generated or not. This makes code longer and harder to read.
• You shouldn't feel your system is more robust and "safer" because it uses static typing. This is a naive approach to development.

Ok, so that is the good stuff out the way. However, the problem I have with Bruce's article is that it again tries to turn the static vs. dynamic typing argument into, ummm.. an argument. Why are we arguing about this? In my view you should be picking the right tool for the job.

This is so fundamental. I mean both paradigms have their strengths and weaknesses, why does one rule out the other? Bruce's article implies the only benefit you get from static-typing is the knowledge that your application is checked at compile time for type safety, which represents a false sense of security anyway. Fundamentally, he says, all you're doing is testing, which you should have unit tests for anyway.

However, when I use Java I don't use it to feel "safe". I use it for the advanced code navigation, refactoring and analysis tools that you get in modern IDEs like Eclipse or IDEA. These tools are not just about generating code, they're about being able to easily maintain your codebase and allow it to scale in terms of complexity.

But, of course, Java is horribly verbose and is not suited to every task. In this sense I would say it is essential that every developer know both a dynamically typed and statically typed language so that you can use a blended approach to development. Getting the best of both worlds.

The thing is, in Agile one of the issues known to reduce productivity is task switching. If you are constantly switching between different programming environments that don't integrate seamlessly with each other you will become less productive. Fact. Also, if you can't easily integrate the two you will end up writing duplicate code for each platform, violating DRY.

This is the fundamental reason why I believe Groovy will be hugely successful. By integrating so tightly with Java and providing a seamless transition with the same APIs and object model it significantly reduces task switching and integration overhead.

My advice: Don't enter this debate. There is really nothing to argue about, choose the best tool for the job and use it. Sometimes that may be a statically typed language like Java, C# and so on other times it may be a dynamic language like Ruby, Groovy or Python. Choice is a good thing people.