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

[Tyler Close]

At 02:46 PM 4/7/01 -0700, Mark S. Miller wrote:
>At 07:02 AM Saturday 4/7/01, steve jenson wrote:
> >The first issue that I'm having is how the language seems to be in
> >a near constant state of flux. [...]
> >It's also to be expected that people won't want to develop
> >in a language that appears to be changing. [...]
> >The idea of having to port my code for every new release
> >isn't something that sits well with me and so I'll avoid developing in it.
> >
> >How this fits into OpenCola is that we're not going to be building
> >production code on top of a rapidly shifting language. We want to wait
> >until a stable 1.0 (or equivalent) release is around.
>
>I'd like to let everyone know how personally painful I find this decision,
>especially because of how perfectly sensible I find it on openCOLA's part.

I very much doubt that anyone has ever accused MarkM of not thinking *big*.

I empathize with you, but I also think its unnecessary sorrow. E's not yet 
ready to be a production language, but that isn't a failure. You can't 
expect to jump from nothing to prime time without passing through any 
intermediate stages.

I remember in the early nineties, most of the best programming shops would 
first build a prototype of their product in SmallTalk, with the full 
intention of completely throwing out this code and redoing the 
implementation in C++. Effectively, SmallTalk was seen as just a 
prototyping tool. A form of executable pseudo-code. Now as it turned out, 
by the time some of these projects were ready to start the C++ recode, the 
SmallTalk runtime had progressed to the point where this wasn't necessary. 
It was an unexpected but welcome bonus.

I think it would be more realistic, and wiser, for OpenCola to view the 
current E codebase as good programming shops once viewed SmallTalk. As a 
tool for producing executable pseudo-code, the current E release is a 
fantastic success. I also think there's a very good chance of getting the 
"no recode necessary" bonus, but you shouldn't be building that into your 
expectations yet. (Is this a sign of the times?)

We need to do a better job of managing expectations. If you apply rational 
criteria, the E project is a great success that should not be causing MarkM 
any heartache. It's only when you succumb to "internet stock" logic that it 
is possible to feel any disappointment.

>This incident reminds me quite forcefully of the need for more inertia and
>conservatism in the design, at this point, of E.

And the pendulum swings...

>   For example, before Steve
>and I had this conversation, I was thinking about the dot issue mostly in
>the terms I was discussing it -- in terms of E's goals as if E was a brand
>new language and design changes were cheap.  Now that we have users (and we
>still have some!), we have different tradeoffs than we did when MarcS was
>the only E language programmer.

Please try to remember how very early it still is. For a programming 
language, you can only measure time in terms of lines written. For E, the 
amount written vs. the amount to be written is still infinitessimal.


>This does not mean we should argue about things any less.  Far from it. It's
>just that, when weighing all these arguments and making tradeoffs about what
>to do, we all need to remember the costs imposed by non-upwards compatible
>on actual current users.  Likewise, the costs of scaring away potential
>users -- as they look at E's recent history, they may very well rationally
>decide to wait for stability.

I think the issue here is properly managing expectations. E is not a 
production language (yet). You *want* to scare away people who are looking 
for one. E should currently be sold as a prototyping language. If people 
are told to expect a prototyping language they will be pleased with what 
they find.




>None of this is to say that we could make E truly stable today, or make any
>real commitment to make only upward compatible changes.  Today we can't,
>and we won't be able to until at least we understand how our persistence
>choices effect E.  But even without firm commitments, E is usable today and
>should be accumulating users.  For these early adopters, actual or
>potential, stability is valuable.  I'm only saying that there's a big new
>tradeoff that we must start seriously taking into account alongside the
>others.  Other than this blind spot, I think our collaborative design
>process has been wonderful.

How big is it? It would probably be wise to start judging changes in terms 
of hard statistics about the number of lines affected. Are your current 
users willing to publish this information?

Tyler