Rather, DSSLs increase modularity, productivity

[Mike Newhall <address@hidden>]

       Much of this discussion is consistent with the theory that 
applications *are* domain-specific languages.  That is, implementors of 
large systems inevitably implement an ad hoc DSL as a natural result of 
development.  This is consistent with the semi-humorous comment that all 
large systems eventually implement an ad hoc version of LISP -- perhaps 
what they are really doing is implementing a DSL, and a LISP-like 
language is the ideal type of language to implement DSLs.  This would 
also explain why many DSL-scripting languages (DSSLs?) are a lot more 
like LISP than the low-level application implementation language (and 
why these DSSLs are showing up at LL conferences :-).

       DSLs allow programmers to deal with application-level objects in 
an application-level grammar (or something close) and not worry so much 
about the details that the implementation language forces them to.  More 
modularity *and* more productivity - fewer lines of more relevant code 
to do the same thing.

       The many problems pointed out that can arise when one has two 
universes to deal with rather than one are valid points, but two 
languages are not necessarily necessary.  Ideally one would have a 
language that suits itself well to implementing a DSL "natively".  So 
build your app in LISP or Scheme or another of our favorite languages 
and you won't need to introduce a completely different DSSL on top of 
it.  Problem solved, right? :-)

        Of course if you're writing a game you will probably need to 
implement your 3D engine in C/++, not R5RS.  If this is the case (and 
speaking as a former game programmer who's done it the traditional, hard 
way), I think it is acceptable and maybe even the ideal to explicitly 
shoot for the goal of "let's get out of C++ as fast as we can": Write 
what you have to in C++, with an interface designed to be manipulated by 
a DSSL at the earliest / lowest feasible point.  Your development of the 
high-level portion of the app will be more flexible, less bug-prone, 
easier, faster, cheaper, and more fun using a DSSL (Hopefully it will 
execute fast enough...).  I can thus agree with Michael Vanier that if 
you are using a DSSL to avoid pain, you do have a bigger problem: a 
too-low-level implementation language.  But if you have to use that 
language for at least part of your project, avoiding pain is a great 
reason to use a scripting language.


Michael Vanier wrote:

>would be better off without it.  My take on this is that if you're just
>using a script language to minimize the pain of having to write code
>directly in C or C++, you have a problem which transcends scripting and
>maybe scripting is not the best solution.
>  
>