[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A Dylan implemented on Common Lisp



andrew@cee.hw.ac.uk (Andrew Dinn) writes:

>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.

This is a tiresome argument, shared libraries solve this problem.

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

Maybe it needs a kick in it's *big* behind, but Common Lisp is certainly
*not* dead.  Granted, it's not cuddly and cute like Dylan is now, but
instead of delivering last rights, why not breath life into this new
standard by focusing on the handful of corrections needed to make Common
Lisp a mainstream delivery vehicle.  We should be resolving all the
fixes needed for the next Common Lisp standard, not planning for a
funeral.  Scott Falhman gave up on the process, not the language.
-- 
jpf.