Re: A Dylan implemented on Common Lisp

[davis@ilog.fr (Harley Davis)]

In article <D584q4.2E8@cee.hw.ac.uk> 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.

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

Right on, dude!

Fortunately, there are alternatives for those who like the
productivity and the parentheses but can't stand the size.  Our
commercial product Ilog Talk has a minimum application overhead (on
most 32 bit machines) of 600k of code in a shared library and 400k of
dynamic data; we're looking to make it even smaller.  This basic
library includes a full-featured Lisp runtime with a MOP-based object
system.  Other libraries are also available.

For more information, check out our Web page at
<URL:http://www.ilog.com/> or write to info@ilog.com.

-- Harley Davis
-- 

------------------------------------------------------------------------------
Harley Davis                            net: davis@ilog.fr
ILOG S.A.                               tel: +33 1 46 63 66 66
2 Avenue Galli駭i, BP 85                fax: +33 1 46 63 15 82
94253 Gentilly Cedex, France            url: http://www.ilog.com/

           Ilog Talk information: info@ilog.com