Summary
Programming really is all about the languages that we create and use. Unfortunately, not in the way that most people think.

Advertisement

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."

>>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.)<<

Perhaps should explain what you mean by "ad-hoc approach" and "more fundamental problems".

I'm more interested in your own thoughts and experience and not the rhetoric of foolish, ignorant, self-important programmers.

If it's not obvious yet, I am an AOP advocate. I also know that there are issues with AOP, but no more serious than my experience in OOP. Most of my appreciation stems from being able to mix declarative (pointcuts,advice) and imperative (classes,objects) constructs nearly seamlessly. I am also able to layer functionality incrementally in ways that object orientation cannot like the http://c2.com/cgi/wiki?FragileBaseClassProblem etc...

(A) It's a sad state of affairs to me that so many people exhibit a presumption of "bile" in our society (and then react to that presumption rather than actuality (though, yes, of course, since so many other people express that same presumption, that presumption all too often ends up being fulfilled, sigh)). The hijacking of civil discussion by polarizing, extremist points of view and presentation misses so many opportunities.

(B) Please read what I actually wrote again and note that I'm not ripping on OOP or "design" or even AOP. I'm saying that we are missing an important facet and that the various paradigms, abstractions, GPPLs, tools, etc. are not only manifesting our lack but are, more or less, fostering and exacerbating the problem.

(C) Since you are an advocate of AOP, please explain how you think AOP specifically provides reliable, articulate, comprehensible, maintainable, etc. grip on expressing the actual languages that programmers are creating in their systems. As I noted in my original post, I'm talking about the need for direct expression of language, not indirect, so you'll need to explain and justify facts like AOP's penchant for hiding behavior and slipping it in behind our backs.

(D) In addition to (or instead of :-) answering (C), you can, of course, argue against e.g., my contention of the need for the support for building systems more directly expressing the actual languages.

In your blog, you criticise the various approaches existing today, such as AOP, and languages where, due to their expressive power, it's possible to write something like DSLs in the language (such as C++, and the Boost.Spirit parser framework, where you can write an approximation of EBNF directly in the code). There are also other approaches on creating meta-languages (languages to create languages), such as Intentional Programming, and similar things, where there's a lot of experimentation.

I found it a little hard to see what you were actually after, but could it be expressed as "languages to create languages"? If so, since you criticise these other approaches, what's your alternative? I didn't see an alternative - so real comparison could be made - in your blog.

Writing a "meta-language" is hard, and I haven't yet seen an example showing that we've found "the way" to create a meta-language where it is both easy to do common/useful things, and possible to do advanced things. Direct manipulation of internal code structures tend to be hard to use, whereas AOP may be easier in this respect, yet may have problems doing things not catered for by the AOP implementation.

> In your blog, you criticise the various approaches> existing today, such as AOP, and languages where, due to> their expressive power, it's possible to write something> like DSLs in the language (such as C++, and the> Boost.Spirit parser framework, where you can write an> approximation of EBNF directly in the code).

Ah, but note how you have to qualify your statement with "something like". That is, those are all basically ad hoc, incomplete approaches to trying to graft various kinds of language support onto GPPLs. [Hygienic macros are complete in that sense but suffer from ugliness and complexity.]

> There are> also other approaches on creating meta-languages> (languages to create languages), such as Intentional> Programming, and similar things, where there's a lot of> experimentation.

Indeed, there's lot of experimentation in mutating GPPLs to focus more on the languages being created but they are fundamentally screwed up (from the language perspective) because the basis of those GPPLs is NOT the languages that people will be creating with the GPPL.

Indeed, there are also various "discipline" based approaches to languages creation in GPPLs. For example, look at how much OOP code is horrible from an OOD standpoint.

> I found it a little hard to see what you were actually> after, but could it be expressed as "languages to create> languages"? If so, since you criticise these other> approaches, what's your alternative? I didn't see an> alternative - so real comparison could be made - in your> blog.

