RE: Y Store /Closures

["Anton van Straaten" <address@hidden>]

Sundar Narasimhan wrote:
> Avi: You've gone from "cannot be done" to "cannot be done in as many
> lines of code". I won't take that bait, Sorry. Because the lines of
> code you are focussed on reducing is not what I (and other enterprise
> developers are focused on -- supporting the back button in the manner
> you describe is less than 5% of my use-cases). Thanks. I'll conclude
> that thus far you seem to agree that in principle you can do w/out
> continuations, but perhaps *you* think that in languages w/out such
> support it might be verbose to implement "some" such traversals.

"Cannot be done in as many lines of code" can mean a range of things - at
some point, it reaches a qualitative level at which the system with fewer
lines of code wins decisively.  High-level languages vs. assembler, to pick
the most unoriginal example.

Continuations do have the kind of quality that make them a potential
competition-killer.  They allow you to ignore certain classes of problem,
and allow you to write code as though those problems didn't exist.  Quite
similar to the way threads allow you to write a program as though it
executes linearly, when in fact it doesn't.  The similarity to threads is
not coincidental, of course, since conceptually, threads are just one
possible application of continuations.

Since threads are more familiar, they may offer a good conceptual model for
the operation of continuations in a web app.  Imagine if you could write
your web app by devoting a thread to every session.

[Of course, with normal OS threads, you can't do this, because they're
expensive enough, and "dumb" enough in terms of scheduling, that even a
thread-per-connection model can be dangerous, let alone thread-per-session.
However, this restriction doesn't apply with continuations: they're
implemented at the language level, where more is known about the state of
the program, and there's no need to deal with unaffected parts of the OS
context during a context switch.]

So, we have a web app with every session implemented as a thread.  The web
framework takes care of associating connections with the appropriate thread
(via the usual means such as cookies, GET/POST parameters, etc.)  From the
point of view of the web app, it can treat a session as a single linear
thread of execution.  It never needs to deal with "session variables", for
example - it can simply use the variables in the program's normal scope -
e.g. lexical variables - which remain available between connections of the
same session.  You don't even need to deal with a single interaction per
function in your program - i.e. a single function might handle multiple
requests from the same user, not by having the function be invoked n times,
but by invoking it once, and having it automatically suspended and resumed n
times at different points in the function's execution, corresponding to
requests from the user.  Most of the issues of control flow as imposed by a
web application simply disappear.

Substitute "continuation" for "thread" in the above, and nothing changes,
except that it suddenly becomes something that's viable to implement without
stretching the resources of a typical web server (which would not be the
case if OS threads were used).

With a framework like Struts, everything I've described can sort of be
emulated, kind of, more or less.  But it can't be duplicated - not even
close.  This is where I see a qualitative difference, and one that does make
it onerous to have to use the "old style" notions of web session handling.

> Personally speaking, I agree -- but the important distinction to
> make is that customers are asking for more than just what the web
> environment provides. So, I really wonder how long this
> backtrackable-forkable HTML/HTTP driven interface period will
> last (already I have customers that are happier running a heavy
> rich-client app fronted by the likes of Citrix :).

Right - but to produce richer distributed applications, without resorting to
plain old screen-remoting (which doesn't strike me as the ultimate answer to
anything), we need tools that make it easier to operate at a higher
conceptual level - like continuations.  We're not going to be able to do the
kind of cool stuff that customers would really like to see if we're stuck
doing the modern-day equivalent of bit-twiddling, with icky details which
can in fact be abstracted away.

Anton