Static typing is a great static analysis tool

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.

  • In case of Scala take advantage of FSC. First compilation may not be so fast, but another one is much much faster.

  • Adam, your just not using the best of breed tools for Scala development! Give SBT 0.10 a try – both compilation and testing can run in the ~ (continuous) mode (that is, repeated on every file modification), SBT rebuilds only what’s really required and that’s not all – both compilation and testing run in paralell by default. So all your previously idle CPU cores finally get busy.
    IntelliJ is unbelievably slow by default when it comes to Scala compilation – I understand what you mean. But even without SBT, have you tried using Fast Scala Compiler? It can be setup quite easily and you gain a significant speedup.

    REPL actually compiles everything under the hood, not sure you knew that.

    You could have preference for either dynamic or static typing. An interresting point of view was presented by Ola Bini in his pyramid of languages. You can apply the most appropriate language for given part/layer of a system.

    My experience with both static and dynamic typing is that I find static typing very convenient especially with good type inference. It just saves me looking at docs or at runtime exceptions. Last time I have worked with Python SUDS library to maintain a couple of legacy system tests for an application. Most of the time I spent with it was looking at test output and figuring out what else attribute do I have to handle or should I spell it correctly. That was complete waste of time – what was the advantage of not having the compilation? Yes, I could just save the file and re-run the tests. So what? I waited for the tests even longer, to have some feedback. The compiler would tell me my errors immediately.

    How it would be to have only static typing, but without compilation? I don’t know. Do you know any practical cases? I heard of Groovy having optional type declarations, but how does it work in practice?

  • Hear ye! You might want to check out the paper “Always-available static and dynamic feedback”, which is linked from . The paper contains:

    (1) a manifesto about how programming language should support both easy testing and easy type-checking, because both are useful, and

    (2) experiments to show that such an approach is both possible and potentially useful.

    The above webpage also has a link to the implementation.

  • Ah yes, the FSC. I always wondered why it’s so well hidden, and if there’s anything wrong with it :) But maybe it’s mainly an Idea deficiency – why would you want to develop with the regular compiler? ;)

  • Christian

    The interesting thing about fsc is that it has some hardcoded timeout in it which can be very annoying. Newer scala versions should fix that. See also:

  • @Przemek/SBT: I’m using both 0.7 and 0.10 and it’s true that the continuous compilation mode is very useful :). Although I wouldn’t call 0.19 best-of-breed (at least yet) – I get regular OOMs or, after several cycles, a message that the scala compiler can’t be found ;) So there’s still room for improvement :)

    @Przemek/REPL: yes sure, it has to compile, but it feels almost like a dynamic language

    @Przemek/typing: I agree with all the arguments about the advantages of static typing. But my point is that having static typing, code completion etc does not imply in any way the need of a compiler. In the old days you were editing in vim and afterwards using the compiler to type-check your program. Now we’ve got IDEs which are much more robust in type-checking on-the-fly. Even without an IDE, type checking could be an optional compiler plugin/pre-processor/validator.

    As for practical cases, I don’t have any – that can be either an indication that the whole idea of separating compiler and type checking is flawed, or that it’s high time to introduce this concept somewhere :)


  • Thanks for the link, looks interesting!


  • Maciej Biłas

    Regarding the SBT OOMs. Typically they are caused by PermGen being exhausted. Adding -XX:+CMSClassUnloadingEnabled to the startup flags of SBT improves it’s “lifespan” (as defined by the time you don’t get another OOM).

  • I’ll try that, thanks :)

  • LK

    In eclipse compilation takes actually much less time than on Idea :>