At what point does a config file become a programming language?

Question

I have been mulling over config files and their relationship to code for a while now and depending on the day and direction of the wind my opinions seem to change. More and mor

Answer 1

Yes, config files should be simple. They should contain no 'logic' themselves - think of them as a list of expressions in if statements, not the conditional statements in their entirety.

They're there to allow the user to decide which of the options coded within the application should be used, so don't try to make them complicated, it'll end up being self-defeating - you may end up writing simple config files to control how the original config file should be configured otherwise!

Answer 2

It depends on what you agree with other developers on the team. Are you using config files just as config files or you are creating a Model Driven application.

Symptoms of config file becoming a programming language:

• name=value pairs start to depend on each other
• you feel a need to have flow control (ex. if (this) than that)
• documentation for config file becomes essential in order to do further development (instead of just using the application)
• before value from config is read it requires to have some context (i.e. values depend on something external to config file itself)

Answer 3

One of the purposes of the "Oslo" work at Microsoft is to permit (though not require) resolution of this issue.

1. An application would ship with models of any new components it includes. It would also use existing models. For instance, it might include a web service, so it could reuse the system model of a web service.
2. The models will include metadata describing them, including enough information for tools to access them, either textually or graphically.
3. Parts of the models will correspond to "configuration"

This means that the equivalent of todays configuration files may be rich enough to support both textual and graphical editing of their configuration. The graphical tool will be supplied with "Oslo" (code name "Quadrant").

Answer 4

Config file: "What is my purpose?"
You: "Configure the butter."
Config file: "Ok..."
Config file: "What is my purpose?"
You: "You configure butter."
Config file: "Oh my god."

1. There is no "true purpose" of a configuration file. Its whatever makes sense for your application. In general, things that differ (or might differ) between machines and don't change in the middle of your application run should probably be in a configuration file. Defaults, ports, and addresses for other services are all great candidates. Keys and secrets are also great candidates but should be handled separately from your normal config for security reasons. I disagree that the purpose of a config file is to allow quick changes to be made. The purpose should be to allow flexibility in the setup of your application. If a config file is a quick easy to way to allow that flexibility, so much the better - but you should not be intending your config files to be frequently changing.

2. Yes and no. Should you atempt to make your application's code simple? Yes. You should attempt to make everything you write simple and to the point. No more complicated than it needs to be. Same is true of your config. However, this is very application specific. Hardcoding what should be in config because it would make your config "too complicated" is bad design. In fact, trying to "keep things simple" is why config files end up being a giant mess. Sometimes the simplest move is to modularize. This is why your configuration files should be written in a well known general purpose programming langauge - not some terrible configuration language (read: all "configuration languages" suck).

3. Again, who should be modifying config files is completely application dependent. But I agree with miniquark, whoever is deploying the application should be in charge of the configuration.

4. Source control everything you can. Source control is great. You can roll stuff back super easily and you have a full history of the changes you've made and a record of who made those changes. So why not?

Answer 5

I'll be the contrarian and submit it's only a language when it embodies more than can be represented by XML; or else when XML is considered to be a language.

Alternatively, most config files can be thought of as classes, but with only properties and no methods. And without methods, I don't think it's a language.

Ultimately, "language" is a squishy abstraction, but yes, the edges are ambiguous.

Answer 6

You could turn to theory of computation to define what counts as a programming language. If your configuration file format is Turing Complete then it reasonably counts as a programming language. By this definition, a file format to describe levels of Sokoban counts as a programming language (see here). There are other levels of complexity below Turing Complete that may also count, such as Regular Grammars and Pushdown Automata.

Another way to look at it is that many config files are only capable of data markup, whereas a proper programming language must be able to implement algorithms. For example, JSON is a config file format, whereas ECMA Script is a programming language.