Config files aren't applications, hence you dont wanna write them in a programming language! Just face it. I was setting up Backuppc at home, brilliant backup utility, but with this horrible flaw of being yet another application whose config files are written in the same language as the app itself.

What's the point, honestly? How much hassle are you going to save yourself avoiding to write 30 lines for a parser? You can't call a bunch of variables, and sometimes even some conditional assignments, a config file. A config file should be very simply designed, divided in sections depending what config parameters apply to, helping the admin to think in terms of components and tasks rather than solitary strings and numbers.

And this habit seems to have crossed any kind of boundaries, small and big apps do it, programming language isn't relevant, perl or python, there's always one. But how did this happen? It all started with high-level scripting languages, for the big public this means perl. This idea that it was interpreted, simper than C, opened the way to new things, included config files that weren't any longer what they used to be.
And then php followed, and if I've seen conf files and parser for perl apps, I've never seen one for php (almost): edit lib/config.php, and shove an include (lib/config.php) in index.php, et voila', app is served. Eventually python came, it was good, but same problem, same reasons: it's simple, it's readable. I'm afraid it's not.

These days I'm working a lot with puppet, a configuration management tool. It's written in ruby, and has its own language for expressing config files, very easy and clear, much like english really. A few months ago I met the author, Luke Kanies, at a talk in London. Chatting with him it comes up he receives lots of comments on the lines of "Oh, puppet is nice, but I dont want to learn ruby", to which I can see how he goes "uhm?!". And then it struck me: he was wondering how was that, and this is the answer: because ppl these days assume that config files of an application written in some high level scripting language are gonna be a piece of code themselves. Even if most of the times they are simple enough, you can see how that's an instinctive reaction.

But another thing went lost in this process, config checking: "hey, we saved on the parser, why bothering with a syntax checker". And so that was flushed down the toilet as well. Unfortunately sometimes running a script without defining a variable can lead to quite unpredictable and unpleasant results. A proper config checker can catch a lot more than just missing parameters or bad keywords: it can enforce dependencies, configure defaults depending on other options, and more. Yes, now it's not any longer just 30 lines, but it should be obvious that it's worth investing some time in it.

So now the next question is gonna be: which format should I use? Though one, I'm leaving the answer to Tuomov, which wrote a brilliant article a while ago titled Thoughts on configuration files and databases. I'm just quoting a little snippet 'cause I'm dying to shout it myself: "Yes, you mindless XML fanatics, you who were born with silver bullets up your asses".