[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: dual-language systems increase modularity



On Sun, 2003-11-16 at 11:16, Michael Vanier wrote:
> 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).

... (other good observations elided)

It seems like bytecode environments like CLR or Parrot hold out the
promise at least of bridging these gaps, although it remains to be seen
how well this works out in actual practice.

These days I like to plot languages along two major axes:

1. statically typed versus dynamically typed
2. native-code compiled vs. interpreted or byte-code compiled

Proponents of each extreme usually have a good theoretical argument for
their emphasis and real world examples to support it, but it seems that
their worth as implementation strategies depends a lot on both the type
of application and the development phase of the application.

For instance, dynamic typing and a fast interactive interpreter are
helpful in the early prototype stages of development.  As an application
matures, however, the performance gains possible from native compilation
often outweigh the cost of longer compile times and static type checking
can be a big help in the later debugging and maintenance phases.  

For example, Java folks usually point to static type checking and
explicit interface definitions as helpful, yet most interesting Java
applications include some kind of scripting layer (usually in an awkward
xml syntax) and often include crazy bytecode manipulation tricks to work
outside the constraints of the type system.  Conversely, all the popular
scripting language implementors seem to have plans to add facilities for
static type declarations for reasons of performance and correctness.

The typical solution is to work in two (or more) languages, but, as
others have pointed out, this has some real disadvantages.

It makes me wonder if it's possible to build a language that can scale
along these axes as needed.  Of course, these extremes are somewhat
antagonistic, but it doesn't seem like it should be impossible to design
one language that could encompass everything outside of very low-level
stuff.  Modern Common Lisp enviroments seem to come the closest to this
ideal, with excellent support for interactive development as well as a
good native compiler and static type declarations.  They're usually also
pretty heavyweight, unfortunately, and don't integrate well with the
libc world around them.  I also miss the ability to declare interfaces
in Lisp.

The thing I find most interesting about Dylan is that the designers
explicitly tried to accomodate the shifting needs of developers across
the various stages of development.  I really like the idea of starting
with very loose specifications of type and tightening them down as an
application matures.

miles