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

[Tyler Close]

MarcS wrote:
> > 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.

;) I agree. ;) So does MarkM. MarkM put the class syntax "in the
pocket". That means that it can be turned on with a command line
switch. That means we can "check the box".

Of all of the various object definition variants, I am actually least
concerned with the "class" variant because, unlike the others, it is
clearly marked with its own keyword that clearly reminds me of what's
going on. So if one day 3 years from now I run across it in an E
source file, I have a fighting chance of remembering what's happening.

I am totally happy to have the "class" syntax sit "in the pocket" for
all of eternity.

> Since inheritance is a checkbox issue, I absolutely must
> cover it in the
> book.

I really disagree here. The book is not a political document. It is a
tutorial. The goal of a tutorial is to quickly make the student
productive. As you've discovered for yourself, using the "class"
syntax is not part of being a productive E programmer. You would be
intentionally misleading your students if you included the "class"
syntax.

I would be tempted to just totally ignore the whole inheritance issue
and just focus on showing the reader how to do things. On the sly, I
would make sure that this list of things includes all the possible
tasks that someone might once have used inheritance for. All of these
"howtos" would be solely done from the perspective of "how do I do
this", not "how do I do what I used to do with inheritance". If your
book is successful, then the reader will end up with a level of skill
commensurate with your own, and they will never miss inheritance.

Also, with a book like "E in a Walnut", the reader will start
programming by taking examples from the book and modifying them to
achieve some goal. You don't want them to do this with the "class"
syntax. If you presented the syntax at all, you'd have to present it
as: "Read this once and then immediately forget it. I've got some
better ways of doing this." I think that wastes both the reader's and
the author's time.

I don't think you can present two models of computation in the same
book. The lack of focus will kill you. If you really want to do "E as
seen through the eyes of the class programmer", then you must do the
entire book in this model, and not pick on it as an inferior model.
You'd have to do the entire book showing the reader how to be
productive when thinking as a "class programmer".

E's popularity hinges on how quickly people can become productive with
it. You have to ask yourself whether the road to productivity leads
through the "class" syntax. I think you know that it doesn't.

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

I think Zooko, "the newbie from the land of Python", would disagree
that the object/function stuff is unatural. He seems to think it's
very natural. So do I.

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

I am finding it difficult to break up this rant into addressable
points. I can definitely see some points that need to be addressed
though. Could you break this up and include fragment URLs into "E in a
Walnut"?

> 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?
> :-).

The simplifications that have been proposed are solely to make the
language easier to use and understand, not to make it more "pure".

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

"delegate" is a shortcut. It is yet another keyword appearing in a
object definition.

Your target audience will be accustomed to the idea of forwarding a
method invocation by invoking on another pointer. They will see the
"match" expression and say: "Ah yes, that's a lot easier than
providing a handler for each method, and I can see how it 'matches'
all of the methods that I want to forward. And that line right there
is where the method gets forwarded." Why do we want to hide this under
a mysterious "delegate" keyword?

Again, I would ignore the existence of the word "inheritance". Get
them productive. If they want, they can then go to a mailing list and
muse on the virtues of inheritance. We're better equiped to handle
such debates in an online discussion.

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

??? "strange qualifiers". "delegate" is a "strange qualifier".

> The other thing all these purifications of the language
> make me yearn for is
> the "declare" syntax.

I thought the "def name;" syntax won?

Tyler