T and franz

[Olin.Shivers@CMU-CS-H]

Hmm. It strikes me that there have been a good many wild claims made on
both side of this argument.  Maybe I can clear a few up.

The professor that announced we shouldn't use franz was Geoff Hinton.
As you will note, he also warned against using Common Lisp.
    04-Feb-84 16:13    Geoff Hinton at CMU-CS-A     AI qual task
    As I announced in the last lecture, the programming task will
    involve writing a search program that runs fast. We have decided
    NOT to test your common-sense in choosing a language, and so you
    are hereby warned that Franz Lisp and common lisp on the vaxes are
    rather slow and you will be at a big disadvantage if you use them...

Mr. Fateman says that "early papers on T claimed it was 40 times faster than
Franz." I've never heard such a claim.  There has only been one paper published
on T ("T:  a Dialect of Lisp" in the Conference Record of the '82 Symposium on
LISP and Functional Programming, August 1982).  I just read through it again; it
makes no claims at all about speedup factors over franz.

Fateman certainly has one point to be reckoned with: if you want to run
any number of the large, useful programs that haven't been written in T,
(Macsyma, for instance) you can't use T.  There are plans to implement
Common Lisp, et al. in T, but they are pretty far down on the queue from
what I hear.

Of course, the reverse is true, although the crying need to import software
written in T has yet to be established.

In general, I don't think much of compatibility issues with respect to
evaluating languages. People who tell me that T is bad because it isn't
compatible with older lisps sound like people who tell me that Fortan and
Cobol are great languages because there is so much code written in them.
It reminds me of Steele's comment in a Common Lisp draft to the effect
that "yesterday's radicals are today's conservatives." There is a certain point
in language design beyond which you cannot go if you are going to limit yourself
to compatible designs.  I can't claim that T is trivially portable in franz or
Interlisp, but I do think it is what lisp ought to be.  If you need to port
software written in brand X lisp, then run brand X lisp. If you are writing
new software, I bet you'd be a lot happier doing it in an efficient, lexically
scoped lisp. Like T.

Mr. Fateman apparently thinks I claim that "(3) CMU professors like it [T]
and hate the sight of franz." Not at all. *I* like T and hate the sight of
franz; the professors will have to speak for themselves.

I have to disagree with Fahlman, who says that franz "doesn't have a
reputation for slowness, except among those people who think all Lisps are
slow." He's the first I've heard at CMU defend franz's speed. Most of the
lispers I know -- people who think lisps don't have to be slow, if done right --
hold franz to be at the slow end of the spectrum. The only fast lisps I know of
are Maclisp, Zetalisp, and T.

Barry Shein claimed that "tons of it [T] is written in LAP (i.e. assembler)."
I just went and checked through the sources here at CMU.
	    T               T&LAP               C               Vax Assembler
#Files      79              2                   1               1
#Lines      13,000          1,500               314             50

Among the stuff written in T I found the code for the evaluator, the garbage
collector, the reader, and the bignum package.  So to reiterate my claim, T is
written in T.  90%, anyway.

Those statistics don't include the moby compiler or the 3,000 T lines of
utilities (loop packages, hash tables, etc) many people use.  They also don't
include the lap code used for the Apollo and VMS kernels -- I only counted Unix
lap code.  It was also a quick check, and it was an old T (2.6).  The new T
(2.7) could have different numbers.  The implementors are always trying to
shrink the non-T kernel.  But you get the idea.

Too bad Barry had such a rough time getting T up at Harvard. I had no problems
here at CMU. I'm currently writing a large 3D hidden-surface graphics system,
and having a very pleasant time.  Maybe he had an old, not-very-portable
version?

Why do I think T is so great? Two major reasons. The first is all the wins
you inherit when your default scoping is lexical:  correct procedure
open-coding, compiler optimisations, modularity, tight control over the
environment that any function executes in, and compiled semantics equal to
interpreted semantics. Second, over and above the scoping issue, I think
Rees has done a brilliant job of language design. He's designed a language so
clean, elegant and powerful it brings tears to your eyes. Razor's edge
semantics. The right stuff. For instance, Fateman points out that franz
has good data types for systems programming because one can generate C-like
declarations. But T goes beyond integers, characters, structures, floating point
numbers, etc and gives you wild things like pools, populations, and weak
pointers. Just the thing for systems hacking.

Of course, as Mr. Fateman would be the first to point out, the last half of
that previous paragraph is unsupported opinion.  My advice is:  get a copy of
the T2.7 manual and generate your own opinion.

So, the points about T:
    -Great language, considered in isolation
	-Fast
	-Elegant
    -But not compatible with franz, interlisp, etc, etc.

It's difficult to explain in a bboard post why lexical lisps win, so in
closing I will once again urge people who want to know what all the
shooting is about to read the Sussman&Steele papers.
				-Olin