Re: hooks vs. subset (last try)

[Tom Bylander at Ohio State <BYLANDER@RUTGERS.ARPA>]

It seems to me that there is a goal conflict corresponding to the
type of programming that people want to use an object-oriented
language/environment for.

1) System programming.  As I understand it, a major use of Flavors is
for programming of essential data types, e.g., the window system.
Such a use demands efficiency (even "modest gains" -- enough modest
gains and sooner or later they all add up to big gains) with perhaps
some cost in understandability, elegance, ease of use, and the like.

2) Research programming.  People (like me) use an object-oriented
system to gain leverage on understanding a system which represents and
perhaps eventually solves difficult problems.  This use demands
understandability, etc. since it is hard enough to thoroughly
understand the problem without the programming system getting in the
way.  This becomes especially important when more than one person is
involved in coding.

3) No programming.  Many people already have large, complex programs
in current object-oriented languages.

Example: When active values were discussed, I was amazed to hear
someone say that Flavors had active values.  Just access the variables
indirectly by message passing instead of directly by name.  From an
elegance viewpoint this is awful.  Besides being able to accidently or
malevolently bypass any intended active values, this means that in
general, the two ways of accessing a variable can have completely
different semantics.  From an efficiency viewpoint, this may be viewed
as a necessary evil because the addition of true active values would
slow down access, and involve very hairy programming in order to gain
reasonable speed.  From the no programming viewpoint, some currently
built programs probably depend on this "feature", and would have to
completely overhauled.

Can one object-oriented language satisfy both system and research
programmers? (satisfying all three views is an overconstrained
problem)

Rather than starting with a already complex system like Flavors,
Loops, or some other comprehensive proposal, I suggest that we start
from scratch, and attempt to build a consensus one piece at a time.
Any comprehensive proposal will have too many implicit assumptions and
too many features to make for a reasonable discussion.  We need to
start with something simple so that the efficiency vs. elegance issue
can be tractably approached.  I like the suggestion of starting with
something similar to Smalltalk, and when (and if) we agree on the
basics, we can move ahead to other issues.

							Tom
-------