Explicit Static Types are not for the Compiler, but for the Developer – Duh

Lots and lots of people lament the explicit type system in Java, either they are dynamic ducks or inference intellectuals. Taken from the Boo manifesto:

Nothing more tiresome than writing the same type name over and over just to make the compiler happy. I’m not talking against static typing in general (boo is statically typed), I’m talking against being coerced by a tyrannical compiler to say things it should already know.”

Beside the fact that my IDE does the typing with auto completion – of course the compiler knows – DUH. But the developer does not know. The developer who wrote the code does know, for about a month. When not working with the code for some time or another developer taking over – then is where the problem rises it’s head.

Explicit Static Types are not for the compiler, but for the developer.

Is person of class Person? Or perhaps Student or Employee? I’m wading through legacy code and the first thing that gets out is correct naming. What once was a person soon gets a Human. How should I know? Explicit typing is writing documentation. Not helping the compiler.

Some people claim explicit types increase lines of code. I can’t see how:


There are other things in Java that increase lines of code. Not explicit types. If I had some whishes free, I’d opt for properties and getting rid of unnecessary getter and setters, I’d like to have constructors with named parameters like in Groovy, I want syntactic sugar like [] and [:] for list and map creation, I want all attributes public unless declared private, all methods public unless declared otherwise, I want to drop the “;”, remove unneeded (cast)s where I declared the type explicitly and I wish for closures. But drop explicit types? NO!

My style of programming uses lots of interfaces. A class usually has several small ones and I try to narrow down a class to the interface I use. Narrowing down an object reduces coupling and increases reusability.

Can I do this with type inference? What about

I guess type inference doesn’t help you here, coding against an interface and coding against more abstract entities as proposed by Robert C. Martin is out of the window. With type inference and without explicit types your code will depend on the concrete implementations, not the abstract definitions (or not depend on anything, which depends on your view ;-) Explicit typing is about reducing scope, knowledge and coupling.

Conclusion: Explicit types help the developer and create better, more understandable, more readable and more reusable code.

Sidenote to ducks: People claim that while they need 95% test coverage for dynamic code to find typo bugs, with explicit types the compiler gets the bugs for them:

“We discovered that anything shy of 95% code coverage with Rails means that type-os turn into runtime failures. We do not have any code coverage metrics for the lift code, but we have seen only 1 defect that’s been checked in in the 2 weeks since we started using lift.”

Thanks for listening.

Update: Jari wrote something about types inference, scala and IDE annotations on his blog.

Comments are closed.