Re: FWIW: script vs. configurtion file
On Wed, 23 Jul 2014 15:46:56 +0900
Joel Rees <joel.rees@gmail.com> wrote:
> I suppose I'll get complaints about this being off-topic,
Yeah you dirty dog :-)
> but perhaps
> we can expose a disagreement on terminology without the clutter and
> heat of the discussion in which it came up.
>
> Words, when spoken, mean what the speaker meant. When heard, they
> mean what the listener thinks they mean. Communiction only occurs
> when there is some agreement between the two.
>
> Programming is a field of mathematics. Mathematically speaking,
> limiting a language to a declarative syntax does not mean that the
> language ceases to be a language.
>
> Trying to assert that configuration files which are limited to
> declarations are not scripts is most kindly viewed as an assertion
> that the configuration file syntax is simpler (for some definition of
> simple) than configuration files that are allowed a greater number of
> constructs (for example, conditions, loops, definitions, etc.).
>
> This is a subjective matter. One person's simple is not guaranteed to
> be every person's simple.
>
> A known consequence of limiting syntax to declarations is that certain
> kinds of complexity which can be exposed by a richer syntax end up
> being hidden by the limited syntax.
>
> The complexities do not actually disappear, they are just hidden,
> becoming implicit, buried in the definitions of the things being
> declared.
And, it just may be that you want this hiding. How much power over the
program do you want to put in the hands of Joe Ordinary User? As a tech
support guy, how much time do you want to spend supporting the user's
config *program*?
Although I spent 14 years making my living as a software developer,
there are times when I don't want the freedom to do absolutely
anything. This is why I switched away from Perl: I needed some
limitations.
>
> Whether hiding such complexities is truly simplification or not is
> often (but not always) a matter of taste.
Yes! Taste, and the goal of the program. Maybe you *want* to put huge
power in the hands of the user, or at least the guy who configures the
program. Or maybe you don't.
There's a programming language called Lua, which, in my opinion, is the
most well constructed language in the world, although its lack of tried
and true addons caused me to move to Python. Anyway, game programmers
often use Lua for config files. In doing so, they give the user the
opportunity to add new capabilities to the game, or change existing
capabilities. I guess the best way to think of this is the game is an
API, and you tell it what to do by programming Lua to operate the API.
>
> One thing is pretty much guaranteed: as the semantic domain of the
> declarative language is expanded, the number of identifiers increases.
> Without care, the number of identfiers can increase exponentially.
>
> In other words, you end up trading the need to understand the richer
> set of constructs for a need to remember and understand a lot more
> identifiers.
Yes. Look no further than the config file for IceWM for an example. I'm
not sure how using a programming language would decrease the number of
identifiers though.
>
> Also, if definition is one of the constructs eliminated from the
> language, you become entirely dependent on the providers of the
> language for functionality. If they choose not to provide an
> identifier that will invoke some function you need, you're stuck.
That's true. Of course, would you really fault the providers of the
language from not providing an identifier for "remove all content from
the doc, save, and delete the backup copy too"? Because if the guy
making the config with a Turning-complete programming language
accidentally does the wrong thing, that could happen.
I'm a huge fan of Yaml for config files. You can express almost any
data situation that way. If you like Yaml but want true
programmability, Lua would be pretty good, because you can do with Lua
tables pretty much anything you could do with Yaml, but you can also
write procedural or functional code to go along with that data. The
same could be said with Python dictionaries.
Shame on you for being OT! But for guys like me, who regularly write
programs so their Linux machine can efficiently run their businesses,
your post is an excellent and thought provoking resource. Thanks!
SteveT
Steve Litt * http://www.troubleshooters.com/
Troubleshooting Training * Human Performance
Reply to: