Sigh. In Defense Of Inheritance

[Marc Stiegler]

>Since my preference is to err on the side of being too simple, until this
>issue is resolved, E's inheritance support sugar (the "class" construct) is
>hereby removed from the language spec.  The documentation will show the
>inheritance-by-delegation pattern merely as an example delegation pattern.

OK, the theoreticians all agree. Markm has followed his natural bent and
come down on the side of the theoreticians.

As someone who could not be considered theoretical in the current company
(but who is unfortunately still a sigma or two away from being a normal kind
of
programmer), I have to say, all my experiences with single inheritance have
been pleasant, even joyous, whatever the theory may say. And judging from
what I read of
Java programmers in general, the world at large considers single
inheritance to be just plain good. Therefore, discarding it is a very
serious decision
against good marketing, and should be undertaken only for reasons of
desperate importance.

This contrasts gravely to my sense of the world-at-large
opinion of threads. You regularly find stuff in Java publications about the
dangers of threads--as I sit here typing, I have the
latest copy of SIGS Java Report sitting unopened on my desk next to me, it
just arrived yesterday, and on the cover one of the feature articles is,
"Why Swing is not Threadsafe". Two issues ago they had a primer on deadlock.

As nearly as I can tell, threads evoke more discussion of risk and
danger than all the other features of Java combined. Yet, despite this kind
of negative publicity,
Tyler has already demonstrated just how difficult it will be to persuade
people to give up threads. So from a marketing perspective I think that
discarding threads is a bad idea. Nevertheless I agree that threads must be
discarded, because for secure distributed reliable systems with mutual
suspicion, it is a matter of desperate importance.

Now you are proposing to throw out a mechanism
that never gets this kind of negative publicity, and which at both first and
second glance is a very cool feature--shucks, back in 1980, when I first
learned about Smalltalk, I was so excited about the idea of inheritance that
I spent the next 8 years looking for an opportunity to use a language
that supported it for my development teams. Having now used personally
programmed with inheritance in one very serious undertaking and a number of
lesser undertakings, I still like it--no, that is not strong enough, truth
be told (time to confess to my defects :-) I still like inheritance a whole,
whole lot.

If scripting programmers weren't
already seeing inheritance, its presence would be a drawing card; if they
are now familiar with inheritance, it seems unlikely (in fact wildly
improbable) that they are far enought along the curve of experience to agree
with combined intellectual might found in this email list. In other words,
I'd bet they still like it, a whole lot, just as I do.

Jonathan made 2 arguments that together almost bring me across the distance
to agreeing with everyone:

1) Inheritance opens up the possibility of "leaking" capability, an obvious
problem for secure computing;
2) It is easier to add inheritance later than it is to remove it.

After considerable pondering, though, I still conclude that E should have
inheritance. Even Jonathan's points do not add up to the kind of desperate
importance that thread-killing has. And frankly, to believe that markm
should get rid of inheritance, I would have to believe it was even more
dangerous than threads, because I believe inheritance has a much larger,
more passionate, audience of believers than do threads.

I see one way out of this that would satisfy both the theoretical side and
the marketing side. Make delegation work so easily that it is in no way the
least bit harder than inheritance (neither more code nor more code browsing
nor more intellectual overhead), and then call it "a more general, more
powerful, yet safer, form of inheritance". Doing both of these with
sufficient intensity could get E out of being stuck with the label, "Cool,
but not only doesn't it have threads, sheesh, it doesn't even have
inheritance."

If this very high standard of delegation simplicity cannot be met, I urge
deploying E with inheritance. Kill only one white elephant per language, or
the elephants will kill you.

You have to kill threads. You don't have to kill inheritance. Five years
after deployment, when you know what else you did wrong, kill inheritance in
the next language you invent.

--marcs



-----Original Message-----
From: Mark S. Miller <markm@erights.org>
To: Douglas Crockford <crockford@earthlink.net>
Cc: e-lang@eros.cis.upenn.edu <e-lang@eros.cis.upenn.edu>
Date: Friday, October 23, 1998 11:49 AM
Subject: Re: Inheritance Considered Harmful


>Since my preference is to err on the side of being too simple, until this
>issue is resolved, E's inheritance support sugar (the "class" construct) is
>hereby removed from the language spec.  The documentation will show the
>inheritance-by-delegation pattern merely as an example delegation pattern.
>
>
> Without inheritance, but still paying the syntax and the vat,
> --MarkM