Re: Sigh. In Defense Of Inheritance Mark S. Miller (markm@erights.org)
Mon, 26 Oct 1998 10:47:26 -0800

I barely have time at the moment to skim this thread, let alone respond. (I expect this situation to change shortly!) But I had to respond to this.

At 05:22 AM 10/25/98 , Tyler Close wrote:
>If E has inheritance, I'm going to be pretty tempted to create a language
>without it. I imagine others will be too. Sounds like a recipe for infant
>death syndrome to me.

  1. Please do, with my sincere blessing.
  2. Feel free to use the E source tree, or not, as you see fit.
  3. C++ was not killed by cleaner languages when it was young, including nearby variants. Instead, C++ kept right on mowing them down. 10 years later, C++ was gloriously killed by Java (I know, it hasn't fallen over yet). But only ten years of (admittedly bad) education of C programmers by C++ made the world safe for Java. Had Java been introduced 9 years earlier, C++ would have killed it because Java would have looked fatally foreign to C programmers.
  4. If you want to see what kind of language I like to design when I'm not compromising, look at Joule. Just as you feel about inheritance and many of us feel about threads, I feel about sequentiality. I don't believe in sequential flow of control. But after talking to VERY SMART people at EC about their failed experiences trying to program in Joule, I'm convinced that Actors never caught on largely because they didn't support sequential programming. If you believe yourself to be as flexible as your hypothesized audience, ask yourself why E grabbed your attention but Joule didn't. Then remember that you are orders of magnitude more flexible than your actual audience.
  5. PL/1 deserves a place in history for making Pascal and C possible. C++ deserves credit for changing the world into one where Java could kill it. I would be honored for E to be the bridge that makes the world safe for cleaner languages, such as Joule. At such a time, the sooner E dies the better.
  6. Choose your battles: Judging from the topics to date, it would seem like the point of E is to create a better object-oriented programming language. Not so! I'm trying to teach the world about distributed capability programming in service of smart contracts, and trying to bootstrap up a secure decentralized electronic market. To have my users succeed at distributed programming, I fear I need to teach an unfamiliar way to do concurrency control. However, I don't see why I *need* to educate my audience how to do without inheritance before E can succeed at E's goals. (This isn't a decision yet, but I am leaning back. More later.) If others want to create a language derived from E for the purpose of teaching other lessons, I truly and sincerely think that's great! 
	To prosper in the long run, you must first survive the short run,
	--MarkM