Path: utzoo!mnetor!uunet!husc6!bu-cs!bzs
From: bzs@bu-cs.BU.EDU (Barry Shein)
Newsgroups: comp.lang.lisp
Subject: Re: FORTRAN,ADA
Message-ID: <18004@bu-cs.BU.EDU>
Date: 27 Dec 87 02:49:20 GMT
References: <4732@well.UUCP> <525@PT.CS.CMU.EDU> <453@athos.rutgers.edu>
Organization: Boston U. Comp. Sci.
Lines: 56
In-reply-to: hedrick@athos.rutgers.edu's message of 17 Dec 87 21:14:11 GMT

Posting-Front-End: GNU Emacs 18.41.4 of Mon Mar 23 1987 on bu-cs (berkeley-unix)



I've had my misgivings about CL, and there are certainly dubious
features I would have thrown out the window (the most dubious of which
is probably multiple-value-returns, there simply to support some
machines with a little fast stack hardware, I mean really, why not
just return a list even if it's faked onto the stack?) but I find it
useful nonetheless. I mean, car is car and all that.

In fact, it's not the "bigness" that's the problem. The perceived
bigness is mostly due to the minutiae it deals with (most of which is
reasonably useful.) Rip everything out of the CL book that you didn't
need to read and I think you won't find a whole lot left (assuming
you've been around the community, that's not a criticism by the way.)

The problem is how little it standardized, that's where I think the
final evaluation of CL will find its criticisms.

The fact that it doesn't cover things like fonts, windows, networking
primitives (well, sort of), object-oriented interfaces, real operating
system environment details (eg. a mandated file system view rather
than "oh, it'll take whatever string the host system does"), debuggers
and other development tools etc etc is the problem.

Without dealing with these issues one ends up with a relatively
non-portable language because all these things end up in programs
anyhow and just create problems. The lack of devpt environment details
of course impacts the portability and standardization of people.
Swell, now we got Lucid/Sun hackers who would probably be totally lost
on a lisp machine CL.

Now, I'd be the first to admit that getting all that right would have
been hard and a lot of work (no one said claiming to have standardized
LISP was supposed to *easy*), but I think it was critical to its
possibility of finding any large-scale commercial success.

The problem was that too many people were thinking in terms of some
least-common denominator, they should have subsetted that perhaps. I
have little doubt that the conversations between the DEC/VMS folks and
the Lisp Machine community (LMI, Symbolics, Xerox) must have been
amusing at best (fonts?! no fonts no way, heck, we don't even want
lower case!!)

It really was a case of a standardization of a language within a
least-common denominator view as it existed some time in the late 70's
on largish dumb-terminal oriented time-sharing systems. That's too bad
but it's not surprising, such people tend to have had their 10+ years
under their belts and got their way via seniority, so we got a
standard that looks real compatible with a DEC-10 just as the last one
rolled off the line...I guess standards have a way of looking
backwards only.

It would be nice to hear that people consider the possibility of a
Common Lisp '90 or some such is open to discussion. Perhaps there's
still a chance to make it a viable language and reflect modern needs.

	-Barry Shein, Boston University