Lambda the Ultimate

This seems to miss one of the main maintenance advanatges of DSLs: the fact that many maintenance changes can be imposed by changing the language processor, and not the user-written DSL code.

For example, suppose you need to add some validity check to many programs. It may be possible to implement these checks as part of the DSL interpreter. This means that change the code have been O(n) where n is the number of user written scripts, becomes O(1) - the change is completely localized.

This can be of prime importance when the DSL code is distributed between many departments and, perhaps, georaphical locations -- and is owned be people of varying skills and schedules.

This can be an essential factor. Consider things like security policies that are mandated from abouve, and must be implemented immediately across the board.

Products are usually designed at corporate headquarters, though. But maybe they are designed at several foreign subsidiaries in which case like you say the DSL could enforce uniformity and non-redundancy.

But the theme of the paper seems to be: putting a dependable old COBOL library to best use. (using the library directly in COBOL versus DSL code that is transformed into a sequence of library calls)

Many organizations are stuck with old Fortran and Cobol libraries, but still want to move ahead, evolve with the times, and use new functionality like GUI questionnaires in Tcl/Tk or functional programming. Financial engineers usually have been exposed to and are open to new innovative techniques.

Take Mathematica and Fortran. You used to write scientific numerical analysis programs in Fortran calling the IMSL library (that's what Wolfram who wrote Mathematica did at Stanford, I believe) Now you have a nice funcitonal programming DSL that can even be used to write new routines from scratch, e.g. the combinatorics library.

Modularity would make the DSL processor more maintainable.

Modular monadic action semantics allow "domain specific specifications to be made at a variety of levels" at the level of the DSL processor and at the level of DSL code as argued in Wansborough's paper which summarizes his thesis.

[ From Author's Page]

Keith Wansbrough and John Hamer (1997). A Modular Monadic Action Semantics. In The Conference on Domain-Specific Languages, Proceedings, Santa Barbara, California, October 15-17, 1997, The USENIX Association, pp. 157-170. Abstract. .ps.gz (66K).

P.S. I'm actually trying to get this system running with some simple DSL examples at which time I will have something more concrete to talk about.

I wonder whether these semantics based language design-protyping systems might ultimately suffer the same problems as the LISP/CLOS MOP (meta-Object Protocol), namely that the line between language designers and language users (i.e. programmers) gets blurred. When programmers can (sometimes arbitrarily) change the language they are programming in...some conservative types...that have to keep systems operational... might get concerned. Lisp-Scheme macros likewise are supposed to be used for language extension, not every program, but often are used habitual by programmers...for things that aren't language extensions)

I guess with proper layering you can restrict access to layers also, like DSL program writers are not DSL processor writers.

Just as Perl and Python have been the great popularizers of many concepts in computer science and programming languages, the potential exists for a do-it-yourself language creation system, what would a popularizing language creation system look like?