Grady Booch has been around the programming language scene for a long time (I read some of his papers in grad school). He's now Chief Scientist at Rational Software. Grady was interviewed in February issue of .NET Magazine. There's a number of little gems in the article, but one jumped out at me because I've been contemplating it a lot lately. On page 2, Grady says:

I used to be a language bigot; I thought ADA was the way the world was intended to program. But we're talking a couple of decades ago. It predated even VB I think. Alan Cooper had done his thing around that time. And at the time I really thought that the choice of language was one of the most important decisions you could make on the development team. But then I encountered this wonderful language called Smalltalk, and C with classes which because C++, and then all the scripting languages and eventually Java. As I go around the world working with lots of projects, the choice of language is important because it brings to the table lots of specific skills, lots of specific tools, lots of specific patterns and idioms for use. And there certain things I can do better in some languages than others.

In the presence of Web services the choice of languages becomes even less important. Because you're going to use little snippets of scripts and lots of different languages on the Web user interface side, such as VB, maybe Java, lots of things. Again, it's raising the level of abstraction. Languages now help us glue those little pieces together and therefore fit in the interstitial spaces of our systems.

This is a fact. I've been playing with a lot of tools for building and serving up Web services and they all make use of a variety of languages to get even simple tasks done. The programmer is forced to map designs not into one concrete syntax, but several---all at once. At times, this cacophony of languages stands in the way of rational thought about the problem. To make matters worse, many of them are not even particularly well designed. As I've said before, most XML-based languages are syntactic arsenic. And if that weren't bad enough, a lot of the programming required to make Web services work isn't even programming with a language, its managing multiple configuration files.

The problem with all of this is fairly straightforward to understand: the nature of programming is building correct dynamic system behavior using static texts (i.e. programs). To do this, programmers have to build mental models of how execution will happen and envision that execution as they program. Mostly, they do this implicitly and, for most, its hard enough to do in one, well thought out language, let alone 5 or 6 bad ones. One last quote from Grady underlines this:

...we're working in a domain where applications are intrinsically concurrent and distributed, and must be secure. That is not a simple domain in and of itself. Not to be disrespectful of the average code warrior, but building distributed concurrent secure apps isn't a core competency of such people. They may make some good local decisions for those three issues; however, building a Web-based system that is extensible, scalable, and secure requires good global policies as well.

In such an environment, the role of the architect becomes even more important. Architects are supposed to be looking out for these global policies and designing the system so that the average code-warrior can make good local decisions producing a global end result that is functional and performs well. Even so, I think we could do a better job of creating languages to help manage these abstractions. Seems that no one even tries anymore. Just slap an XML syntax on a simple workflow semantics and claim you're cutting edge because you've sprinkled angle bracket pixie dust on your incomplete scripting language.