I am purposefully not talking yet about my thoughts of better ways to do things -- I'm hoping that people will think of where we are currently and where we've been, first.

> Writing a "meta-language" is hard, and I haven't yet seen> an example showing that we've found "the way" to create a> meta-language where it is both easy to do common/useful> things, and possible to do advanced things. Direct> manipulation of internal code structures tend to be hard> to use, whereas AOP may be easier in this respect, yet may> have problems doing things not catered for by the AOP> implementation.

You're thinking of the need for a "meta-language" seems, IMVHO, rooted in traditional thinking. There are plently of examples of successful, powerful, useful little languages. In general, look at the trend towards more and more "scripting"/"dynamic" languages both in terms number of languages and number of developers using those languages. Yes, most of them suck as languages but then again, as the man said, most things suck. :-)

In terms of creating little languages, look at the consistency and completeness of being able to create "safe" interpreters in Tcl. Whether or not you like Tcl's syntax, with safe interpreters in Tcl you can easily create little languages using a well known base.

Re-reading your blog, I'm trying to understand what you're saying. Let me see if I can rephrase it, and maybe you can say whether it's something like this:

There are general-purpose programming languages (GPPL), and there are more special-purpose programming languages (or Domain-Specific Languages - DSLs), and there's a continuum between them. Some examples may be:

What you seem to be saying, is that if there's not a readily available DSL for something, then writing it in a GPPL may give a less explicit intent-revealing code, as the language may not have good support for the abstractions you'd like to create.

So, what's new?

If you want to create a DSL for every domain (or domains) your system is involved with, that may be quite a lot more work than using a GPPL, if that works fairly well.

The comparison is similar to using libraries, or writing your own code.

If this is what you're talking about, then - as a start - I may understand what the issue is. However, as you haven't (intentionally) revealed what you may suggest as an improvement of this situation, much more can't be said about your blog at this point.

> > Writing a "meta-language" is hard, and I haven't yet> seen> > an example showing that we've found "the way" to create> a> > meta-language where it is both easy to do common/useful> > things, and possible to do advanced things. Direct> > manipulation of internal code structures tend to be> hard> > to use, whereas AOP may be easier in this respect, yet> may> > have problems doing things not catered for by the AOP> > implementation.> > You're thinking of the need for a "meta-language" seems,> IMVHO, rooted in traditional thinking.

You mention using TCL to create interpreters - IOW using TCL as a meta-language (a language to create a language), so aren't we talking about the same thing?

> There are plently> of examples of successful, powerful, useful little> languages.

Indeed, yes. However, as you move towards specialisation, the domain they may be useful for also narrows. This could lead to an "explosion" of DSLs, if we'd like to use one for each domain. Then, there's their interaction. As well as practical issues, such as who will develop them (if they only cover a niche). Unless, that is, users may construct their own DSL, IOW a meta-language.

> In general, look at the trend towards more and> more "scripting"/"dynamic" languages both in terms number> of languages and number of developers using those> languages. Yes, most of them suck as languages but then> again, as the man said, most things suck. :-)

I don't get much out of this argument. Most of the "scripting languages" in wide use is general-purpose, e.g. Perl, Python, PHP, various Lisp dialects, etc. There may be more specialised scripting languages in some systems, but even they tend to be fairly general (Visual Basic, JavaScript, etc.), or confined to specialist systems.

> In terms of creating little languages, look at the> consistency and completeness of being able to create> "safe" interpreters in Tcl. Whether or not you like Tcl's> syntax, with safe interpreters in Tcl you can easily> create little languages using a well known base.

Can you suggest a link for this?

Regards,

Terje

P.S. I'm still wondering what "ITLS" is supposed to mean, but maybe that's TBA, as well...

> What you seem to be saying, is that if there's not a> readily available DSL for something, then writing it in a> GPPL may give a less explicit intent-revealing code, as> the language may not have good support for the> abstractions you'd like to create.> > So, what's new?

