[E-Lang] multiple-domain language, plus Super Newbie is lost without "The Dot" (was: down with `define' (was: newbie syntax: picayune points from a prejudiced programmer))

[Marc Stiegler]

> But it seems to me that you are overlooking the biggest obstacles:
> required "def" for each variable and required ":any" type-annotation
> for each function.
>
>
> To me (and I do write a *lot* of shell scripts in bash, mostly
> interactively but also in persistent files), typing a whole 'nother
> word in such frequent cases as those two would be a real strain.
> (Contrast with appending `()', or inserting `.' -- I do this without
> thinking about it and I don't mind.)
>
>
> I read some (all?) of the e-lang list threads about the ":any" "reveal
> operator", but if I were a naive newcomer I would not have read those
> threads, and I might well prefer to have an explicit, required `return'
> keyword, which is perfectly familiar to all C, C++, Java and Python
> programmers, and thus make type annotations optional, instead of having
> expression-style, which is not familiar and which I don't like anyway.

I am confused. Earlier it sounded like you needed to have
no-assertion-means-return-a-value, but here it sounds like you need
something longer than what E currently requires:

def add(a,b) returns any {a + b}

versus

def add(a,b) :any {a + b}

In fact, despite the extra characters involved, it would be a ludicrous
mistake, as discussed in those old threads, for a capability secure OS like
EROS to have a shell language in which the default behavior was to
accidentally export capabilities. And that is the context in which E is
being considered as a shell language--I really don't see it replacing bash
any time soon (sorry to dash your hopes, markm :-) So for a shell language
the ":any" seems like a better choice than "returns any". For Java
beginners, of course, "returns any" is probably a better choice. This is
indeed a tradeoff between the two goals.

> P.P.S.  I think maybe required-parens, which MarkM has already blessed,
> would solve the problems demonstrated herein

You're tired, I'm tired, and this statement you made as a PPS is correct.
Everyone one of the problems you blamed on the absence of dots (that I could
understand in my tired condition) would have been clarified with the new
required parens notation. So even for a newbie, the space-not-dot is
comprehensible given parens-required. And I can assure you that after 30
days of E programming, it will be the dots that seem ugly and hard to read,
not the spaces. I learned this in my first 30 days of programming in
Smalltalk, and it is just as true today as it was then.

I just spent today writing Java for the first time in several months. I was
astonished at how clumsy it feels. It may seem to some of you, for
theoretical reasons, that E is less "clean" than Java, but I can assure you
that that is not how it feels when you're actually writing pages and pages
of code. Quite the opposite. Very intensely the opposite. The last time I
saw an analysis of productivity comparisons between Java and Smalltalk,
Smalltalk still had a factor 2x or 3x productivity  advantage (Java and
Smalltalk are both way ahead of C++, of course). E has the characteristics
that make Smalltalk so much better, and you can tell when you're building
apps, you really can.

--marcs