C - eunichs

[buff@pravda.cc.gatech.edu (Richard Billington)]

First, thanks to Dave Magerman for being such a staunch supporter of C in face
of so many rabid lispm users. No sarcasm. I think it's really valuable to have
someone who's been a pretty substantial user give us a bunch of shit so we
don't rest on our laurels ... and fade away (which the lisp community is in
danger of doing).

I'm quite amused to see Dave taking on this role. I gave him his first job on
lisp machines. He wrote a nice little window-oriented system for entering and
reducing lambda calculus expressions. The expressions were displayed in tree
form and he used presentations to show where you could and couldn't make
additions to the expressions, and to point to sub-expressions you'd like to
have reduced (if possible) and animate the reduction. This was developed as
the first part of a teaching tool. From the time he first sat down at a lisp
machine until he had the whole thing running was less than a month. One of the
profs in the dep't saw it and said that while he was at CMU they'd spent "a
few months" trying to get such a thing working in C ... and it sort of worked,
but not really.

Since i/o is a major target of this discussion, let me just relate a story
we're in the middle of right now. We're running a quarterly level-0 dump of
all of our file systems by NFS mounting them to our central server and dumping
them - a very conveniant capability (lispms included). However, we've been
trying to complete this since the 1st of the year. Why aren't we done? The
dump progresses from machine to machine until some trivial error causes it to
bomb, and we have to begin all over again. We're backing up enough file
systems that we estimate this is about a 24 - 36 hour job total. The error can
be as trivial as our network being saturated for a time long enough that the
program times out. Boom (or does one say SCUD these days). Now, on my badly
maligned lispm, when some file system operation bombs for even the most
trivial reason, I find myself in the debugger with the option of continuing
AND with a rather complete view of what the problem is. So, if my dumper were
on a lisp machine, it'd probably take 10 times longer than the C - unix
version, but I'd be done by now.

Finally, portability: The last time I did any C programming (which was for a
compiler course in which we HAD to use C 'cause the assignment was trivial in
Lisp) I had trouble calling library functions. It turned out that exactly
where the library's are, exactly what they contain, and exactly the syntax one
uses to refer to them in the #include statements varies from implementation to
implementation, just a bit, and since it's all *pretty* standard and well-known
these differences aren't well-documented (if at all - I gave up on finding out
and just did some guessing until it worked).

As a footnote: lisp is not the same as common lisp. There are some extrememly
efficient implementations of scheme for micros (MacScheme for the Mac, e.g.),
and I'll take them over C anytime. They're still lisp.