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).

Comments on this page:

From at 2010-03-19 12:32:31:

Your argument may be weak. I can see how there are may be poor usages of general purpose languages when it comes to writing configuration files, but to count these languages out altogether for this purpose seems a little rash.

Your example of Rake is an interesting one, because Ruby is probably one of the best examples of a language in which it's easy to create your own DSLs to accomplish what you want to do. Now, it's up to the DSL creator to make that human-readable and -editable, but with the right implementation it can expose the API you need to manipulate in your config files.

Maybe what you mean to say is "I haven't seen a good example of a general purpose language applied to an app or system configuration scenario."

The scenario I typically run across is web server configuration, usually with Apache or nginx. This example is a good one. I see a lot of opportunity for using Ruby to replace this config file in terms of improving human readability. Hell, it almost looks like a Sinatra application. This configuration file is really, at its core, an API. Given certain parameters in a certain state, the configuration file should facilitate state change and different return values. I couldn't think of a more appropriate application of a general purpose, object-oriented language.

I hope you're not suggesting XML as an alternative :)

From at 2010-03-19 12:34:51:

Meant to put a signature above...


Pat Collins (

From at 2010-03-21 08:31:40:


You put it very well; this sums up my own thoughts, but I wasn't able to express them quite so neatly. We had a spirited discussion recently about general purpose versus dedicated configuration languages on my 'Puppet vs Chef' article:

Puppet vs Chef

I added a link to this post in the article.

By cks at 2010-03-23 00:09:51:

I've now written DSLIsNotHumanReadable to expand my views on DSLs and their human readability or lack thereof. Personally I think the nginx example is a good example of a perfectly readable configuration file as it is, one that seems unlikely to be improved by describing it in the form of a program.

From at 2010-03-28 07:27:05:

I disagree completely. well designed DSL is way better then any configuration 'language'.

In two words: config generation.

To take nginx configuration as an example, if it was a Ruby DSL you could do in config file all kinds of stuff that currently require custom coded plugins. For example configuring vhosts from SQL. I know there is probably a plugin for that, but it can't possibly cover all kinds of legacy databases and schemas you might need to configure from. And what if its not mysql, but some kind of http service or what not.

Other very common case is when you have several 'things' in the configuration that are very similar with just a minor differences. in DSL you would incapsulate it into a function or something similar and do all the differentiation with parameters and variables. in config file you are stuck with copy paste all over the place.

So in any non trivial case you might end up with a script that generates configuration which is them parsed by the program in question, which in my opinion is much less readable and maintainable then configuring it directly with DSL. not to mention the need to execute the script each time you need to change config.

Vitaly Kushner(

From at 2012-04-29 21:25:28:


I think you are arguing at cross purposes. You don't want things like the implementation of mapping vhost configurations from SQL to be embedded in your configuration. You want clarity and brevity, and simply having a plugin named "MySQL_vhosts" gets the job done. Embedding that implementation inside the configuration is exactly how you end up with a script that generates the configuration file. ;-)

Written on 19 March 2010.
« How Solaris 10's mountd works
Web analytics versus GET parameter security »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Fri Mar 19 03:56:40 2010
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.