>While Arc includes some handy libraries for writing web apps--libraries so powerful, apparently, that it's cheating to compare Arc to other languages using a problem that requires saving a string on the server--that is not the focus right now.
HAHA... great quote, pg!!
As for language features, I think Arc's on the right track. If anything, be flexible and don't resist the urge to change everything. At this stage, the main thing is to get core right and not worry about backward compatibility.
> libraries so powerful, apparently, that it's cheating to compare Arc to other languages using a problem that requires saving a string on the server
It is kind of a straw man though, but he also got a point. Clearly the use of continuations allows very compact descriptions of multi-page control flow. The only languages that can match the succinctness of Arc in the Arc-challenge are other lisps, Ruby and Smalltalk/Seaside, which all of them also uses continuations. Python which is otherwise known for succinctness but which doesn't expose continuations, does not allow such compact code.
On the other hand it is a straw man because you would not use continuation for navigation in real-world production web sites. You would have to store a continuation for every hit on the site forever, which is clearly not scalable. Therefore it is obvious that serious web frameworks uses other approaches more in line with the stateless nature of HTTP, even if it leads to more verbose code.
I still think the arc-challenge is fun (and I agree that brevity is very desirable), but I think it would be more "fair" if it was framed with real world requirements (scalable, pages bookmarkable etc.) rather than random constraints (the user input must not be exposed in the URL) which only serves to disqualify some non-continuation-based frameworks.
Continuation-based web frameworks suffers IMHO from the same mistake as ASP.NET - trying to make web development look like traditional application code. ASP.NET tries to make it look like event-based desktop GUI app development, Arc tries to make it look like a long-running interactive app written in a function style.
What web-frameworks are really trying to, is to create a new kind of DSL which embraces the spirit and constraints of the web rather than try to hide it. We are not there yet, and such a holy-grail web app DSL might very well be written in Arc one day. It would probably be very short then.
OK, I just realized that the example in the Arc-challenge might be possible to implement without the use of closures persisted between requests.
If the page URLs are generated from the expression tree - outer expression is "/said", page 2 is "/said/anonymous1", page 3 is "/said/anonymous1/anonymous1" or something like that, the framework could locate and execute the correct expression for every hit.
The framework would have to be smart enough to detect that the "foo" input to the page 2 is used on page 3, so it is passed on in the generated link. This approach could actually be fully scalable.
(But damn! It would be disqualified because the input is passed from page 2 to 3 in the URL. I suppose it would be cheating to encrypt it?)
Yeah, but you don't want to keep navigation state in the session. Otherwise you have to keep the session alive indefinitely to support bookmarking. Also, session based navigation state breaks if you browse the site in two tabs at the same time. And it breaks the back-button.
pg's server-side closures are just a variation on the session theme, except that the data being stored is a procedure.
You've just listed a bunch of flaws evident on this very forum . Any link with fnid as a parameter is pointing to a server-side session closure that might expire before you actually click the link.
"On the other hand it is a straw man because you would not use continuation for navigation in real-world production web sites. You would have to store a continuation for every hit on the site forever, which is clearly not scalable."
I think if you are not using first-class continuation and are rolling your own CPS-style libraries, you can make the continuations serializable. Then you can save them on a LRU cache like memcached, to disk, or pass them to the client, depending on your performance requirements.
Agreed, if you serialize the closure and append it to the URL, you solve the problem. I actually proposed this fix over in the Arcforum yesterday: http://www.arclanguage.com/item?id=1760
But if you keep the closure on the server, whether memcached or on disk, you still have the problem that you have to keep storing a growing amount of closures forever.
I think for most public web sites, keeping sessions in a LRU cache like memcached shouldn't be a problem, since it automatically purges the relatively inactive sessions. Assuming each session uses up 100k, which is a lot if the user is not writing a novel, you can still keep 10,000 active sessions in 1GB of memory. If you think the sessions are purged too early, you can add more ram, or more boxes, since memcached is distributed. Last I checked facebook had a 3TB memcached cluster. But ya, if the sessions are small enough you might as well pass them to the clients.
Sorry, I'm confusing continuations and closures in the parent post. You don't need to persist the call stack to implement the Arc-challenge, it is enough to persist the closure. It still have the same problems, though.
HAHA... great quote, pg!!
As for language features, I think Arc's on the right track. If anything, be flexible and don't resist the urge to change everything. At this stage, the main thing is to get core right and not worry about backward compatibility.