Eitan Suez's Blog

January 2006 Archives

Skip the Compile

It seems to me that many issues that come up in Java stem from the "I don't want to have to recompile my code" argument. All kinds of design decisions stem from it too. We end up with systems that are written in two or more languages. What I mean is that we usually end up with a mix of Java code, properties files, xml files and other stuff. The properties files and xml files can be viewed as interpreted mini-languages that bypass the Java compilation hurdle.

Many debates surrounding Java 5 annotations also are related to this issue: many have argued that they don't want to have to recompile their code to revise the value for a piece of metadata. Fair enough.

How many times have you heard or read of a selling point for a software framework or product or solution being "and you can make changes to the system without having to recompile the code." I must admit I'm sure I used that line more than once before (in my early days programming :-)).

So here's what I find interesting: instead of coming up with all kinds of schemes to get around the problem, why don't we just deal with the root cause? I think it's staring at us in the face: why don't we simply program in an interpreted environment?

I think we all must admit that it's much nicer to be able to make a change to a web page or a template or a piece of code and very quickly turn around and test the change without having to recompile. Compare that to the way a jsp works: compile the jsp into a servlet and compile the servlet into bytecode. It's true that servlet containers are easily configured to 'autoreload' jsps. So in this case, it's really no big deal.

But that's not what I'm talking about here. What I'm talking about is if we need the equivalent of a config file, we don't have to go out-of-band and step out of the Java environment and start our new metalanguage in a properties or XML file like James Duncan Davidson did with Ant or like we do every day. We would simply write source code. An entire thick layer of nonsense design decisions would simply disappear. No more debates about put this code here or there depending on whether we want to incur the cost of a recompile.

This essentially is the argument for internal domain specific languages (DSLs). So Rake files are not written in XML like Ant is but instead they're interpreted by Ruby, the same interpreter that you use to write your Rails app (note: ruby and rake and rails are discussed here as means to provide an illustration. this entry is _not_ about 'ruby is better than java' but rather about the more general idea that 'interpreted might be better than compiled, from this point of view anyway').

More and more these days I'm coming to think that a single or unified underlying model for interpreting stuff would be a good, pleasing thing. I like this kind of simplification. We end up with a more uniform system, and spend less time reinventing the wheel.

I find it most interesting that for some reason, discussions around this basic issue never seem to come up. What comes up are people talking about or trying to solve the symptoms of the root cause, but the root cause seems to evade us.

Note: this entry is cross-posted on my personal weblog

This work is licensed under a Creative Commons License.