Best of all worlds, tools in the toolbox, etc.

[Dan Weinreb <address@hidden>]

   Date: Mon, 26 Nov 2001 22:42:03 -0800
   From: Lennon Day-Reynolds <lennon@day-reynolds.com>

   In essence, I'm just fickle. To put my own spin on your CLOS 
   comment, I think it's best to have the choice of *all* worlds, or 
   at least as many as are practical. 
   ...
   Object-orientation is one technique available, and is often a very 
   helpful addition to my toolkit.

That's true.  The real art lies in designing a language that does give
you all the choices you want, but avoid having a fundamental semantics
that's so extensive that it gets into serious complexity problems.  If
you just start throwing in everything that everyone wants, how do you
avoid a "kitchen sink" that's so big that it's hard to learn, and that
has lots of interactions between all the different aspects of its
semantics?  I'm not saying that it's impossible.  I'm saying that it's
a real art to do a good job at this.

In CLOS (and its predecessors "New Flavors" and, I think,
CommonLoops), the designers found a good way to make "object-oriented"
programming emerge as a natural extension of "procedural" programming,
rather than having two distinct and unrelated (or loosely-related)
mechanisms.

Sometimes, rather than having a language that has all the tools of the
toolkit, it can be good to separate the toolkit from the language.
That is, if some tool can be implemented as a library, it's usually
good to make it a library (with some exceptions allowed for things
that are very pervasive, such as integer addition).

Several serious and practical object-oriented language facilities were
added to Lisp as libraries (libraries not only of functions but also
of macros).  It was actually possible to get very far without any
modifications whatsoever to the underlying interpreter or compiler,
and still get very practical performance.  (In fact, does anybody
remember to what extent the late-model CLOS implementation *did*
include changes that were so deep that you couldn't do them as part of
a library?  I don't remember any more.)

What you want is to have a kernel language, that can be defined and
explained and understood all by itself.  If the kernel has N concepts
in it, you'll probably have to worry about a pretty good-sized
fraction of N-squared interactions, so you really want to keep N
small.  But the kernel should be strong enough to be a basis for lots
of possible libraries of new functionality.  (I think this is similar
to the first point that Guy Steele made in the panel session.)