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

dual-language systems increase modularity



You need to be careful with the term "scripting".  I see that there
are at least two different kinds of uses of the term prevalent.

One is what one might call "glue" scripting, which is the sense of
Ousterhout's quote: the script's main job is to patch together lots of
existing applications.  To do this, it doesn't need much knowledge of
the individual applications, though the more it knows the better it
can glue them together.  But just a good "exec" notation suffices to
get you off the ground.  The script is generally the utility "in
charge".  Examples are Unix shells, most early uses of Perl.

The other I might call "extensive" scripting.  This is the mode where
some application provides access to its guts.  In this instance, the
scripting language needs to know a lot about the application, and the
application in turn needs to be highly amenable to reflection.
Canonical example: Elisp, or game scripting engines.

You can imagine various interminglings of these, but in the big
picture I think this is an important distinction, because it
determines a lot about the structure of the language.  A glue
scripting language can behave like most programming languages:
accustomed to being in charge.  (Of course, an application that is too
much in charge resists conversion to a component of some other
application -- eg, an app with a GUI you can't turn off, to adapt
Vadim's scenario.)  Whereas an extensive scripting language often
needs to have a very specific application-sensitive flow-of-control.

Shriram