Complexity, yet again

[David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>]

    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
    machine....
    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
    switch modes.

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.