T and franz

[Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>]

Well, I wanted to sit this one out, but feel I must respond to a few of
the points that were made.  Just to expose my biases, I've been rather
heavily involved in the Common Lisp specification effort and have been
more or less in charge of the Common Lisp implementation efforts for
Perq and Vax.  I've studied both Franz and T and have played with them,
but have not written large amounts of code in either.

I'm sort of on the fence about lexical scoping.  We used it in Common
Lisp as the default, though dynamic scoping is available via
declarations.  Lexical scoping makes things like closures a bit cleaner
and enables the compiler to produce better code in some places because
it can see all of the relevant context surrounding a form.  It also
slows down the interpreter a good deal.  I think I'd stay with lexical
scoping if we had it to do over again, but it's not a big deal.  The
average programmer will hardly never notice the difference, except when
he gets into closures.  I would not use a Lisp that didn't provide some
sort of dynamic scoping.  There are times when you need that and nothing
else will do.

I'm not sure which CMU professor forbade his students to use Franz.  It
wasn't me.  A lot of people here consider Franz a bit flaky -- there are
still some bugs and there is not as much runtime checking as in Common
Lisp -- but it doesn't have a reputation for slowness, except among
those people who think all Lisps are slow.  Of course, any large Lisp
program will seem slow on a crowded Vax with insufficient memory for
everyone's working sets.  The limited benchmarks we have run seem to put
Vax Common Lisp and Franz at about the same speed right now.  People at
DEC are working hard to speed up the Common Lisp; presumably there are
some people working on the speed of Franz as well.  My guess is that for
real work T is somewhat faster, maybe by as much as a factor of two.  T
is a simpler language and can therefore be compiled more tensely, making
better use of registers for argument-passing.  Unfortunately, the wild
claims that the Yale people initially made about the speed of T tend to
cast serious doubt on any further benchmarks they might provide.  I
don't know of any independent studies of T's speed.

DEC never abandoned Steele's Rabbit compiler because they never
considered using it in the first place.  They are using my compiler,
originally developed for the Perq, with a different code-generator and
post-optimizer.  This is not a super-optimizing compiler, but it is not
pessimizing either.  Its main drawback is that it uses the stack a lot
and does not make optimal use of the registers for argument passing.
Its main advantage is that it has been available and working for some
time.  A super-optimizing Common Lisp compiler is being written for the
S1 by Dick Gabriel, Rod Brooks, and (in earlier times) Guy Steele.
Whenever this is done, it will probably replace my compiler as the
portable core for other Common Lisp compilers.  DEC will probably adopt
this technology whenever it is ready.  The delays seem to be more a
matter of personnel and support than technical problems.

I must agree with Fateman that T is considerably less interesting than
it might be because of the large differences between it and earlier
Lisps.  Maclisp, Franz, PSL, Zetalisp, and Common Lisp are all pretty
close together, and the prospects for large-scale migration of code
among these languages are excellent.  Interlisp -- the programming
language, not the total programming environment -- is also an easy port
away.  T and Scheme are different enough that they will have to thrive
on the basis of home-grown users and applications and not on immigrants
and foreign trade.  Maybe they're superior enough (and the Yalies are
energetic enough) to pull that off -- I don't know.

In the end, I think that the attractiveness and value of any Lisp
environment is going to depend almost exclusively on the number of
active researchers using it (and using closely-related dialects).  The
inherent quality of the Lisp is a second-order effect.

-- Scott Fahlman, CMU