Configuration files and dynamic languages

⇐ previous
Posted
next ⇒

A few months ago, Carlos Perez blogged about someone else's claim to have built a mildly complex web app using Ruby in just two months. Perez argued that one reason Ruby-based development was so much faster than Java-based development would have been was:

  1. Java web app frameworks typically use lots of configuration files.
  2. These are effectively dynamically-typed (i.e. checking is done at runtime, rather than during a compilation phase).
  3. If you're going to use dynamic typing, you're better off going all the way, rather than trying to weld dynamically-typed configuration onto a statically-typed language.

Perez offers no evidence to back up his argument, but it's an interesting one nonetheless. Hibernate, Tapestry, Tomcat itself, and many other current-generation Java tools require XML configuration files that are so complex that users are effectively doing bilingual programming, without having a debugger for one of the two languages.

In contrast, dynamic languages like Ruby and Python allow users to type in complex data structures directly, and make it easy to include calculated values. This is (in my opinion) the main reason why SCons (a build system written in Python) is easier to use than Ant: one language, with a debugger, and you don't have to jump through hoops to say "for each" or "only do this if A and B are true, but C isn't". Even Ant's inventor agrees: a few months ago, James Duncan Davidson wrote:

If I knew then what I know now, I would have tried using a real scripting language, such as JavaScript via the Rhino component or Python via JPython, with bindings to Java objects which implemented the functionality expressed in todays tasks. Then, there would be a first class way to express logic and we wouldn't be stuck with XML as a format that is too bulky for the way that people really want to use the tool.

Now that entire books are being written to decry the complexity of Java application frameworks, and urge us to return to simpler code, it'll be interesting to see whether more programmers switch to dynamic languages, or whether the continuing backwardness of those languages' application frameworks drives programmers back to Java and .Net.