Given that the flaming on CL versus Dylan hasn't died down yet, I
thought I would cross-post something I put on comp.lang.dylan a couple
of days ago. My apologies to anyone who has already read it there.
* It's hard to see how Common Lisp can be viewed as anything other
than a major win. DARPA's goal in pushing it was to make it easy for
the AI research community to interact. At the time (early 80's), the
divergence between the versions of Lisp used by different groups was
so substantial that you would buy hardware based on who you were most
likely to interact with, so that there would be a chance that you
could collaborate. Common Lisp satisfied that goal wonderfully. The
commercial versions are excellent, and there are quite satisfactory
public versions as well, so anybody who wants to, and has a machine
that is hefty enough (more on this momentarily) can use it. The
degree of portability we experience now in the AI community was
impossible ten years ago. So, given its goals, I think Common Lisp
has been an enormous success.
* The glory and curse of Common Lisp is the huge set of standardized
libraries. By having huge standard libraries, there are fewer wheels
to reinvent, each with slightly different axle sizes and tire
requirements. This enhances portability, and thus was consistent with
the original goals for CL. On the other hand, the large image sizes
and complexity make it a pain to implement and hard to run on
(today's) small machines. But that of course wasn't what it was
optimized for. Look at Scheme: Much easier to implement, and runs
small programs fine even on an HP100lx. But writing large systems in
it is very painful because you have to write (or find) all the
libraries that are already there for you in CL, and worse yet, people
who try to put together large systems are in trouble unless their
libraries are insulated or compatible.
* I applaud the goal of making a dynamic object-oriented language,
taking the best ideas from Lisp, optimized towards the goal of
supporting mainstream computing. From the perspective of a researcher
who would like to see some of his code in classrooms, porting to Dylan
is likely to be much more palatable than porting to C++. If it takes
off, that is. Which means large collections of affordable libraries,
preferably portable across a variety of platforms. The situation in
the C++ community looks like a nightmare to me: Some developers cycle
through several libraries/frameworks, due to bugs and/or limitations,
pouring huge amounts of energy into understanding systems whose
concerns are far below the level of abstraction that we get "for free"
in Common Lisp and CLIM. My group's productivity would plummet if we
had to use something other than Common Lisp and CLIM.
* I wonder how much of the concern with program size is due to the
limitations of today's hardware. When 100MIP/128MB RAM/1GB disk
becomes the mean for PC's (and if you think it won't, contemplate how
badly people want video and hand-holding software, and what those
capabilities demand out of hardware), I suspect Common Lisp won't look
like such an elephant. On the other hand, the number of CPUs
appearing in things that don't look like computers will probably dwarf
the number of CPUs in things that do, and I don't think Common Lisp is
necessarily the best language to program toasters in.
==========================================
Prof. Kenneth D. Forbus
Qualitative Reasoning Group
The Institute for the Learning Sciences
Northwestern University
1890 Maple Avenue
Evanston, Illinois, 60201, USA
email: ······@ils.nwu.edu
voice: (708) 491-7699
fax: (708) 491-5258
==========================================
>From April 1 through August 26st:
====================================
Prof. Kenneth D. Forbus
c/o Prof. J. M. Brady
Department of Engineering Science
Oxford University
Parks Road, Oxford, OX13PJ,
United Kingdom
Voice: 011-44-865-273003
Fax: 011-44-865-273010
email: ······@ils.nwu.edu
====================================