ouster@tcl.eng.sun.com (John Ousterhout) writes:
> One of the most common criticisms of my white paper has been that the
> distinction between scripting and system programming is artificial, and
> that it is possible for a single language to be good at both tasks.
> Lisp-like languages such as Scheme were suggested as living proof. I
> can't prove that it's impossible for a single language to be good at
> both scripting and system programming, but I don't know of a good example
> and I doubt that it will ever happen. The reason for this is the
> difference in typing, as I explained in the white paper. A given language
> embodies a particular style of typing, which can range from very strongly
> typed to totally untyped. Once that decision has been made, the language's
> position on the spectrum between system programming and scripting is set.
> I think it's possible to have a language that's in the middle, but it's
> not likely to be terrific at either task.
>
> Let's take Lisp as an example. [..]
Since Lisp is dynamically typed, according to your hierarchy of
typing, it is in the middle between TCL and C. It is then easy to make
your point.
But you have completely ignored here another thread of comments: there
exist now typing systems that both are stronger than C, and give you
(almost) as much programming freedom as Lisp.
Typically, when one speaks of "strongly typed" languages, this is
talking about strongly typed functional languages, like ML or
Haskell. Strong here means both that the constraint is stronger --you
do not use cast in these languages, meaning types give you absolute
security--, and that the expressive power is strong --otherwise you
won't be able to write in such languages.
There was an example a while ago in TkGofer: did you realize that it
was _strongly typed_. You can express things with the same concision
as TCL, and be more strictly typed than JAVA !
I do not contest the expressive power of TCL (as a scripting
language), and even think that it's syntax to use the Tk library is
very nice. That is why we intended to stay as close to TCL as possible
in the LablTk library. This library is built on Objective Label, a
derivative of Objective Caml, in the ML family.
Let's see a small example:
(TCL)
button .b -text Hello -font {Times 12} -relief sunken
(LablTk)
let b = Button.create parent:top text:"Hello" font:"Times 12" relief:`Sunken
Again, the syntax is not more difficult. Allegedly a little bit more
verbose, but not really bothering. The difference is that everything
that can be checked is checked at compile time (or even before, using
the interactive editor):
* that Button has text, font, and relief configuration option
* that sunken is a valid relief
In order to do this, we had to extend ML's type system, which is
already powerful, in two ways: labeled and optional arguments, and
polymorphic variants (the `Sunken). But this was possible, keeping all
the nice properties.
So, how such a language compares to Tcl. The essential difference is
that you can write and manage big applications in it, and do not need
to use a specific scripting language for the GUI. One could even think
of allowing scripting and extensions in the language itself (dynamic
loading is already available).
Speed also: very fast bytecode compilation should give you code
already orders faster. And you can also use a native code compiler to
compete with C.
OK, what's my point. Not that this language is the solution to all
problems. But that in the future languages and type systems of this
kind will undergo huge progresses, and eventually make irrelevant your
distinction between system and scripting languages --at least for
applications. Let's call them "strongly typed" languages (that's
what they are called now).
Will C then disappear ? I do not believe so. I think that we should
rather use a 3-level classification, if we want to follow your view.
* Low-level, system programming languages, for really computation
intensive or very low level tasks: C, C++ (I don't believe JAVA fits
in here)
* Application development languages: C++, JAVA, "strongly typed"
languages, and many other
* Script languages: Tcl, Guile..., "strongly typed" languages
I do not know the end of the story, but since low level tasks will be
more and more delegated to drivers and libraries, I think the ability
to handle the last two kinds of programming in a uniform framework is
an important one.
---------------------------------------------------------------------------
Jacques Garrigue Kyoto University garrigue@kurims.kyoto-u.ac.jp
<A HREF=http://wwwfun.kurims.kyoto-u.ac.jp/~garrigue/>JG</A>
|