[E-Lang] down with `define' (was: newbie syntax: picayune points from a prejudiced programmer)

[Marc Stiegler]

> 6) The "delegate" shorthand for a matcher goes in the pocket.
>
> g) The class shorthand, for supporting inheritance:
>
>     class name(...) :any { ... }

As those of you who saw the fight about inheritance a year ago would
anticipate, I fiercely oppose removal of the class inheritance shorthand.
Having inheritance is a checkbox issue: half the blinkin' world doesn't even
think you have objects if you don't have inheritance. It's part of Bertrand
Meyer's definition of objects! Prior to becoming an E enthusiast, I myself
would have rejected out-of-hand any language that claimed to be
object-oriented that didn't support inheritance. Having some oh-so-clever
lambda thingie that can do it doesn't fill the check box.

Since inheritance is a checkbox issue, I absolutely must cover it in the
book. Removing the structure that does the job makes the book just plain
worse--and it is worse in the very same section where all the other
unnatural stuff lives, namely in the object/function section of the book,
which was complicated yesterday before we started getting rid of the
shortcuts, and which is already now harder because of the loss of the
single-method constructor which means I have to explain and make explicit
the invisible "run" method for makers with multiple constructors. Taking all
the new unusual stuff from inheritance,  delegation, and run methods
together that now has to be not only mentioned but really understood, it has
become hard for me to imagine the majority of Java programmers making it
through the functions/objects section of the book--they'll never even get to
the really good stuff. If the only people willing to become E programmers
are ex-Scheme hackers, we have lost totally (actually, we can't attract them
either--E is still too unclean to attract Scheme hackers. Maybe we should
dispense with E and just go with Kernel-E. Who is this language for again?
:-).

I yearn to keep "delegate". The complicated part of the book would be
shorter without delegate, but once again more complicated: instead of
tossing off a couple quick sentences about match[verb,args], and using
"delegate" as a crisp and easy-as-pie alternative to inheritance, now I have
to use the long version. "Delegate" very nicely captures an important
alternative way of thinking about object usage. It is not so much a shortcut
as it is a conceptual model. If we seriously want people not to use the
inheritance system I seriously believe we absolutely must leave in, we must
make the alternative as easy as falling off a log ("if you want people to do
it the right way, you must make the right way the easy way"). "Delegate" is
just about the only part of the "objects and functions" section of the book
that doesn't have a bunch of strange qualifiers and odd scoping behaviors.

Even Tyler(!) admitted at one point in this thread that E's object
construction behavior takes some getting used to. If there is a place in the
language where we should use some syntactic sugar to help beginners, this is
it.

The other thing all these purifications of the language make me yearn for is
the "declare" syntax. The self-referencing-during-construction object maker
is the only part of this mess for which we have a possibility of
simplification that is better for beginners, pros, and purists alike.
Putting in "declare" would roughly compensate for the loss of the single
method constructor in terms of book complexity. Markm, I don't suppose
you've had any brilliant insights that would let you implement this in a
weekend, have you? :-)

I feel like we are no longer asking the right question. I go back to Zooko's
observation that Python enables 2 different mental models of classes, one
for beginners and one for pros. E's model-for-beginners has always been just
slightly too bent to be entirely satisfying, though my own personal
experiences with it suggest it was (marginally) adequate. We seem to be
asking the question, "how do we get rid of the bent model?", for which there
is an easy (and wrong, IMHO), answer. The important question is, "how do we
create a good model-for-beginners?" If we can get a good answer to this,
then we can move across this process with a series of agreements. Otherwise,
we will move across it with a series of disagreements, some of them very
serious indeed.

--marcs