CommonLoops

[Robert W. Kerns <RWK@SCRC-YUKON.ARPA>]

    Date: Mon, 23 Sep 1985  22:28 EDT
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
	 The image I have (admittedly an exaggeration) is of a minefield: if
    I want to get from point A to point B, you can show me a simple path;
    for the beginner, however, the hard part is in knowing where NOT to
    step.  Commonloops (so far) has fewer mines and they are all in a couple
    of well-defined areas, not sprinkled around all over.
I don't disagree, but I won't be sure of it until it has been
used for a while by people entirely new to object-oriented
programming.

		 So the question is not whether I'm right or wrong about
    flavors being hairy; the question is why so many people THINK it is
    hairy, and what (i anything) can be done about that.

As DDyer points out, a lot of why people think of flavors as
hairy is they quickly get deeply involved into the window-system.
Once into the window system, they quickly get overwhelmed by all
the different optional mixins, ways of putting things together,
bad modularity, missing documentation, etc.  I'm sure it's not
the only reason, but it IS hard to factor out.

(Making the window system easier to use is obviously a prime target.  I
don't believe the window system is hairy because of the flavor system,
just that the flavor system LET the window system be hairy).

    I'm writing this when I really should be doing a bunch of other stuff,
    so this may not end up being as coherent as I would like.  But anyway,
    here are some of my thoughts on why Flavors seems gratuitously hairy to
    me -- more hairy than, for example, CommonLoops.  Of course, hair is
    in the eye of the beholder (ugh!).
Excuse you!

    First, some general views on what makes a software system seem simple or
    complex.
[General views deleted for brevity.  Suffice it to say: well said].

    I think that the Flavors system (as described in the Gray edition of the
    Chine Nual, which is the version I happen to have handy) does rather
    poorly by all of these criteria.  

Do me a favor, and donate that edition to your local computer museum.
(ESPECIALLY anyone else who ONLY has a copy of the Chine Nual!)  The
damn thing was done when the company was only a year old, as a minor
update to something done before there WAS a Symbolics.  It is now 4
years and two entire versions of the documentation later.  The volume
(Vol 2 of 9) that contains the language reference material alone is
almost twice the size of that old relic.

That said, I notice that the description of flavors therein hasn't
changed much.  So a lot of your comments still apply, at least to some
degree.  But it does make it harder sometimes for me to figure out
whether what you're saying has any modern relevance.

The containing volume IS labeled as a reference guide.  (I don't think it is
bad as a reference guide, although I could be blinded by knowing it already).
While there isn't a a lot that it specifically flavors, there is a lot of
"here's how you do something using flavors" documentation in other volumes.
(Sadly, the window-system makes these much hairier than they should be).
I'd be interested in your comments on this more modern documentation.

				      I won't dwell on the small
    inelegancies, except to note that the system has a bunch of these.  For
    example, the gettable/settable/initiable options for instance variables
    should be on by default, with with an option to turn them off; as it is,
    even very simple flavor definitions must be cluttered up with
    odd-looking keywords.  There are several things like this that increase
    the general level of clutter and make flavors code LOOK hairier than it
    is.

I don't think I like this idea.  It's like making all symbols of a package
be exported by default.  But that's irrelevant to your point; can you give
me another example that I don't have this reaction to?

    The documentation is a big part of the problem with flavors, I think.
    There are a LOT of complicated little options and features and
    specialized functions (such as Instantiate-Flavor) that are all mixed in
    with the stuff that the average user needs to know.  It may or may not
    be the case that each and every one of these is necessary for doing
    advanced system programming in flavors (some of them look like real
    kludges), but if they must be around they should be put in a special
    "hairy flavor wizards only" section of the manual.  The first few times
    I tried to read the document, I started to falter when I hit
    Instantiate- Flavor, and I was totally confused by the time I made it to
    the section on Defflavor options (which finished me off).

This is better in the current documentation.  Although I think that
most of the chapter that now contains INSTANTIATE-FLAVOR should come
about 7-8 chapters later, at least it is in a separate chapter of
more obscure stuff.  (It is worth noting that INSTANTIATE-FLAVOR
is used only 20 times in the system, 2 of them inside the flavor
system!)

    Examples are very important -- without them, the documentation has to be
    perfect -- and there are essentially none of them in the manual.  Worse,
    there don't seem to be any relatively simple flavor-ized programs for
    people to look at anywhere in the world.  At least, we got no response
    when we asked for pointers to such things.  So people have to read the
    manual and then start writing their own code without a template, or else
    they have to look at something like the Symbolics window system.  That
    is not a good way to persuade people that flavors are simple.

Sorry nobody responded.  But there's a couple of problems.  Every time
anyone goes and writes a simple example, they fall prey to the urge to
make it DO something.  This gets them involved in the window system.
The other problem is that a lot of examples make very simple use of
flavors, and so don't illustrate much.  I don't know of any examples
off-hand that avoid BOTH problems.

But you might look at SYS:EXAMPLES; on your local Lispm.  The CALC
example is fairly simple.  Probably the hairiest thing is supplying
some default values for the window flavor.

    I should also mention that the few times I have tried to read
    production-quality flavors code (in various parts of the 3600 software),
    I have had a very difficult time finding the places where some code
    actually does something; most methods seem to just do a Send to
    somewhere else, along with doing a tiny bit of what has to be done.  I
    would suggest that an important goal of good coding style in these
    systems is to make it easy for the user to find where the action really
    is, or else to clearly specify what the total effect of calling a
    particular method is.

There are a lot of tools that make this easier.  (Most of them
invented since 1981, I think).  Still, your point is worth
considering.  But I'm afraid I don't see how your problem
was due to flavors, per se, or how CommonLoops solves it.
Can you say a little more about this?

I deleted the rest of your remarks (about complexity of flavors being
the attempts at delayed binding), because (I confess) I haven't more
than skimmed the CommonLoops stuff that's come by, meaning to get to
it later.  (I'm pretty sure the people here who are working on our
flavor system have paid more attention).

I will comment that being able to preserve the ability to redefine
things on the fly is much more important in an environment where you
don't boot for a month at a time.

(uptime 'crow) ;My machine
CROW                     2 weeks 5 days 18 hours 31 minutes 38 seconds

In an environment like a Lisp on a conventional system, your system
administrator would turn off your account if you stayed logged in for a
month running Common Lisp.  I confess I don't know whether this would be
a problem with CommonLoops or not.

It's too bad, too, since I guess this was your more important point,
and I understood it the least.

    I don't know how clear any of this is, and I'm sure that you will think
    that some of this is off base.  I've tried to give you a general idea of
    why flavors LOOKS hairy to me, without thinking too hard about which of
    these concerns are really justified and which are just misconceptions
    and lack of experience on my part.  But I guess it is the perceptions
    that are of interest here.  What it adds up to for me is that I'm eager
    to try CommonLoops and I hope I never have to write anything serious in
    flavors.

Thanks for sharing your perceptions, it is indeed valuable information.
I'm forwarding your comments to our documentation people here, and I
guess I should get off my ass and find time to read this proposal
more carefully.