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.
def person = Factory.getPerson()
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:
def person = new Person()
versus
Person person = new Person()
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.
public class Person implements Nameable {
private String name;
public String getName() {
return this.name;
};
}
...
Nameable nameable = new Person();
printName( nameable );
Can I do this with type inference? What about
List persons = new ArrayList();
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.
You can leave a Reply here. Of course, you should follow me on twitter here.
“Beside the fact that my IDE does the typing with auto completion”
Having completion doesn’t make the extra code worth having, it just reduces the number of finger presses to make it appear.
“When not working with the code for some time or another developer taking over – then is where the problem rises it’s head.”
The same IDE-using developer is certainly able to glance at the original method to see what types it has, and maybe just hover over the variable declaration to see what type the inference has given it.
“def person = Factory.getPerson()
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.”
person is a fairly meaningless variable name. You’re actually duplicating the type in the name, when you probably would be better off picking a better name, or getting rid of the name. Any time you rename a class, even in Java, you can end up with this kind of variable name becoming out of sync (IDEs can help in simple cases).
“remove unneeded (cast)s where I declared the type explicitly”
Where do you need such a cast? I’d guess most of those are misuse or lack of use of generics.
“Nameable nameable = new Person();
printName( nameable );
Can I do this with type inference?”
Yes. There’s no logic that says that type inference must always pick the most concrete type. However, as there’s no difference in functionality in your above code between you using Nameable or Person, it doesn’t matter much which is picked.
About your ArrayList example in particular, ArrayList is an example of bad API, as it exposes a List implementation by name, instead of just providing a method that gives you a List (and the actual implementation would be private/anonymous). In fact, as I’ve never adapted any code from using ArrayList to using some other implementation, I’d go so far as to say for that example, using ArrayList as the variable type isn’t insane.
“Explicit typing is about reducing scope, knowledge and coupling”
Explicit typing increases coupling by name, simply by making you repeat names. IDEs or other language-aware tools can give you everything that explicit typing has, but in a type-inferred environment.
The usual case in inference is that you can override the compiler’s choices if you like, so languages with inference only *allow* you to elide types, they don’t force you to. A step up on the ladder.