[E-Lang] A more critical question (was: an example impatience policy )

[Tyler Close]

MarcS wrote:
> E needs a comm system. E needs persistence. Everything else
> is gravy.
> Everything! Including the really cool features I want myself :-)

In my view, the solution to this problem is not "rush everything to
completion now", but "let's see if we can't break this up into some
smaller pieces that we can ship now". Hydro as a capability based
collection library is one step. Carving out the VLS into an HTTPY
service would be another step. How many business plans for just this
are circulating right now? "Replace the DNS" is the meme of the day.
Shipping a capability based object database like Acid/Lock is another
step. Writing a language wrapper for that database is another step. If
communities.com had put together a bunch of different individually
interesting products like this, they probably could have spun off half
a dozen different profitable companies. Just shipping a Java
implemented SSL implementation would have been a comfortably
profitable venture at the time communities.com was first running.
Trying to do the whole thing at once is suicide, as history has showed
again and again with these projects.

The other nice thing about shipping many small chunks, as opposed to
one colossus, is that even if you fail in your grand dreams, chances
are some of your smaller dreams will catch on. The very fact that I
can hand-off Hydro to E, while simultaneously chasing a greater
Droplets, is proof of that. I am building a nice safety net. E has no
safety net.

One of the main worries that MarkM expressed with Hydro is that it is
not tightly bound to the rest of the E code base. That he doesn't get
that this is a good thing is, in my view, the source of E's shipping
problems.

Tyler