Lambda the Ultimate

In the old days (~ 30 years ago) IT systems were often written in assembly language. Since this kind of code is hard to maintain, many systems were table driven, and in fact quite flexible. You could often configure the software from the outside by changing the configuration tables, allowing you at times to supply entry points to new external routines ("user exits" or hooks), change the format of reports etc.

With compiled high level languages systems were usually much "cleaner" from a traditional SE point of view, with modules defining the various kinds of functionality (today we have classes and EJBs), but this could lead to less flexible systems, which didn't allow user customization, or even programmer customization without changing the code and recompiling. Maybe if reflective languages were in the mainstream the trend would have been different, but it wasn't.

It seems that some of these XML standards are bringing us back to the old days of table driven programs, with XML configuration files instead of fixed layout tables. The principle remains the same: Prgograms that can be customized from the outside, at times even while the software is up and running. This is a good trend.

I am curious to know if others share this feeling, and noticed the trends I am talking about. It seems like this is related in some respects to the debate about how programming language expressiveness affects programming style and helps entrench design methodologies.

I think though there is a fundamental tension between configuration and "programming". If the configuration is sufficiently full-featured, it approaches the complexity of a DSL, and is just programming by a different name. In that case, I would want to see the details of the configuration design before declaring it a "good thing".

On the other hand, good software design generally involves empowering the user to "hot configure" the application precisely over those variables that a) are of highest utility within the application domain b) are most well-defined within the application and its domain.

I'm not sure this is a "new trend"; XML has just given people the "silver bullet" that makes them stretch the principle to the limit. ;-)

It's not a new idea, that's for sure. Like I said, people have been doing this sort of thing for ages. But XML (and easy XML parsing) are helping these techniques to regain prominence.

That's why I said that in some respects this is similar to the influence reflective languages might have on the programmers using them.

I suppose what I meant is that even between the "old days" of table driven and the "new days" of XML, there has always been a desire to find a configuration magic bullet.

Attempts at "dynamic configuration" have been common in applications whether they were using a reflective language or had some custom configuration scheme. The dream of a totally data-driven application that is common among hard-core database specialists is a variation on this theme.

From my point of view, this isn't a discrete space but a continuum, with a totally closed application that takes no input at one end and an interpreter for a full-featured PL at the other.

I think that bold, unexamined use of strong configuration schemes just happen to have been done in XML recently because it is "standard syntax" that looks like a configuration format, but is often used as a (possibly lousy) DSL.

The Pragmatic Programmers make a similar point in a recent interview:

Plain Text and XML