Posted by eitan
on January 17, 2006 at 2:19 PM PST
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