Posted: Nov 29, 2004 10:18 PM
> 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,
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.
[... Tcl's safe interpreters ...]
> Can you suggest a link for this?
A man page to start at is: http://tcl.tk/man/tcl8.4/TclCmd/safe.htm
> P.S. I'm still wondering what "ITLS" is supposed to mean,
> but maybe that's TBA, as well...