Stephan Schmidt tries to claim that static languages are more productive than dynamic languages. His main argument seems to be that Auto Completion makes him more productive.

Auto Completion is often touted these days as the main advantage of statically typed languages. Auto completion, however, only helps to type the code in. It's not the typing of the code that's the problem.

The key problem with software is rigidity. When software is rigid, changing it in one spot requires corresponding changes in many other spots. What we try to achieve is what I call the Local Change / Local Effect principle - a change in one area should only result in changes in nearby code and shouldn't propagate across the system. In the worst case, you get a domino effect.

One key reason software becomes rigid is because of coupling. Coupling comes in many different forms. Referencing a class, referencing a variable and sending a message all couple code to other classes or methods in the system. Polymorphism reduces the coupling by allowing different classes of objects to be used as the target of message sends. Encapsulation reduces coupling by hiding variables and using methods to access them. These methods can be called polymorphically. Design patterns such as Abstract Factory can replace class references with polymorphic message sends.

So, object oriented programming principles try to reduce the rigidity of software by reducing the coupling.Now, what does static typing (more specifically, manifest typing) give us? More coupling. We now have to specify the types of variables. These types form a coupling with the code that defines those types. In Java and C#, the types can be classes or interfaces. In both cases, you are causing more coupling to occur.

How does this impact Local Change / Local Effect? If I change a class name, I now have many other pieces of code that must change as well. I should be able to change the name of an interface, but that also impacts many other classes and methods. If I add a method to an interface, I must implement it in all classes that implement the interface. If I decide to split an interface into two, I must visit all variables defined with that interface and specify which of the new interfaces to use instead. If I combine two interfaces into one, I have to do the same thing. By adding static typing, I've added more coupling in my code and my code becomes more rigid.

I know that people are going to say that refactoring handles this problem, but refactoring is a poor solution. Refactoring still changes the code. This code still has to be submitted to the source code repository. The more code you change, the more you will impact other developers and other teams. Refactoring may make it possible to live with the coupling but doesn't eliminate the coupling itself. Object oriented principles aim to reduce the coupling itself.

Auto Complete doesn't solve the problem at all. The problem is coupling, not entering code.