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

[Marc Stiegler]

> Suppose I wanted to write a turn-based board game as my first E app[1].
>
>
> People usually prefer to play fast -- as little as 1 second per turn.  But
since
> it *is* a turn-based game, if you wait and wait and the opponent's move
never
> arrives, the correct behaviour is just to keep waiting (optionally: resend
your
> previous message in case it never arrived and *he* is waiting on *you*)
until
> either the message arrives or the user signals to stop waiting by clicking
the
> "abandon game" button.
>
> Since it is a strategy game, it is not uncommon for a certain move to take
a day
> or two of thinking on the part of a player.  One of the attractions of
writing
> this game in E is that my users do not have to click the "save/load game"
> buttons whenever they are going "off-line" -- instead persistence is the
default
> and you use the "create new game/abandon game" buttons instead.
>
>
> So in thinking about this it occurred to me that the natural way for me
(the
> programmer) to communicate to the comms system that I no longer care about
> messages that I sent to him is to *destroy the "game" object*!
>
>
> When the user clicks "abandon game", I destroy the "game" object.  Since
it was
> this object that sent the messages to the other player's computer, the
> underlying comms system can know that it need no longer send messages nor
wait
> for responses.  On the other hand as long as the user does *not* click the
> "abandon game" button, then I want the underlying comm system to give me
full
> ordering guarantees and message retrying even if I do something like
shutdown
> the E runtime, unplug my laptop and stick in my backpack, etc.
>
>
> It seems for this example at least that making the coder write his own
> reconnect-and-resend code in order to implement his desired impatience
policy is
> losing some of the gains that a persistent O-O language should offer.
>
> It seems somewhat akin to manual persistence vs. orthogonal persistence or
even
> manual memory management vs. garbage collection -- asking the programmer
to
> manually implement such necessary features sours the promise of O-O,
because it
> forces programmers to descend from the mental state of "modelling the
problem
> domain with objects" into the mental state of "implementing some
supporting
> feature that I need so that I can go back to modelling the problem
domain".

While I am not particularly wedded to the Sturdy/Live Ref system of the
current E, this example does not drive me to a sturdy-everything view of the
world. Within the context of my limited ability to project what E will be
like when it has persistence,  I believe solving this problem with
Sturdy/Live refs will be straightforward--the game object is really just an
example of an object that must be Sturdy. For me, the comparison to garbage
collection is not on-target: manual garbage collection is a constant
intrusion into "modelling the problem domain with objects", absolutely every
object must be managed all the time. Sturdy-ref management, inside the
context of the handful of problems I have thought about persisting
(including one very similar to your example, the Satan at the RaceTrack
problem in Walnut), affects very few, and will (I believe) be managed both
simply and separately. My current sense is that SturdyRef management is a
molehill compared to the garbage collection mountain.

So if I were prioritizing E activities,  I would consider it more important
to get a persistence system into E than to try to figure out the "right"
answer to the SturdyAlways question at this time. Only when we have
persistence can we experimentally assess whether there is a big problem
here. If it is not a big problem, and if it would require a substantial
rewrite of the comm system, I would urge shipping version 1.0 of E without
it. And if that means E can never evolve to have this feature, so be it: one
of our advantages with E over the JavaSoft people with Java is that we have
the wisdom to acknowledge that E is not the last programming language that
mankind will ever need.

Please note that I am, with this email message, attempting to bring to bear
on E development a shockingly new criterion: time to shipment. A dozen
little things have happened in the last 30 days that remind me that this is
an issue (I will name 2: markm's persistent inability to make progress on
the comm system; the near-total collapse of venture financing and other
capital markets that, both directly and indirectly, could fuel markm's
ongoing development).

I am not the manager of E development, but I cannot help putting on the
management hat from time to time that I have worn so often. Two months ago,
when I looked with my management hat 6 months into the future, I saw an E
language being announced on slashdot, being written about in Release 1.0 and
Wired, painfully climbing the user-community-size ladder toward the
hocky-stick explosion of users. Today when I look 9 months into the future I
see Xana-E: a system chock full of wonderful goodness, but so intent on
becoming even better that it never quite got done, and then people had to go
work on other things, and that was the end of it--threads win, RMI and EJB
dominate, and the world uses government regulation as a pathetic alternative
to capability security to make computing safe.

What is the upshot of this monolog? It is this: while it is wonderful and
valuable for us all to argue the merits of X versus Y to identify a more
perfect language
design, I urge markm to more frequently use his authority to say, "yes, that
is a better idea, we will work with it some other time", to less frequently
personally engage these questions (and he hasn't engaged this SturdyRef
question, for which I commend him), and for everyone to be forgiving (even
complimentary!) of markm when he uses this authority.

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

--marcs