DISCLAIMER: This site is a mirror of original one that was once available at http://iki.fi/~tuomov/b/
In the posting “Thoughts on configuration files and databases”, I provided some reasons for the use of standard non-XML structural configuration file formats or simply suitable file systems, for the storage of program configuration options. (And although I pointed towards my preferences among these options, a variety should be used instead of settling on a single monoculturist standard.) But one crucial issue remained unsettled: we may still want to provide scripting access to our program, but do not want to spend too much effort in providing both, scripting and simple structural configuration. It is quite imperative, after all, that there is redundant access to all of the configuration options from the scripting language as well. But at the same time, a proper extension language should have access to much more features than that. How to resolve this problem?
A partial solution is provided by combining configuration and scripting with something like the Vis proposal: instead of hard-coding an user interface into the program, providing a user interface agnostic description of the program, of the commands it provides, and the data it has to offer. An user interface would then be generated from such a description perhaps semi-automatically combined with stylesheets, a bit akin to HTML (containing only tags with higher semantic meaning) combined with CSS. Such a description obviously includes everything that one would control through configuration files or some other configuration interface, but also various other things the user can ask the program to do, including anything one might want to bind to a key or other action (aside from the very low-level functions related to widgets and such, that a Vis program should be ignorant about).
For the scripting needs of many programs, a command/function set generable from a Vis-style description of the program, may very well be sufficient. This description is, of course, a named key/value structure, which can in a straightforward manner be mapped into any of the considered structural configuration file formats, as well as file systems. Therefore, it is a prime candidate for inclusion into Plan K from Kludgespace, providing support for shell-based scripting as well.
For many other uses, the Vis description may not be be sufficient, however. In these cases I suspect that often what is really desired, is full access to all of the functions exported by all of the modules of the program (to other modules). The issue is therefore more that of writing additional modules for the program, than simple scripting. If writing these modules in the source language of the program is not a problem, there should be no problem then.
But when the program is written in a low-level language like C, there can be a problem. One solution is to provide bindings to the necessary functions in some scripting language. Support for configuration files in that language comes almost free then. Another solution is provided by writing the program against some kind of “common language infrastructure” that should automatically provide bindings for anything using the same infrastructure. Unfortunately, it seems that these often go by the least common denominator (impure1 and object-bloated), not taking advantage of the special features and philosophies of different types of languages. Possibly the least common denominator philosophy extends even to the hardware level, and the infrastructure demands the use of an inefficient virtual machine.
Sometimes – maybe even always – it would be possible to offer a very simple API that would make it easy to manually write bindings for every language anyone has interest in using, while taking advantage of their special features. The Vis API, as far as it has been thought of in the document, is an example of a rather minimalistic API. While Lua is used in the Vis essay for demonstration purposes, I think such core application programming interfaces should be written in simple C (or any language that most other languages can easily access without giving up their own conventions) and be very simple, precisely for the aforementioned reason. To list a few other examples, Lua's C-side API is, in fact, also quite minimal, at least compared to the alternatives. OpenGL isn't all bad either, although there are quite a few functions available in the native C bindings due to providing the same functions for various sizes of numbers.2
In conclusion, the kind of description of programs, suitable for building various kinds of user interfaces – with or without fine-tuning stylesheets – should also suffice for many – one might even say all – scripting needs. Such a description also automatically provides structural configuration files, without the program's author doing anything about it – other than providing this description, of course. Thus writing the application around such a description kills, well, at least two and a half flies with one slap. For the lower level extension needs, others efforts are needed. These, however, should be rather minimal when the application has a good inter-module interface design and documentation, possibly combined with suitable inter-language tools.
1 That is, most values are mutable and operations have no guarantees of being without side effects.
2 It seems that “stack-based” APIs tend to be quite nice and simple more often than others. They're not necessary the least laboursome to use directly, but the most flexible for writing wrappers suitable to the task at hand. The functional programming equivalent is, of course, a suitable composition of a few primitive functions – which Monads give the imperative flavour to.