[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
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!).
First, some general views on what makes a software system seem simple or
[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
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
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
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
- From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>