Re: Rather, DSSLs increase modularity, productivity

[Michael Vanier <address@hidden>]

> Date: Sun, 16 Nov 2003 15:47:52 -0500
> From: Mike Newhall <mike@newhall.net>
> 
>        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? :-)

The only examples of this I've seen that are reasonably compelling are
common lisp and Dylan, the latter having been designed explicitly to allow
two universes to cooperate.  The .NET initiative is a completely different
approach to the problem; maybe it will pan out in practice, though I gather
there's a lot of pain to be had in trying to interface mutually
incompatible type systems.

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

Yes, BUT that puts a heavy burden on the scripting language.  Now it's not
being used just for "scripting" i.e. smallish programs that glue together
functional modules (what has been called "glue coding").  It's a real,
serious programming language for applications.  And that means that it must
have a decent module system (at least), and it would also be nice if there
was some notion of type checking (my bias; I find myself longing for type
checking once the code base grows beyond about 1000 lines).  And if you
have all that, the notion of "scripting" has gone by the wayside.  Which
may be a good thing. 

An interesting feature of java is its C/C++ interface.  My understanding of
it is that where the data structures live is critically important to
performance.  It's very expensive to send data back and forth between C
world (no pun intended) and java world, so you have to commit to one or the
other.  If you've prototyped in java world and then need to send a data
structure to C world, you may then find that you need to send another
related data structure to C world, and another, and before long you're
looking at a major overhaul just to get more efficiency.

Bottom line: don't take lightly the problems involved with crossing
language boundaries.  Possibly languages of the future will all be like
Dylan, with a "scripting" version and an "application" version which are
deliberately designed to interoperate seamlessly.  Designers of the
programming languages of the future have got their work cut out for them.

Mike

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