The problem with general purpose languages as configuration languages
March 19, 2010
Lately, one of the popular ways to configure programs is not to come up with a custom configuration language or format (and the associated parsers and so on) but to use a general purpose language for this purpose, generally augmented with as much of a DSL as you can wedge in. One example of this is Rake, but there are others; I have the impression that it's most popular when there may be actual logic that you need to express in the program configuration, as is the case for makefiles.
It's my view that having your program configured through writing things in a general purpose language is generally a bad mistake (at least once you consider the purpose of configuration systems). To put it simply, the problem with configuration systems is almost always that they lack clarity, not that they lack power. Using a general purpose language is adding power while subtracting clarity; now, in order to understand what the configuration is going to do you need to mentally execute the configuration program in your head, on top of understanding the effects of the configuration options themselves. Overall, this means that you're solving the wrong problem. Even if your configuration system lacks both clarity and power, using a general purpose language solves only half of the problem while making the other half worse.
(It is a rare configuration system indeed that has clarity to spare but lacks power.)
It's easy to see why this approach to the problem is superficially attractive to programmers. As the old math joke goes, it reduces configuration systems to an already solved problem, making them into 'just' simple programs, and in a powerful language that someone else has already designed and implemented.
(I've observed that programmers tend to like hitting things with the programming hammer, as it were, and feel that programming can be the solution to all problems. Sometimes this works well; sometimes it produces things that only programmers like.)
I also suspect that attempts to twist the general purpose language into something DSL-like that is nominally human readable do more harm than good in the long run. The problem is that you're forcing people to work in two languages, not one, since now they have to know both the general purpose language and your DSL (instead of just the language and what the various subroutines you make available do). That the DSL is theoretically human readable doesn't help, because when you're dealing with a DSL you can't assume that you know what something does just because it's in pseudo-English (or pseudo-whatever).
Written on 19 March 2010.
* * *