Re: Lua as a config-file language [was Re: proplib and the jet age]

[David Holland <dholland-tech%netbsd.org@localhost>]

On Fri, Jan 04, 2013 at 09:50:21PM -0500, Mouse wrote:
 > > [...]... but do keep in mind that in general, using Turing-complete
 > > languages for configuration is a bad thing.
 > 
 > For whom?  And why?  I have trouble seeing downsides, and indeed have
 > taken advantage of it myself in the case of /etc/rc.conf on some of my
 > 4.0.1 machines.
 > 
 > But you know your stuff, so I'm probably missing something.  What?

Basically what I wrote in the other mail replying to Christos: it
increases the complexity of your configuration space and makes it
harder to understand.

When you know what you're doing, it can let you do things that
otherwise require specific support, like making your laptop
automatically choose a different default printer depending on whether
it's at home or at the office, or not running /etc/daily when on
battery power, or whatever. But when you don't know what you're doing,
or when you think you do but some dingbat working for your Linux
vendor has misused the facility behind your back, it can be a major
problem. Especially if the whole thing is not well documented, as is
usually the case.

It is my observation that early in the lifecycle of new things there's
a tendency to need, or believe you need, Turing-complete configuration
because developers don't know what their users are going to need to be
able to do in the trenches, and even what that's likely to entail may
not really be well understood yet. Later on as things become more
mature the need tends to go away, but by then the Turing-complete
scheme is widely deployed and can't easily be recalled. The canonical
example of this process is sendmail.cf, but there are plenty of other
less glaring cases.

It is better not to fall down this hole at all, by paying more
attention up front to what the expressive range of your configuration
really needs to be, by working with people deploying your stuff to
figure out what they do and do not need to be able to do, by
engineering just those things and not others into your configuration
system, and (often most importantly) avoiding the temptation to
provide specious generality just because you can.

There is also a problem with Turing-complete configuration when one
starts trying to provide desktop (or tablet/phone) software with
Control Panels and Preferences and so on, which is that it can't be
adequately represented in that context. Most of the time when people
run into this problem, or other allied problems, their desire/need to
provide a Control Panel outweighs the need to represent the
configuration correctly (which they may not even understand, as these
sorts of tasks tend to be handed out to the most junior coders) and so
you get an unsafe Control Panel. It may work as long as you never
touch the configuration except through it; but if you do, or the
configuration becomes corrupted, you are in a hole that you probably
can't easily get out of.

It doesn't require Turing-complete configuration to land in such a
mess, just configuration that's too complex to represent adequately
(or that some bozo thinks is too complicated for end users to see)
but Turing-complete configuration makes it nearly inevitable.

It is my theory (although I don't have adequate evidence for it) that
a lot of the random weirdness that arises in Windows, and also in
GNOME and KDE, has this kind of unsafety property at its root.

-- 
David A. Holland
dholland%netbsd.org@localhost