On Wed, 23 Jul 2014 15:46:56 +0900 Joel Rees <joel.r...@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 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140723100452.573d7...@mydesq2.domain.cxm
