My first observation is that this discussion screams out for a better point-counterpoint tool than email. I wonder how it would look in CritLink, and if that would make it easier to follow?
My second observation is that, unless markm extracts from this discussion a clearcut decision of his own, I recommend that markm do himself a decision table on the matter :-)
Additional observations below.
--marcs
>Try something for me. Go back and look at the code you have that uses
>single inheritance. How much of it is inheritance and how much of it is
>just interface implementation? Of the code that is inheritance, ask
>yourself what it would mean to change it to interface implementation. Is
>the result better?
Changing it to interface implementation would require writing more code, and more conceptual overhead to manage via a decorator pattern. Indeed, there are a number of places where the decorator pattern would fail because the concept of "self" gets clobbered: if your decorator adds behavior to 2 methods, foo and bar, then when the decorator calls the decorated object's foo, if the decorated object's foo calls bar, it bypasses the decorator's bar. Almost every time I ever considered using a decorator, I found that this was the wrong behavior, and that the behavior of an inherited class was correct. If decorators don't work, I guess I'm stuck copy/pasting code into multiple locations. Surely no one believes that duplicating code is a good idea.
Regardless, this whole track misses the point. For the purposes of making E a success, I don't really care whether inheritance is good or bad, nor whether people's perception of its goodness is a misunderstanding on their part. I only care whether inheritance is so bad it could destroy E, and whether inheritance is so generally appreciated that its absence could destroy E. Which of these two sides imposes the greater risk to E's broad adoption, this is the key question.
>I don't know how to argue against this governing by opinion poll. My poll
>indicates that people will grumble and then realize that this is what they
>have been leaning towards all along.
Yet dealing with opinion polls that have not yet been conducted is the most critical, riskiest element of the language design that markm must yet face down. If opinion polls didn't make a difference, Eiffel would have become the language of choice before C++ ever came to fruition. Perl could never have come into existence.
In very broad strokes, there are 2 ways that markm as language designer could fail. He could fail by making a language with so little in the way of improvement, that even if he won it wouldn't be a good thing. Or, he could fail by making something so brilliant, but so alien, that people wouldn't tolerate the learning curve.
I think we can all agree that, with or without inheritance, E will have enough wonderfulness so that the first risk is negligible. All the risk is on the other side--the side of being too alien to have a tolerable learning curve. Why add more risk here? Why add even the littlest bit more risk here? Isn't the risk great enough yet? Must we yet again pile on risk till you need the Hubble telescope to see the pinnacle? How many times have I wound up saying this to members of this group?
The only way to avoid tragedy yet again is to figure out what that opinion poll will look like.
Tyler, even you predict "initial grumbling". I consider that initial
grumbling to be perhaps the single biggest risk E faces. What percentage of
the people who grumble will just turn and do something else? What percentage
will be as irritated by the lack of inheritance as you are irritated by the
lack of threads? If we could get
Bill Clinton to pass a mandate, requiring all programmers to learn E and
write a hundred thousand lines of code before deciding whether they like it
or not, we could dismiss the grumbling. We do not get that luxury. Even Bill
Gates doesn't get that luxury when introducing something new.
>bug, but I don't see how the string of adjectives comes into play. Right
>now, my understanding is at a point where your above statement could be
>summarized as: "Threads must be discarded, because for God, it is a matter
>of desperate importance."
Certainly, outside the context of the rest of the email in this repository, it would be merely "For God". Thank you, though, for so poignantly re-emphasizing how difficult it will be to get people to surrender a feature they already feel comfortable with. I fear that, just as you feel compelled to defend threads at every turn, frightful numbers of people will feel compelled to defend inheritance, endlessly.
>If E has inheritance, I'm going to be pretty tempted to create a language
>without it.
Bravo!
>Sounds like a recipe for infant
>death syndrome to me.
The key question is, which path avoids the largest probabilities of infant death syndrome? The initial grumbling you shrug off so easily looks like the biggest risk to me.
>See, you're missing the point. The "very high standard of delegation
>simplicity" is a big part of what makes inheritance bad.
Several times in this discussion I have seen statements by people that imply
a philosophy of, "Hey, that quick method of doing things you customers are
using is really a bad idea, we're going to help you out by making you work
harder/longer/smarter." There
just isn't a surer way of avoiding customers than to tell them they have to
work harder. It doesn't make any difference whether you're right or not,
you're still dead. Dead right. A place where some of us have been before.
>I don't know about these crowd control tactics, but my gut tells me that
>people will go for simpler every time.
Opinion polls and crowd control problems do not have the neat clean lines of software design decisions. I wish they did. But winning requires succeeding with these issues no matter how grungy, misshapen, and chaotic they may be. And I really mean the term "requires". Without successfully dealing with these issues, markm is just playing a silly game. And so are we.
--marcs