I don't know about you but I find the fact that the Interpreter pattern was "voted off" at the recent OOPSLA conference discussions on Design Patterns to be a Very Bad Sign(tm).

"Programming" is about the creation and transformation of relationships. That process is mediated by the creation and manipulation of "languages". I don't care if you call the language a "language" or "protocol" or "API" or "idiom" or "pattern" or "design" or "framework" or "architecture" or "paradigm" or etc. (ad nauseum).

One sad fact in the software world is that coders literally get lost in the "code" and forget all about the fact that they are dealing with languages. [And please do note carefully that I wrote "languages", plural.] I.e., programmers, whether they understand this or not, are *always* creating and manipulating languages when they create and modify code. Unfortunately, this is rarely conscious let alone the focus.

Another sad fact is that most programming language "designers" have fallen victim to the same problem and their programming languages are "designed" (almost uniformly horribly, I must say) for people to write more incomprehensible "code" rather than languages. I'm saying that general purpose programming languages (GPPLs) almost completely miss that point and therefore the code that people write in those GPPLs are almost always extremely poor, confusing, bug-ridden, etc. implementations of the informally-specified (usually implicit), horribly designed (usually accreted rather than actually designed) languages that the programmer is creating and manipulating.

For the "linguists" in the audience, let me humbly suggest looking at the history and evolution of programming languages slightly differently... There are two primary thrusts of GPPL development, mathematics (formal logic, symbolism, abstractionism) and hardware leverage (mechanistic, performance, conformist). All GPPLs are some combination of the tradeoffs between those two (often conflicting) needs. Given the historical lack of hardware horsepower, it's no wonder that the hardware leverage camp has been so dominant. This left the abstract, mathematics school of thought on the mostly research fringe where they've had to watch their old ideas get "rediscovered" (usually poorly :-) by succeeding generations of the popular GPPLs. Structured programming, functional programming, meta-programming, dynamic languages, OOP, OOD, patterns, etc. So far, that all is fairly commonly understood. Now, take a step to the left and look again at that evolution in terms of how all of those approaches are about trying to get a grip on the real languages that the programmers are trying to create and manipulate to develop (as) their systems.

The mainstream (of the self-styled programming avant garde, anyways :-) is finally starting to play around in this direction. To wit, look at all of the work on pattern languages and domain specific languages. Look at all of the sudden, "revolutionary" interest in code generation and reflection-based code manipulation. Look at the press that folks like Gosling got for working on a toolset based upon manipulating abstract representations of programs. For example, look at the continuing evolution of "aspect oriented programming" -- the AOP community is trying to backfit the ability to create and manipulate (higher-level) languages on top of the existing GPPLs. As their ad hoc approach continues to run into more and more fundamental problems, they continue to *try* to increase the power of their approach -- alas, mostly through more ad hoc measures (conventions, etc.). Finally, look at the growing buzz over the "Language Oriented Programming".

In summary and conclusion, here's my first rule on Programming and Languages:

"Any non-trivial program written in a general purpose programming language contains ad-hoc, bug-ridden, inarticulate implementations of multiple, informally-specified, incomplete, and inhumane languages."