Adam Warski

27 Jun 2011

Static typing is a great static analysis tool

static analysis
clean code

Statically-typed languages are great because, well, they have static typing. However very often developing using a dynamically-typed language is much more convenient. Take writing a webapp in Ruby On Rails – change some code, hit reload and you can see the new code in action. JavaScript – same thing. On the other hand change a bean in a JSF app: first redeploy (*), wait, and only then go and see the changes. Or even, run a very simple Scala unit test in IntelliJ – I don’t know why, but the compilation always takes a long time, even if the change is very minor. The total run time of the unit test far exceeds the milliseconds in which a unit test should run.

I know it’s in fact a compiled vs interpreted thing, but somehow statically-typed languages most often come in the “compiled” flavor, while dynamically typed in the interpreted one (**). I’m a huge fan of static typing, and I think static typing is the best static-analysis tool out there, but why shouldn’t it be left just at that: as a static analysis tool.

Moreover, the code is usually type-checked twice: first by the IDE (e.g. IntelliJ won’t let you run anything as long as there are errors, Eclipse I suppose does the same), then again by the compiler. Isn’t this a waste of time? If the modern virtual machines are so great at run-time optimization, is the compiler still needed, especially during development?


(*) Or just use e.g. JRebel; I think that JRebel is great, but I still view it as a huge hack on the JVM making our lives easier, rather than a “proper” solution to the redeployments problem.

(**) Scala takes a step in the “right” direction providing the REPL.

comments powered by Disqus

Any questions?

Can’t find the answer you’re looking for?