You can pick up the syntax of JSON, INI and YAML in a couple of minutes - which is how it should be. Because all you should be doing with a config file is assigning values to variables or defining the attributes of a structure - and preferably, those values should be primitives. To me, "Turing complete configuration" is a contradiction in terms, or at least it should be considered such. Almost everything the author lists as an advantage of using a programming language shouldn't be done with configuration anyway.

One of the reasons I like PHP is that INI and JSON parsing come out of the box, so no need to worry about whether or not a packaged parser is compliant. This is also one of the reasons why I avoid YAML even though it's more flexible - if a configuration format isn't supported natively by the language you're using then I would agree it's probably an unnecessary layer of abstraction. But I don't see how the c example provided is much better than the .conf file, although it does possibly demonstrate that the config file format itself should be a bit less opaque. At least I can expect that a simple config file couldn't eventually explode in algorithmic complexity into its own bloated universe of code.

Keep it simple. Keep it stupid. You'll be thankful a few years down the road when the inevitable feature creep hasn't caused your config workflow to explode into its own self-contained application with its own dependencies and peculiarities.

Terrible, terrible idea. The hazard of Turing completeness is that once you have it you will have to keep it. And the mind-rending horror of programming in a DSL that accidentally achieved Turing completeness has to be experienced to be believed. Let alone the horror of having to maintain it.

It also invites hideous hackery at the wrong level of the system. It turns trying to read a mere system config into trying to read source code. You will write some hideous spaghetti code in the accidental language. And then your future self will curse you.

See: Rule of Least Power https://en.wikipedia.org/wiki/Rule_of_least_power

There is no way the proposal in this blog post is a good idea.

I used to work on a proprietary software package that used this approach.

But the original authors of our software underestimated the craziness that customers would put into their "config" files. Once they had a programming language, our customers started to write programs.

Big programs--like approaching 100K lines. Programs that dynamically did different things in response to environment variables, machine names, specific usernames. Programs that read in custom ad hoc customer-specific "config" files. Programs that communicated to central servers over sockets. Programs that popped up GUI windows.

And of course programs that had lots and lots of crazy bugs, from memory leaks to stray pointers corrupting things to security issues. You cannot imagine how much fun it was to debug "our" software when the problem turned out to be in a customer's code.

There are some solutions to these problems, but you have to anticipate them first. I guess I'm just warning you to do so.

This is a long debate, with no resolution. Eg, http://taint.org/2011/02/18/001527a.html from 2011 is "Against The Use Of Programming Languages in Configuration Files", with links to resources both pro- and con.

In Python, you see migration away from the Turing-complete "setup.py" configuration language to a special purpose "setup.cfg", in order that dependency systems can reason about the configuration without worrying about the Halting Problem.

Amusingly the suckless package suite does exactly that, all your configuration is done in native c as a large array I believe and compiled into the program.

Also most Freeware daemons and servers are configured by running a literal bash script when they start.

That being said configuration files exist because not everyone knows BASH, or C, or Python, or Javascript/Node.js But also every software developer doesn't want to spend a week or two making a configuration GUI.

So I have to learn languages and compilers I don't know just to configure a tool I wish to use?

it gets tricky because in order to change the configuration you now have to change the source code and not every software is open source.