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

[Mark S. Miller]

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.  
This incident reminds me quite forcefully of the need for more inertia and 
conservatism in the design, at this point, of E.  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.

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.

Both actual and perceived instability creates actual costs for us: in the 
recent round of syntax changes, I carefully engineered and tested the 
pocket-switches mechanism, so code using the old syntax could run without 
problem during the transition.  This should have done much to reduce the 
actual costs of this change on our users, but it didn't adequately reduce 
the perceived costs. The result: we lost a terribly important opportunity.

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.


        Cheers,
        --MarkM