Configuration files suck. Just use a programming language(medium.com)
medium.com
Configuration files suck. Just use a programming language
https://medium.com/@MrJamesFisher/configuration-files-suck-6daa9812f601
13 comments
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.
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.
Yes, here's a great list of turing completeness where you might not expect it (even Minecraft): http://beza1e1.tuxen.de/articles/accidentally_turing_complet...
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.
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.
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.
I think the problem is the implicit assumption that configuration has to be all the way one way or the other. In my experience you want configuration to be mostly declarative, but you also want to augment that configuration with limited amounts of actual code.
I think it's an explicit assumption. Either a configuration language is Turing complete or it isn't.
I think I know where you're coming from - if you are a human reading the configuration then you can analyze the actual code. But that's only one dimension of the problem, because it requires a human to be in the loop.
I think I know where you're coming from - if you are a human reading the configuration then you can analyze the actual code. But that's only one dimension of the problem, because it requires a human to be in the loop.
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.
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.
> But also every software developer wants to spend a week or two making a configuration GUI
no way in hell.
no way in hell.
Thanks for catching my typo. Updated grammar
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.
The temptation to do this in proprietaryware is strong because then your customers can customise their stuff without you giving away your precioussss.
Of course, then you have to support the terrible, terrible programming language you have just invented by accidentally making your DSL Turing complete.
Examples: ant, MediaWiki parser functions, whatever that thing Varnish uses is ... the Varnish one is less terrible than most Turing-complete configuration languages, but it still turns trying to read a config into trying to read source code. You don't want to do that to your future self.
(I have had to write actual code in Ant. It's as if COBOL were written in XML. Unbelievably horrible.)
Of course, then you have to support the terrible, terrible programming language you have just invented by accidentally making your DSL Turing complete.
Examples: ant, MediaWiki parser functions, whatever that thing Varnish uses is ... the Varnish one is less terrible than most Turing-complete configuration languages, but it still turns trying to read a config into trying to read source code. You don't want to do that to your future self.
(I have had to write actual code in Ant. It's as if COBOL were written in XML. Unbelievably horrible.)
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.