>>>>> "George" == George J Carrette <···@delphi.com> writes:
George> John Ousterhout <······@tcl.eng.sun.com> wrote in article
George> <··········@engnews2.Eng.Sun.COM>...
>> Wow, there's been quite a party going on over here on
>> comp.lang.scheme!
George> There is always a party here. But I think the major reason your
George> paper struck a nerve has nothing to do with "languages being
George> left out" per se, but everything to do with the fact that lisp
George> people do not beleive in your fundamental assumption that there
George> is a difference between "scripting" and "system programming"
George> languages.
{stuff deleted}
I think there is a real important difference between a "scripting" and
"systems programming" languages. "scripting" languages are designed to let
you *manipulate* a certain set of *fixed* abstractions easily. "System
languages" are desgined to let you *create* new abstractions.
Sometime certain features that make it easy to manipulate abstractsions
(special syntax for example) makes it more difficult to add features that
let you create new abstractions (consider why C++ overloading drives some
people mad). Strong typing of floats versus int makes sense in C, but seems
completely crazy in Mathmatica, since in Mathmatica the abstraction you want
to manipulate are just numbers in the most abstract sense.
Perhaps these aren't the defintions Ousterhout been using, but I think this
is the defintion he should be using. Ousterhout is really making a
distiction that isn't totally meaningless. Perl is not like C or Lisp.
Notice that the distinction I'm suggesting is a fuzzy continuum. C and Lisp
differ in the way they support creating and manipulating abstractions but
they are more alike in flavor to each other than to Perl and Tcl.
The initial intent of the langauge designers effects the flavor of the
language. Ousterhout misses the point when he tries to classify "systems"
and "scripting" languages based on a set of features. He should be asking
why were those features added. You understand a langauge if you understand
why it has certain features and how those features interact with others.
Simply knowing what features it has give little insight into the language.
This is the main reason Ousterhout doesn't make a convincing distinction
between "scripting" and "systems". He's classifing langauges based on
features rather than the motivations for those features.
For example Tcl everythings is a string model is there because Tcl was
designed to be extended to include different and new base types. If you
added a static type system you have to allow users to extend the type
system. Not an impossible task but perhaps not worth the trouble given Tcl's
goal of providing a simple off the shelf way to integrate and control C
code. Tcl probably better viewed as a library that lets you build a whole
class of special purpose scripting langauges which all are designed to solve
a set of similar problems. i.e. maipulating abstractions written in C.
Since the set of abstractions in a "scripting" langauge is *usally* small
and well defined a type system probably does get in the way more than it
helps.
Perl has built in syntax for regular expressions rather than pushing this
feature into a library. Perl has lots of other features such as default
values and silly but useful syntaxic features to make writting a certain
class of programs easy. This was by intent not by accident.
Lots of langauges have special purpose features too. Mathmatica, Maple,
Matlab, and S-Plus are some examples of languages desgined with a specific
mathmatical bent. Mathmatica, S-Plus, and Perl to some extent under the hood
are really just Lisp systems, but they load on lots of special syntax and
the right set of built in primitives to make them easier to solve a certain
class of problems than any Lisp system could.
Ousterhout is making an important observation about different classes of
langauges, and he's not making this up. He's simply staring at the myriad of
langauges out there and noticing a pattern. His paper done a bad job of
explaing what and why this pattern is, but we shouldn't dismiss it out of
hand.