Unpleasantness

[gjs@ZOHAR.AI.MIT.EDU (Gerald Jay Sussman)]

    Usually I refrain from becoming involved in squabbles about the
apparent quality of one or another person's code.  I can remember such
arguments when I was very small -- something of the form "My daddy is
bigger and stronger than your daddy.", so it usually feels a bit
childish to fight about things like that.  In this case, however, you
have said some rather unpleasant things about very good friends of
mine, and they are feeling quite bad about it, so I feel compelled to
respond.

In defense of CScheme.  
    I teach 2 subjects at MIT that use Scheme as an integral part of
the methodology of teaching.  Abelson and I are in charge of the
introductory computer science subject, where we use SICP.  This
subject serves a population of 700 students each year.  Abelson and I
also are involved with our introductory subject in Circuits, Signals
and Systems, with about 500 students each year.  In both of these
subjects we use a Scheme system produced by those friends of mine you
have insulted.  We use CScheme in the CSS subject and a previous
version of Scheme written for the HP Pascal P system in the SICP
subject.
    In running such large subjects it is essential that we have
excellent software, because even a small problem can become an
educational disaster.  Thus, I can assert, with considerable
experience, that the Scheme software we use is of outstanding quality.
It is clean.  It is maintainable.  It is reliable.  I can be sure that
when I put out a problem set that the students will not get the system
into bad states and that their bugs will be clearly indicated with
clear error comments.  I can be sure that the Scheme system will not
crash, even under the relentless pressure of hundreds of smart
undergraduates.

You complain about some strange things:

	Writing nonprimitives in C.  My eye happened to fall on
	list_to_string, which is about three times longer and more
	complicated in C than in Scheme.  What earthly reason could
	there be for this?  I suppose it could be worse; KCL is an
	example.  On the other hand, even KCL doesn't put a Fast Fourier 
	Transform and a regular expression matcher in its C "microcode"...

    I can see nothing wrong with this, but I am willing to take
responsibility for it, since I can explain it rather easily...  Even
KCL is not used in an introductory subject on Signal Processing.  It
just so happened that we had an excellent FFT, written in C by Yekta
Gursel.  I needed a good FFT for my subject, so Panayotis Skordos, one
of my star graduate students, who was a teaching assistant for me in
the subject, installed a slightly modified version of the Gursel FFT
into the CScheme kernel for students to use in the course.  It seems
to me that we Lispers would be fools not to use good code that we can
get from someone else.  Do YOU want to write me a procedure that
computes Bessel functions? -- I can probably buy a better one from
IMSL.  In fact, that we can assimilate code not written in Scheme is
one of the virtues of the MIT CScheme system.

I assert, and I believe that I can do so with authority, that CScheme
is an excellent system that reliably and effectively supports teaching
of massive subjects at MIT.  I have tried a number of other Lisp
systems, including PSL, and of those I have tried I have found no other
systems, except for possibly TI PC Scheme or Semantic Microsystems'
MACScheme that could stand up to this rigorous a test.


Strategic Considerations
    You also object to a number of organizational decisions that were
made in CScheme, indicating serious ignorance of the historical
context of the system.

	Gazillions of builtin types.  There are twice as many
	primitive types of objects as any other high-level language
	that I know of (3- and 4-element hunks? give me a break!).
	Many could have been built as nonprimitives.  See T for good
	efforts in that direction.

	Attempts to optimize the C code implementing a virtual
	machine.  If you use a virtual machine, you've already lost
	speedwise; doing complicated C hacks isn't going to recover
	much for you. (Presumably that's the reason for hundreds of
	C macros that could have been function calls.)

Again, though I find nothing wrong with virtual machines (note that TI
PC Scheme uses a virtual-machine strategy and it is roaringly fast) I
am pleased to take responsibility for this.  What you do not know is
that CScheme evolved from the actual microcode for the Scheme-81 chip,
a special-purpose architecture for executing the Scheme SCODE language
efficiently.  The CScheme system started as a simulator for the actual
Scheme-81 machine.  The SCODE language is an experimental machine
language.  The plethora of types you refer to are the opcodes of that
language.  They have nothing at all to do with the user's types.  You
should be amazed at CScheme's excellent performance, considering that
we had not contemplated running it on a conventional architecture at
all.


Summary
    I feel that your allegations are unfounded and ill considered.
However, I want you and everyone else to know that I am part of the
reason why some of the things you object to came out the way they did.
I suggest that we stop arguing about such things in public like little
children.  I will stop if you do.  I also suggest that if you want to
fight out the technical details I will be pleased to meet with you at
the Lisp Conference in Snowbird.  Perhaps we will both learn something
useful in that context.


			Gerald Jay Sussman,
			Professor of Electrical Engineering,
			Massachusetts Institute of Technology.