Thoughts on language-level configuration support?

[Lorenzo Gatti]

On 31 Mar, 09:19, jfager <jfa... at gmail.com> wrote:
> On Mar 31, 2:54 am, David Stanek <dsta... at dstanek.com> wrote:
>
> > On Mon, Mar 30, 2009 at 9:40 AM, jfager <jfa... at gmail.com> wrote:
> > >http://jasonfager.com/?p=440.
>
> > > The basic idea is that a language could offer syntactic support for
> > > declaring configurable points in the program.  The language system
> > > would then offer an api to allow the end user to discover a programs
> > > configuration service, as well as a general api for providing
> > > configuration values.

A configuration "service"? An "end user" that bothers to discover it?
API for "providing" configuration "values"? This suggestion, and the
companion blog post, seem very distant from the real world for a
number of reasons.

1) Users want to supply applications with the least amount of useful
configuration information as rarely and easily as possible, not to use
advanced tools to satisfy an application's crudely expressed
configuration demands.

Reducing inconvenience for the user entails sophisticated and mostly
ad hoc techniques: deciding without asking (e.g. autoconf looking into
C compiler headers and trying shell commands or countless applications
with "user profiles" querying the OS for the current user's home
directory), asking when the software is installed (e.g. what 8 bit
character encoding should be used in a new database), designing
sensible and safe defaults.

2) Practical complex configuration files (or their equivalent in a DB,
a LDAP directory, etc.) are more important and more permanent than the
applications that use them; their syntax and semantics should be
defined by external specifications (such as manuals and examples), not
in the code of a particular implementation.

User documentation is necessary, and having a configuration mechanism
that isn't subject to accidents when the application is modified is
equally important.

3) Configuration consisting of values associated with individual
variables is an unusually simple case. The normal case is translating
between nontrivial sequential, hierarchical or reticular data
structures in the configuration input and quite different ones in the
implementation.

4) Your actual use case seems to be providing a lot of tests with a
replacement for the "real" configuration of the actual application.
Branding variables as "configuration" all over the program isn't an
useful way to help the tests and the actual application build the same
data structures in different ways.

> > What value does this have over simply having a configuration file.
>
> "Simply having a configuration file" - okay.  What format?  What if
> the end user wants to keep their configuration info in LDAP?

Wait a minute. Reading the "configuration" from a live LDAP directory
is a major feature, with involved application specific aspects (e.g.
error handling) and a solid justification in the application's
requirements (e.g. ensuring up to date authentication and
authorization data), not an interchangeable configuration provider and
certainly not something that the user can replace.

Deciding where the configuration comes from is an integral part of the
design, not something that can or should be left to the user: there
can be value in defining common object models for various sources of
configuration data and rules to combine them, like e.g. in the Spring
framework for Java, but it's only a starting point for the actual
design of the application's configuration.

> > In your load testing application you could have easily checked for the
> > settings in a config object.
>
> Not really easily, no.  It would have been repeated boilerplate across
> many different test cases (actually, that's what we started with and
> refactored away), instead of a simple declaration that delegated the
> checking to the test runner.

A test runner has no business configuring tests beyond calling generic
setup and teardown methods; tests can be designed smartly and factored
properly to take care of their own configuration without repeating
"boilerplate".

> > I think that the discover-ability of
> > configuration can be handled with example configs and documentation.
>
> Who's keeping that up to date?  Who's making sure it stays in sync
> with the code?  Why even bother, if you could get it automatically
> from the code?

It's the code that must remain in sync with the documentation, the
tests, and the actual usage of the application. For example, when did
you last see incompatible changes in Apache's httpd.conf?

You seem to think code is central and actual use and design is a
second class citizen. You say in your blog post: "Users shouldn’t have
to pore through the code to find all the little bits they can tweak".
They shouldn't because a well designed application has adequate
documentation of what should be configured in the form of manuals,
wizards, etc. and they shouldn't because they don't want to tweak
little bits, not even if they have to.

Regards,

Lorenzo Gatti