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

[Marc Stiegler]

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

If I were making a "political" statement, I would leave inheritance out of
the book, because that would be the "political" statement of, "hey, all you
guys are doing it wrong out there, you must Convert To The Superior Way." We
are already doing that with promises and capabilities. This is the wrong
place to make a "political" statement.

What the book is, in fact, is a marketing statement. The book can not help
being a marketing statement. No word written about E at this moment in
history can help being a marketing statement. Every word about E is today a
part of the marketing effort because the number of words is so small. Worse,
the book is probably the most important marketing document we have. If there
were already 10,000 E programmers in the world, and 200 other books about E,
I would write a different book. You would like that book more. But there are
not 10,000 programmers. All I really care about is getting to the point
where we have 10,000 programmers so that you can say you were right all
along, and I can laugh and agree and promise we'll fix it when we do Joule.

I will cover inheritance for the same reason that I cover the xml
quasi-parser--it is not key to getting programmers productive quickly, but
it must be included so they can all see that the stuff they expect to have
is available. The way I cover inheritance today is, IMHO, perfectly okay:
describe it, give an example, note that you probably don't need it because
you have delegation, and proceed for the rest of the book to show how to do
everything with delegation.

> I don't think you can present two models of computation in the same
> book.

Yet Zooko's story about Python is, as nearly as I can tell, exactly this
story. I actually believe that I already have done this, in the current
version of Walnut. I am fighting to ensure the goal is still achievable.

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

I am happy for you. For some of us (including myself), this stuff is only
natural after working with it for half a year.  Lambda expression languages
have a pathetic track record for widespread adoption. Consequently I fear I
am more "normal" on this matter than thee. Certainly, the risk-averse
attitude is to assume that dragging E's lambda-nature in front of the
beginner is a losing strategy.

> > 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 feel like reciting a mantra, "a mental model for beginners, a mental model
for beginners." Such a strategy almost certainly involves more syntactic
sugar, not less. Yet "less" is all I can hear being endorsed here. To me
this is "purism".


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

At what point does a shortcut become a new mental model? Why do we not refer
to snow as, "small, lightweight crystallized oxygen dihydride"? You see a
shortcut, I see a mental model, we are looking at the same thing. The
difference is indeed important. I actually experience the difference between

delegate {object}

and

match[verb,args] {E call(object, verb, args)}

as a physical sensation: when I write "delegate" in an object maker, the
tension flows out of my shoulders because it is so easy, I can't get it
wrong. But when I write "match" in an object maker, the tension flows into
my shoulders, because I have to get the rest of the passage exactly right
for every conceivable message coming through. When reading, I have the same
reactions: "delegate" means I can stop inspecting this constructor and go
read the other constructor, "match" means it is time to review the rest
extra-carefully.

> I thought the "def name;" syntax won?

It did, if you mean "def name := something". The "declare" syntax is a
different animal, specifically for simplifying objectmakers with
self-reference during construction. This would help me make the apology at
the beginning of the subsection on "Objects" less necessary. It actually is
"declare name" without assignment, which is why I am a little confused.

You asked in response to the "rant" in my last message (and it was indeed a
rant, I apologize) that I post some fine-grain urls in the book.

This whole discussion revolves around the section

http://www.skyhunter.com/marcs/ewalnut.html#SEC12

which is the "Objects and Functions" section of the book. I will now walk
through the subsections and note the wins/losses with markm's current
proposal:

Functions: a win, the required parens make this section simpler. This
assumes I don't have to do the whole discussion of function shortcut
expansions here, which is not yet certain.

Dynamic Type Checking: unaffected

Objects: a loss. This section already begins with an apology for how
different E is. If you read this section, you will see that the apology is
truly needed. Of all the sections that cry out for simplification, this is
the one; making this section more complicated is as wrong a direction as you
can get. With the new proposals, the subsubsection about Multiple
Constructors becomes more alien, since we use "run" rather than "new", and
must talk at length about the shortcut nature of functions, either here or
earlier.

Delegation: a loss. I have to describe the whole match [verb,args] thing
here.

Inheritance: a loss since this section is not going away.

General method name matching and E call: a win, sort of, in that this
section must now be included in what used to be the simple Delegation
section.

Under the covers: a win, sort of, in that the material, "everything is an
object" must now be covered earlier and in more depth for what used to be
the simple Multiple Constructors subsection.

The layout of this section of the book has been designed so that the
important parts are described early and simply, and the clever stuff you
don't need very often is described late and briefly. One might refer to this
as a "marketing" strategy, since the goal is to keep the important parts
easy and the hard parts short; the actual value in this separation is much
greater than the actual word count for the number of words added/removed. I
was actually considering moving the "match" section and the "under the
covers" section to Advanced Topics that can come after we do the cool stuff
with secure and distributed programming. This would have helped with another
problem with the book, which is that you don't get into the cool stuff until
you are past the halfway point in book! These proposals destroy such hope.


--marcs