Static vs. Dynamic: The Line

If you read many programming blogs, you've probably heard about the recent rekindling of the static vs. dynamic debate. In particular, it started with Steve Yegge's Dynamic Languages Strike Back, followed by Cedric Beaust's Return Of The Statically Typed Languages and finally Ola Bini's A New Hope: Polyglotism. Ola does a good job of summarizing the other 2 and then proclaims that the correct answer is somewhere in between, using both static and dynamic languages in different situations.

As a Java developer who knows JavaScript far too well, this is something I've believed for quite some time. I'm going to go one step further and say that I have a vague idea of where the line is where it is appropriate to switch from static to dynamic. If you've done much JEE development (if you're reading this, I know you have!), then you also know too, but you may not realize it.

Think about a typical web application. Say we're using Struts, Spring, and Hibernate, but it really doesn't matter. In the view we have this mix of XML/HTML and some sort of code, be it logic tags or inline code. The type of everything is a string. We produce a big string as the output, all the inputs are strings, we validate strings. We have to do conversion in varying degrees to pass things on to the service layer, but by the time we get to the persistence layer, you better not be passing a String when you really need a Long. Did you spot it? We get virtually no benefit from types in the view, which is why no one uses Servlets anymore. Declaring that everything is a String is kind of pointless, so a dynamic language is a good choice for the view. On the other side, types help us ensure the integrity of our persistent data and let us avoid nasty things like injection attacks. The persistance tier has to be fast and it has to be correct. A UI glitch is annoying, but if we commit corrupt or invalid data, we're in big trouble.

That leaves the middle tier, which is where the blurry line between static and dynamic lies. One option would be to use a language with optional static types like Groovy (i.e., persistence layer is pure Java, middle tier is Groovy, top is JavaScript or Groovy with minimal typing). Another would be to use a library like DWR that takes care of most of the type conversions so you can have a statically typed service later but a fully dynamic view. The JVM really shines here because it gives us so many options. What languages you choose are largely going to be affected by what people know (i.e., what's easy to support) but picking the right tool for the job is important too. I think one thing is certain though, the days where developers can be effective knowing just one language are drawing to a close.