[E-Lang] E Project, Documentation, and new programmers

[zooko@zooko.com]

I haven't used E (in any incarnation) enough to have formed an opinion of its
suitability, nor do I have any idea what OpenCola was doing with E or how
likely they are to do something with E in the future.

But when I joined the syntax discussion, the common understanding seemed to be
that we wanted to make whatever changes necessary in order to make E maximally
palatable to the most common kinds of programmers.  I thought that this was an
excellent goal and I still think that achieving that goal would yield benefits
that would outweigh many costs.


On a more philosophical note, I believe that many kinds of design are impossible
to get right without practice -- that design and implementation are in these
cases mutually co-requisite and that if you try to do one first and then do the
other, you will fail.

In particular, I don't believe it is possible to design programmer-friendly
syntax for such a radical new programming language without actually
implementing a syntax and having some programmers try it, and then learning
from your mistakes and designing a new syntax.[1]  

So in my view you cannot have both of: (a) a good programmer-friendly version
1.0 of your language that will be easily accepted by large numbers of
programmers, and (b) early adopters before 1.0 who need a stable, unchanging
language.  But you *must* have (c) early adopters before 1.0 who can accept an
evolving language.


Now, obviously my own prejudice is towards having more programmer-friendly
syntax, as I imagine the future success of E being influenced largely by how
palatable it is to Java and C hackers, but I will remain interested in using E
even if the E cabal values this trade-off differently than I do.


Regards,

Zooko

P.S.  You could also try to satisfy early adopters who need stability by
offering to support features that they are using even after those features are
deprecated.

[1]  For a case in point, after my first foray into using E, I think that the
 default ":none" guard is a major source of surprises that leave newbie
 programmers unable to figure out what went wrong, and that it really ought to
 be changed to a default ":retAny" guard that returns anything wrapped in a
 "RetVal" object.  I will soon publish my notes about that experience.