
Configuration files suck. Just use a programming language - jamesfisher
https://medium.com/@MrJamesFisher/configuration-files-suck-6daa9812f601
======
krapp
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.

------
davidgerard
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](https://en.wikipedia.org/wiki/Rule_of_least_power)

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

~~~
todd8
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...](http://beza1e1.tuxen.de/articles/accidentally_turing_complete.html)

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

------
dalke
This is a long debate, with no resolution. Eg,
[http://taint.org/2011/02/18/001527a.html](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.

~~~
curtis
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.

~~~
dalke
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.

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

~~~
gjvc
> But also every software developer wants to spend a week or two making a
> configuration GUI

no way in hell.

~~~
valarauca1
Thanks for catching my typo. Updated grammar

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

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

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

