Re: dual-language systems increase modularity

[Michael Vanier <address@hidden>]

> Cc: ll1-discuss@ai.mit.edu, owner-ll1-discuss@ai.mit.edu
> From: sundar@ascent.com
> Date: Sun, 16 Nov 2003 10:32:58 -0500
> 
> Hi, Shriram: Agreed w/ what you have to say about glue vs. "strong-type"
> scripting (i.e. where both caller/callee have intimate knowledge of types
> on either side).
> 
> > Shriram said at the workshop that his big question was, how do you go
> > "from scripts to programs"?
> Could you say more about what you meant here?
> 
> To me -- it has always been somewhat interesting that introspection
> abilities and debugging API's.. (both of which "expose" aspects of
> typing and control-flow across code/program boundaries) often are
> not designed in an integrated before-the-fact fashion. Once again
> an instance where the language/tools boundary causes more lossage
> than winnage.
> 

My experience with large-scale scriptable applications suggests to me that:

1) The ability to introspect objects written in the non-script language is
   critical, and must be very carefully designed in at the beginning.

2) There is a "scripting trap".  Once you start to code in the scripting
   language, you normally don't want to go back to the non-script language
   (especially if it's C or C++, because those languages tend to make
   programming quite painful -- not to sound pejorative).  So you write
   very large amounts of code in the scripting language.  If said scripting
   language does not have a good module system or any support for type
   declarations, you have a scaling problem.  I'm seeing this with some
   code I've been writing in java.  Sure, I *could* put a scripting
   language on top of java (kawa or jython come to mind), but essentially
   all I'd get from the standpoint of this code would be not having to
   declare types and a more interactive, introspective environment.  Nice
   though that is, it isn't enough of a win, especially since programming
   in java is not particularly painful.  Also, I don't have to design in a
   reflection mechanism, since java already has one.

3) If both languages support object-oriented styles, there are lots of hard
   issues with how to allow yourself to build objects at either level and
   access them from both levels.  Also, it should be easy to transfer the
   definition of objects from the script language to the non-script
   language with a minimum of disruption (because you will always want to
   eventually do this for efficiency reasons in many cases).

4) If both languages support exception handling, there are lots of hard
   issues with how to throw exceptions in one language and catch them in
   another.

5) If data structures will be built in both languages, there are lots of
   hard issues (including efficiency issues) with allowing data structures
   build in one language to be accessed from the other and/or transferred
   to the other.

6) If the type systems between the two languages have very different
   semantics, there is lots more non-fun to be had.

The SWIG project (http://www.swig.org) gives a good idea of the various
problems involved in interfacing multiple languages, and they are by no
means trivial.  I think an interesting question is what kinds of
applications can really benefit from a scriptable interface, and which ones
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.

Mike