(A) On the part that you've restated, not much per se. I will quibble with your use of the term "abstractions". The point I'm making is about the *language*. That is, whether you're consciously creating e.g., a DSL interpreter or implementing some fancy OOD or building things bottom up or whatever, you are creating and manipulating multiple languages.

(B) GPPLs are just one facet that I'm talking about. W.r.t. GPPLs, one of my points is that they have had a very large effect on how we *think* of creating solutions. Design patterns, OOD, frameworks, AOP, methodologies, etc. are all attempts at trying to get a grip on the languages.

> If you want to create a DSL for every domain (or domains)> your system is involved with, that may be quite a lot more> work than using a GPPL, if that works fairly well.

Well, not to put to fine a point on it but looking at the software world now that we have some bit of experience and I've got to ask:How are those GPPLs working out for you?We've got unbelievably bad failure rates, piss poor reuse, poor ability to respond to change, wretched robustness, security? what's that?, etc. ad nauseum.

All of the various things that we've been trying have been attempts to come to grips with the nature of the problems that we're trying to solve. Languages, however implicit and unconcious, are how we actually mediate their solution.

> The comparison is similar to using libraries, or writing> your own code.> > If this is what you're talking about, then - as a start -> I may understand what the issue is. However, as you> haven't (intentionally) revealed what you may suggest as> an improvement of this situation, much more can't be said> about your blog at this point.

I ain't trying to sell you anything. I'm just trying to point out (a very clear and simple fact) that for a lot of reasons, we've been lost because we have not focused on the fact that what we're really doing when we program is creating and manipulating languages (so as to create and transform relationships). That's it. What you do with that knowledge is, of course, completely your business.

[... "meta" languages ...]

> You mention using TCL to create interpreters - IOW using> TCL as a meta-language (a language to create a language),> so aren't we talking about the same thing?

No, I'm talking about using Tcl as a base language (for example) so that people don't e.g., need to learn 8 bazillian different syntax's (one for each custom language) and their weird rules (and poor implementations, etc). I brought this up as an example that there is a wide continuum .

Hmm... Though, given your question, you seem to be using the term "meta language" to mean something a bit different than its usual meaning. A grammar based language such as ANTLR is a language for creating languages but it's not a "meta" language. Hygienic macros, on the other hand, are facilities in some GPPLs which allow for the extension of the GPPL itself -- that's meta.

> > There are plently> > of examples of successful, powerful, useful little> > languages.> > Indeed, yes. However, as you move towards specialisation,> the domain they may be useful for also narrows. This could> lead to an "explosion" of DSLs, if we'd like to use one> for each domain. Then, there's their interaction. As well> as practical issues, such as who will develop them (if> they only cover a niche). Unless, that is, users may> construct their own DSL, IOW a meta-language.

But that's part of the point... Everything that you're doing as a programmer is creating and manipulating languages (whether you're conscious of it or not). The perennial battle between the mathematician perspective and the hardware leverage perspective has obscured this most critical fact. Of course the question of "now, what are we going to do about it is important" but if there's no understanding of where we are and where we've been then I fear we're doomed to more fumbling about.

[... more and more popular scripting languages ...] > I don't get much out of this argument. Most of the> "scripting languages" in wide use is general-purpose, e.g.> Perl, Python, PHP, various Lisp dialects, etc. There may> be more specialised scripting languages in some systems,> but even they tend to be fairly general (Visual Basic,> JavaScript, etc.), or confined to specialist systems.

I'm confused by your confusion. I pointed those out as examples of the trend that people are starting to open up to (and even prefer) such little languages even for fairly large and complex tasks. It's just one trend out of many wherein people are (starting) thinking about the mismatch between the GPPL's and the languages that they are actually building in their systems.

> It helps to be American to work it out.> > "It's the economy, stupid." was a tag line used by Bill> Clinton to remind people what the most important thing was> that a US President's dealt with. > > "It's The Language, Stupid."> is being suggested here as the programmer's equivalent.

Aha. Then it also helps to not assume that everyone is an American. :) (I'm Norwegian, myself)