[plt-scheme] web programming, continuation, CPS transform, etc.

From: Shriram Krishnamurthi (sk at cs.brown.edu)
Date: Wed May 2 09:00:14 EDT 2007

> It makes sense this is a onerous work - I worked out that it requires
> knowledge of PLT scheme itself and then I stopped


> (an aside - I guess what
> you are saying is that PLT is not using CPS underneath ;P).

It doesn't matter what it uses unless that internal representation is
exposed as an API.  This is true of any compiler.

Why would you expect PLT to use CPS?  Virtually no modern compiler

> (2 more cents from a practitioner) The ilities are of huge interest
> for developers wanting to develop huge scale web applications.  I
> love the concept of continuation, and I suspect the scalability is
> higher than I give it credit for currently, but I haven't justified
> diving in head first due to the fear of committing to a ceiling on
> scalability in architecture that I can't fix.

Understood.  I would say that the ilities are probably neither better
nor worse than you would expect, but just different.  We have, in
effect, run a many-year experiment using Continue, a semi-commercial
Web application for conference paper management written entirely in
PLT Scheme (continue.cs.brown.edu).  Over the years we have gradually
refined our understanding of its performance, and some of Jay's work
on continuation replacement strategies (not written up anywhere, but
I'm sure he can say more here if he feels inclined) stems from our
observations of this system (and of its sibling, Resume, which handles
the faculty job ads for Brown CS and was also used at Northeastern CCS
this past year).

> From my perspective AJAX complicates the design of web software even
> further as one has to account for multiple levels of browser/server
> interaction.

Yes.  For now I'm focusing on client-side computation.

Our view of the server has evolved. Initially we thought of it as just
a dumb repository of data.  But then when we saw that we had built a
fairly nice API for connecting to Web services, we realized that was
our way out of the "how rich a server?" conundrum.  I have written
this up on the Flapjax blog, where this post also takes some cracks at
the so-called "tierless" languages:


By the way, until now I knew of only one other person who understood
that the so-called three-tiered architecture is actually a two-tiered
*architecture*.  I was pleased to see from a throw-away aside earlier
in this thread that Matthias is the second such person.

> Unification of browser & server level programming ( e.g. write once,
> work as ajax and as non-ajax) is something that's also of big
> interest for developers, but perhaps this is more fitted toward
> implementation than necessarily research? ;)

No, it's also a research question, but not one I care about.  The
tierless guys are interested in this.  I think this is fundamentally a
confused question, though.  Putting things in different places
involves introducing a new (and significant!) locus of failure; you
need to worry about communication, synchronization, policies, etc.  I
don't think we're anywhere near being able to do such things
seamlessly.  *Furthermore*, whether you run on the client or on the
server has a huge impact on the kind of UI you write (imagine a
word-processor that ran purely on the server, and sent every keystroke
as a synchronous communication...).  So I focus on assuming that
people know what they want running where and will program to that.


Posted on the users mailing list.