[racket] Server side continuations
Paul A. Steckler
http://carcaddar.blogspot.com/2011/06/continuation-based-web-applications.html
The claim is that AJAX makes server-side continuations (invented at
PLT) unnecessary.
-- Paul
_________________________________________________
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/users
Robby Findler
javascript in every browser makes continuation-based web servers less
crucial than it was before that) but overall that post just seems
confused.
Robby
Shriram Krishnamurthi
and then ends up all-wrong. (Even the premise of this flame is wrong.
Continuations are not solely about managing client-side state.)
I guess it's up to Jay to post the brilliant follow-up that
will...well, who knows what will happen when someone this confused
reads it.
I wonder if he's read the structure of JavaScript programs, which --
because of the cooperative multi-tasking structure of JavaScript --
have to return control to the event loop (ie, "terminate") whenever
they make an Ajax request, leaving *another procedure* to pick up the
response if and when it arrives. What a nifty pattern -- I really
wish it had a name! Oh wait, I guess these days it's called "Ajax" --
which makes it all good.
Shriram
Robby Findler
just opens new doors that, pre-javascript, we had kind of wedged our
fingers underneath but hadn't really opened.
For example, just the other day, Casey crashed travelocity when he
tried to buy two tickets at once (he and Diana have different flight
dates but one day/flight in common) leading to him being unable to buy
either ticket.
Robby
Sam Tobin-Hochstadt
> I wonder if he's read the structure of JavaScript programs, which --
> because of the cooperative multi-tasking structure of JavaScript --
> have to return control to the event loop (ie, "terminate") whenever
> they make an Ajax request, leaving *another procedure* to pick up the
> response if and when it arrives. What a nifty pattern -- I really
> wish it had a name! Oh wait, I guess these days it's called "Ajax" --
> which makes it all good.
These days it's called "I need TaskJS, stat!".
http://dherman.github.com/taskjs/
--
sam th
sa...@ccs.neu.edu
Paul A. Steckler
> Where to start? Oh, where to start? Every sentence begins half-right
> and then ends up all-wrong. (Even the premise of this flame is wrong.
> Continuations are not solely about managing client-side state.)
>
> I guess it's up to Jay to post the brilliant follow-up that
> will...well, who knows what will happen when someone this confused
> reads it.
I knew this would get you going.
Good to see the fires are still stoked at PLT. :-)
-- Paul
Shriram Krishnamurthi
find this thread, let me point out one more source of confusion.
Continuations do not manufacture more names *than there really are*.
So, no matter how you program (continuations or CPS, Ajax or not) you
still have to come up with that many distinct names.
You could let the framework choose them for you. OR, you could choose
to give names to the entry points and have the framework calculate
just the arguments needed for each of those entry points.
The latter is what serialization achieves, at which point you have
achieved the same testability, etc., as you have otherwise.
The key point of confusion in the post is therefore that it conflates
continuation-based *programming* with continuation-based *deployment*.
Maybe we should write a paper about this stuff sometime (he says with
bitter irony).
Shriram
Eli Barzilay
>
> I wonder if he's read the structure of JavaScript programs, which --
> because of the cooperative multi-tasking structure of JavaScript --
> have to return control to the event loop (ie, "terminate") whenever
> they make an Ajax request, leaving *another procedure* to pick up
> the response if and when it arrives. What a nifty pattern -- I
> really wish it had a name! Oh wait, I guess these days it's called
> "Ajax" -- which makes it all good.
But of course ajax is too vague an low level -- so it's wrapped in
things like node.js. I've recently looked at it (node.js) in an
attempt to figure out what's all the noise about, and it's surprising
how little you get from it. Practically any text on it explains the
IO problem and then goes on with examples like
foo(1, 2, function(x,y) {
...
bar(x+y, function(z) {
...;
})})
But nobody minds the extra work -- and that seems to be achieved
through some very specific vocabulary, words like "hotness" and "add
some awesome" tends to get a certain kind of people all excited (eg,
"nodejitsu"). Not to mention the many places that refer to it as
"non-blocking evend-driven", and conclude (with a straight face) that
it's a real-time high performance system.
On the plus side, people are very aware of first class functions. I
can imagine the kind of responses such code would get 10 years ago,
but now it's cool.
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
Sam Tobin-Hochstadt
> On Friday, Shriram Krishnamurthi wrote:
>>
>> I wonder if he's read the structure of JavaScript programs, which --
>> because of the cooperative multi-tasking structure of JavaScript --
>> have to return control to the event loop (ie, "terminate") whenever
>> they make an Ajax request, leaving *another procedure* to pick up
>> the response if and when it arrives. What a nifty pattern -- I
>> really wish it had a name! Oh wait, I guess these days it's called
>> "Ajax" -- which makes it all good.
>
> But of course ajax is too vague an low level -- so it's wrapped in
> things like node.js.
This statement is very confused. Ajax is a technique for single-page
communication with the server from a browser. node.js is a
stand-alone version of V8, the Chrome JS engine, designed for
server-side use a la Python, Ruby, Java, or Racket.
People do use libraries to make Ajax easier, but those are things like
jQuery, Dojo, and Prototype.
> I've recently looked at it (node.js) in an
> attempt to figure out what's all the noise about, and it's surprising
> how little you get from it. Practically any text on it explains the
> IO problem and then goes on with examples like
>
> foo(1, 2, function(x,y) {
> ...
> bar(x+y, function(z) {
> ...;
> })})
>
> But nobody minds the extra work -- and that seems to be achieved
> through some very specific vocabulary, words like "hotness" and "add
> some awesome" tends to get a certain kind of people all excited (eg,
> "nodejitsu"). Not to mention the many places that refer to it as
> "non-blocking evend-driven", and conclude (with a straight face) that
> it's a real-time high performance system.
node.js does deliver impressive performance. The non-blocking nature
of JS I/O is annoying -- that's why Dave created task.js, as I pointed
to earlier, but it also allows node to scale to large numbers of
connections much more easily than similar systems written in other
languages.
The node.js crowd has the annoying tendency to act like they've
invented non-blocking I/O, but it's a good idea anyway, and node is
actually a system that lots of people are accomplishing impressive
things with.
--
sam th
sa...@ccs.neu.edu
Eli Barzilay
> On Mon, Jun 13, 2011 at 5:37 PM, Eli Barzilay <e...@barzilay.org> wrote:
> > On Friday, Shriram Krishnamurthi wrote:
> >>
> >> I wonder if he's read the structure of JavaScript programs, which --
> >> because of the cooperative multi-tasking structure of JavaScript --
> >> have to return control to the event loop (ie, "terminate") whenever
> >> they make an Ajax request, leaving *another procedure* to pick up
> >> the response if and when it arrives. What a nifty pattern -- I
> >> really wish it had a name! Oh wait, I guess these days it's called
> >> "Ajax" -- which makes it all good.
> >
> > But of course ajax is too vague an low level -- so it's wrapped in
> > things like node.js.
>
> This statement is very confused. Ajax is a technique for
> single-page communication with the server from a browser. node.js
> is a stand-alone version of V8, the Chrome JS engine, designed for
It's confused because it's a joke on how people confuse these things.
For relevant example, if ajax makes all server side code unneeded,
then how come things like node.js are popular in the first place. And
then the obvious way this would go is "but node.js does very well
without continuations" -- and that gets to the punchline of the joke.
> node.js does deliver impressive performance.
Whether it's impressive or not is unrelated to what it calls
"non-blocking even-driven", which is the connection that every page
that I've seen makes.
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
_________________________________________________
Sam Tobin-Hochstadt
> Three minutes ago, Sam Tobin-Hochstadt wrote:
>> On Mon, Jun 13, 2011 at 5:37 PM, Eli Barzilay <e...@barzilay.org> wrote:
>> > On Friday, Shriram Krishnamurthi wrote:
>> >>
>> >> I wonder if he's read the structure of JavaScript programs, which --
>> >> because of the cooperative multi-tasking structure of JavaScript --
>> >> have to return control to the event loop (ie, "terminate") whenever
>> >> they make an Ajax request, leaving *another procedure* to pick up
>> >> the response if and when it arrives. What a nifty pattern -- I
>> >> really wish it had a name! Oh wait, I guess these days it's called
>> >> "Ajax" -- which makes it all good.
>> >
>> > But of course ajax is too vague an low level -- so it's wrapped in
>> > things like node.js.
>>
>> This statement is very confused. Ajax is a technique for
>> single-page communication with the server from a browser. node.js
>> is a stand-alone version of V8, the Chrome JS engine, designed for
>> server-side use a la Python, Ruby, Java, or Racket. [...]
>
> It's confused because it's a joke on how people confuse these things.
> For relevant example, if ajax makes all server side code unneeded,
> then how come things like node.js are popular in the first place. And
> then the obvious way this would go is "but node.js does very well
> without continuations" -- and that gets to the punchline of the joke.
You seem to be primarily interested in making jokes here, rather than
discussing web programming.
>> node.js does deliver impressive performance.
>
> Whether it's impressive or not is unrelated to what it calls
> "non-blocking even-driven", which is the connection that every page
> that I've seen makes.
That is not true. The event-driven structure of all JavaScript code is
an important part of why node is fast. That's what JS engines are
good at, among other things.
--
sam th
sa...@ccs.neu.edu
Raoul Duke
> That is not true. The event-driven structure of all JavaScript code is
> an important part of why node is fast. That's what JS engines are
> good at, among other things.
imho everything is a trade-off. event-driven has major suck about it.
thread-based has major suck about it. stm has major suck about it.
actor implementations have major suck about them. all for a myriad
rage of values for the particular categories of suck. maintenance.
performance. simplicity. safety. robustness. security. size of
community. miles on the road. yadda. personally i'm sorta annoyed most
about the whole node.js thing because it seems to have gotten some 2nd
coming sort of cult around it, that doesn't seem to actually think
about the trade-offs being made, and what the alternatives are.
sincerely.
Eli Barzilay
That goes perfectly fine with this thread starting as a joke.
> >> node.js does deliver impressive performance.
> >
> > Whether it's impressive or not is unrelated to what it calls
> > "non-blocking even-driven", which is the connection that every
> > page that I've seen makes.
>
> That is not true. The event-driven structure of all JavaScript code
> is an important part of why node is fast. That's what JS engines
> are good at, among other things.
To make it painfully clear, "even driven" is just another word for
"callbacks", which is another word for "explicitly CPS your code". If
you don't see what's lost here, then you're in the wrong context.
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
_________________________________________________