Re: A Dylan implemented on Common Lisp

[jeff@aiai.ed.ac.uk (Jeff Dalton)]

In article <D584q4.2E8@cee.hw.ac.uk> andrew@cee.hw.ac.uk (Andrew Dinn) writes:
>Jeff Dalton (jeff@aiai.ed.ac.uk) wrote:
>
>: You know, crocks and kludges are crocks and kludges regardless
>: of why they were put in the language.  Scott would like us to
>: think Common Lisp is a poor language because the design process
>: involved discussions among a number of people and -- heaven
>: forbid -- actual votes.  But in fact, Common Lisp is a poor
>: language only if its properties as a language make it poor.
>: Let's see the Dylan-based attackers deal with the actual
>: properties of the language rather than engaging in innuendo
>: about the design process.
>
>I can attack Common Lisp without defending Dylan.

I can attack Common Lisp too.  Indeed, there are many things I
would rather were different.  However, I've also found Common Lisp
to be a useful language, and many of the complaints we see on the
net get it wrong.  For instance, you say:

> Common Lisp almost
>killed of lisp application development because i) the fact that it is
>such a fat language (thanks to all those proponents of {Mac, Inter,
>Franz, Zeta, Foo, Bar, ...}Lisp who wanted all their favourite
>features retained) 

That's just false.  Common Lisp is not a collection of favorite
features of random Lisp varieties.  Common Lisp is very clearly
in the MacLisp branch of Lisp and is in line with the way that
branch was developing via LM-Lisp/ZetaLisp and various NILs.
If anything, it's a cleanup relative to ZetaLisp and MacLisp
(e.g. by having uniform scoping rules).  Moreover, a number of
things that were in MacLisp or ZetaLisp were left out of Common
Lisp.

The "Common" in "Common Lisp" refers to commonality between various
MacLisp successors, not to all of Lisp.  Indeed, the list of InterLisp
features that are not in Common Lisp is about as long as the list of
InterLisp features.  (Where are the spaghetti stacks, DWIM, CLISP,
DEDIT, etc?) Franz Lisp, by the way, is basically MacLisp, and
there are no specifically Franz Lisp features in Common Lisp.

As for Foo, Bar, etc, tell me something that was put in Common Lisp
because of, say, PSL or Cambridge Lisp.

>   combined with ii) the fact that all this fat
>functionality was not layered as a series of libraries included as and
>when you need them. 

That much is ok, in part.  But the implementations you usually
see are not the only ones possible.  Common Lisp has been packaged
as a shared library (WCL), just for instance.

>The consequence of Common Lisp being defined as a
>ball of mud 

You're either misunderstanding or misrepresenting how that phrase
is normally used.  It does not mean everything is built-in rather
than in libraries.  Indeed, for much of Lisp's history, a library
technology called autoloading was fairly common, as were libraries
that had to be explicitly requested (e.g. environment in Franz
Lisp).

>   was that a full Common Lisp implementation required, circa
>1988, about 12 Mb of VMem before you even started defining your own
>functions.

Bull.  I've used Common Lisp since 1985, and I've always been able
to use implementations that are smaller than that.

>C does not have these problems (remember that Unix Labs proverb
>'Language design is library design; and vice versa'). C++, with its
>current template technology does have such problems - templates are
>still a crock - but it's not as bad as the mess in Common Lisp. 

I have less trouble w/ running out of swap space than the C++
programmers here do.

>Remember C may be a bitch to program it can be made to run lean and
>fast on cheap hardware [...]   Common Lisp and
>CLOS may be better to program in, more elegant, safer, reusable
>etc. but it is never going to run lean and will only be fast on
>expensive hardware (don't quote me benchmarks for tak, think about
>cache/real memory residence and paging overheads)

It runs reasonably fast on my PC (given the speed of the PC). 
If a 386 is expensive hardware, I wonder what you think is cheap.

>and will require use
>of either expensive or inexperienced programmers.

Sure, let's get rid of all the expensive programmers.  Should
we kill them off or just let them die in the street once they
all lose their jobs?

-- jd