[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: dual-language systems increase modularity
> Cc: email@example.com, firstname.lastname@example.org
> From: email@example.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
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.