Re: A Dylan implemented on Common Lisp

[andrew@cee.hw.ac.uk (Andrew Dinn)]

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. 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) 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. The consequence of Common Lisp being defined as a
ball of mud was that a full Common Lisp implementation required, circa
1988, about 12 Mb of VMem before you even started defining your own
functions.

If you add on top of this the overheads for CLOS (which is also not
layered and hence made Common Lisp an even bigger ball of mud) then
you can change thet 12 Mb to 20 Mb.

*Circa 1988* those were big numbers, hence the death of Common
Lisp. They still are quite big, actually.

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. If
Dylan can avoid falling into this pit then it might have a chance.

Remember C may be a bitch to program it can be made to run lean and
fast on cheap hardware and most developers think the cost is just the
salaries of a few good (cheap) C hackers i.e. it answers their
priority numero uno and they cannot see the drawbacks. 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) and will require use
of either expensive or inexperienced programmers.


Andrew Dinn
-----------
O alter Duft aus Maerchenzeit / Berauschest wieder meine Sinne
Ein naerrisch Heer aus Schelmerein / Durchschwirrt die leichte Luft