Standardization (ugh)

["Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>]

I think Handerson misses the most important reasons for standardization:
stability and sharing of code across the largest possible community.  I
want to learn *ONE* object-oriented system to the point where I can use
it well, write a lot of code in it, and I want that system to be the one
that all my friends use so that I can borrow their code and they can
borrow mine.  I want this one system to be efficient enough for systems
programming (though that DOES NOT mean that I'm willing to sacrifice a
lot of elegance for that last 10%) and I want it to be clean enough so
that I don't get mad every time I use it.  I don't want to invest a lot
of effort in a system whose users don't really like it; such a system is
likely to go away as soon as something good comes along.

I think the optimal plan for this group is the following:

(1) Define a minimal set of low-level hooks that can support a
variety of object-oriented systems.

(2) Implement a portable Flavor system -- there's a demand for this,
even if we eventually move to something else as a standard.  However, we
should try not to let Flavors creep into other essential parts of the
system.

(3) Try to come up with a system that we all like better than Flavors.
This group is the right set of people to work on that, and the longer we
wait, the harder it will be to get people to switch.

(4) Implement this new system in a protable way so that we can play with
it and refine it.

(5) Maybe someday, if the new system becomes popular, accept it as a
white-pages standard.

-- Scott