asah@CS.Berkeley.EDU (Adam Sah) writes:
...
| - regexps in Perl, traces in Tcl, etc. are all examples of advanced language
| features. In this vein, Java provides garbage collection, exceptions,
| objects, safety, convenient concurrency primitives, etc. I think it's
| pretty hard to (objectively) toss Java into the "systems language" camp,
| at least without more rigorous definitions. A really useful chart would
| be one that said what kinds of features are found in scripting languages.
| For example, portability of scripts is probably very important.
a.) For me, it's not at all clear why you think those features of Java
disqualify it from being a ``systems language''. While the ``scripting
languages'' have been bringing in some features from more formal
languages, the point of that paper seemed to be that in general
you don't need those features to script and glue.
In a sense this only proves your point - without more rigorous
definitions, we only end up arguing about semantics and lose the
point (if there is one.) I'd go farther, though: the notion of
using four or five computer languages (C, C++, Java, Tcl and VB)
to define a language taxonomy of ``scripting'' vs. ``systems''
needs rethinking. Even among these five we start to see some
strange bedfellows, as you point out.
b.) Portability is the last thing I'd worry about in a scripting language.
Contrary to apparently widespread belief, ``as we approach the year
2000'' scripting languages have been a mainstay of computing technology
pretty much all along, but the need to port old scripts hasn't been a
big issue. Occasionally you will hear from people who wish they could
port their DCL/REXX/Bourne shell/who knows what scripts, but this is
usually a sign of their own confusion. Scripting languages are so
profoundly dependent on their environment - the things they're gluing -
that it's pointless to port only the glue, you have to bring along the
whole environment. Time to reimplement, rather than port.
Again, this probably goes back to confusion over what we're talking
about. Further drafts of this paper may help to clarify the subject
of discussion. A system that hopes to implement applications all by
itself might indeed want to be portable. If a scripting language is
one of the components of such a system, then the language has to be
as portable as the other components. What's as likely to happen,
though, is that the other components (e.g., graphics) are going to
much harder to port with satisfactory results, and you'll get better
results if you can replace those components with their natural equivalent
in the destination environment. With luck, you may have designed it so
that major wholescale rewriting isn't necessary ... and that turns out
to be the point of all the abstractions provided by the formal languages,
for example, OOP: to improve your luck in these situations.
Donn Cave, University Computing Services, University of Washington
donn@u.washington.edu
|