[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Complexity, yet again
Date: Tue, 24 Sep 1985 22:11 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
In this note, I would like to respond to one point you made that I think
may be important and very relevant to this discussion: the one about
wanting things to be modifiable forever because you never reboot your
Flavors wants full runtime modifiability and the absolute maximum in
efficiency, so it makes the latter choice. Well, almost...some things
would just be too expensive to fix up, so they don't get fixed; others
are fixable, but only at a cost the probably doesn't want to pay. Once
there are a few of these exceptions, you can't just tell the user to
change what he likes and to just trust the system to keep everything
consistent. The user has to more or less understand how the fixing-up
process works and what its limitations are. And this, I think is the
biggest unavoidable cognitive load on the would-be user of flavors.
Because of the combination of maximum compilation, arbitrary load order,
and runtime flexibility, the consistency machinery is very hairy, and
there's no simple lie that you can tell the user that will allow him to
ignore it all. I'm pretty sure that this is a fundamental problem and
not a documentation issue.
I wish you would be specific. I spent some time trying to guess what in the
world you could be talking about. I came up with two things: (1) you have to
call the function recompile-flavor sometimes (but that bug was fixed about
three years ago, and in any case was an implementation shortcut, not a
language issue); (2) when you change the number of instance variables in a
flavor that has already been instantiated, existing instances break (this
isn't a language issue either, since it's easy to fix, is fixed in your
student Handerson's implementation I believe, and is fixed in my
implementation (which you haven't seen, so I can't fault you for not knowing
about it.)) Except for this, I can't think of any exceptions to the rule that
you can change what you like and trust the system to keep it consistent, which
of course is a rule to which every program development system ought to adhere.
Have I correctly guessed what you're talking about, or are there some real
fundamental problems that I'm overlooking?
....I am willing to divide my life into phases: when I'm
messing around and doing exploratory programming, I'm willing to suffer
a modest loss of efficiency -- say, a factor of two overall. When I've
got the system the way I want it, then I want to be able to compile out
all the flexibility to get the very last drop of performance. the
excess complexity of flavors comes from wanting both of these things AT
THE SAME TIME. I'm willing to accept one or the other at any given
time, and to recompile and reload the universe when the time comes to
In my view, forcing the user to choose between exploratory and production
modes would be an increase in cognitive complexity, not a decrease!
By the way, I am not saying that CommonLoops does better according to
these goals -- just that they still have an opportunity to do so,
depending on how various issues get resolved.
Thanks, that wasn't clear to me from your original statement. The really
important thing is that we all (I hope) agree that it is important to decrease
the apparent complexity of object-oriented programming as perceived by today
and tomorrow's users. Your comments are helping, but I'm still trying to get
a grasp on the exact nature of that complexity.