Sigh. In Defense Of Inheritance

[Tyler Close]

At 10:47 AM 10/26/98 -0800, you wrote:
>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.

Whoa, don't push me off the cliff just because I was admiring the view.

>3) C++ was not killed by cleaner languages when it was young, including
>nearby variants.  Instead, C++ kept right on mowing them down.  

I am pretty enamoured by the type of work that you're currently doing, so
maybe in the not so distant future I will try my hand at it. Maybe I'll
call it ESL, officially "E's second language" and unofficially "E's
sacrificial lamb".

Anyways, this certainly isn't anything I am going to try before I at least
fully understand E.

>4) If you want to see what kind of language I like to design when I'm not
>compromising, look at Joule.  

As you recommended earlier, I am looking at Joule. Is this Dean that I'm
reading or did you write this document?

>Just as you feel about inheritance and many
>of us feel about threads,

I'm really not as stubborn as maybe you have the impression I am. I'm sure
you have good reason for feeling this way, and I would like to understand
why, but everytime I ask someone, I get hit over the head with the God stick.

So far, my own privately constructed reason list looks like:
1. Code complexity comes from interacting with a global environment.
Threading creates a global environment of locks.
2. Concurrency is better expressed by the dependencies between asynchronous
operations than by the sharing of locks.

My current pet hypothesis is that a vat is similar to what I normally think
of as an apartment, except that all work within the apartment is done by a
single thread associated with the vat. Code wishing to enter an apartment
does so not by grabbing the apartment's lock but by asynchronously
communicating with the vat's thread.

Well, these are just my favorite guesses coming from a slow read of the
Joule documentation. Again, if someone would like to show me the real list,
I'd love to see it.

>programming.  If you believe yourself to be as flexible as your
>hypothesized audience, ask yourself why E grabbed your attention but Joule
>didn't.  

The great underlying strength of the internet, word of mouth. Ping told me
about Mark and E, Mark told me about Joule.

>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.  

See, in my mind, that's a very large goal. I'm just not sure I see how that
monumental goal meshes with the idea that shell script authors are going to
be the foot soldiers.

To date, people aiming at this application domain have been using hugely
sophisticated OO frameworks like CORBA. I wince when you tell me that you
think script authors are going to be the champions of this market.

On the other hand, if you could somehow play up E as a "serious" OO
solution on par with CORBA, then the corporate types might be willing to
play. I know their employees certainly are. While at Nortel, I worked on a
project built around CORBA, and most everyone was pretty overwhelmed by the
vastness of it. I honestly think there were only two people in the
department who actually understood what was going on. From what I've read
in technical journals, this experience is not unusual. CORBA is just too
blasted large for it to get a critical mass of qualified practitioners.

If E is "A better way of achieving CORBA's goal" then I think I know some
people who would be excited about it. But if E is "A good scripting
language that introduces capabilities" then these same people will ignore
it (I think). Not to be too negative, but the scripting crowd probably
feels that it's already got lots of good scripting languages and isn't of
the nature to be intrigued by new design theories.

Bottom line: Maybe by innovating on the OO front, you will get an audience
of CORBA rejects that you can tutor in the ways of capabilities.

I think that removing inheritance is a technically good and eye catching OO
innovation. It's the sort of thing that will make people demand to know why
you would have done such a thing,... which gives you a chance to talk to
them for longer.

On the other hand, E already has lots of innovation on the OO front and
maybe removing inheritance is like shipping the iMac without a floppy
drive; valiant, but a tad early.

Either way, I think this will be an interesting choice. I look forward to
seeing what and why you decide.

Tyler