Sunday, October 10, 2010

Static Types are Costly

One of nice things about scripting languages is that they don't force you to putter away time setting up gratuitous static class hierarchies. When was the last time a real customer said "what I really want is a large number of class libraries".

That just isn't the value that customers are buying. In most cases the customer has a new business they want to enact, or an existing process they want to improve upon, and for you to facilitate that with whatever skills you are bringing to bear.

Proponents of static typing will argue that a language like Java protects you from certain important classes of bugs.

What no one has considered yet is the error injection rate arising from having to put time in to writing code just to satisfy the static type checks. The time would be better spent writing test cases.

Overall, static typing slows the development process down. You cannot build the structure without the scaffold, and in Java one ends up building scaffolds for the scaffolds, which at run-time are indeterminately deep.

Ordinarily the static source depth stops after a couple of levels, just below a massive library like Spring. But the run-time indirection is much deeper than the static typing would suggest; all the reflections and inversions result in error messages that are wildly difficult to connected back to the static sources.

That too, is an uncounted cost of doing business with Java.

No comments: