Lambda the Ultimate

I hate to be negative about a front-page post... especially one that's of potentially interesting technology, and also especially as I don't have a "Real Name" (tm) account (and thus quite intentionally a second-class citizen here) ... but, well, WTF?

With this huge wall of text that focuses exclusively on ends rather than means (the latter is what I come here to learn about), I have now learned that there exists something cool called "Volta" that does some sort of weather control and cloud-cover manipulation, as well as help me to eat healthier at my desk while coding.

How about a mention that Volta compiles MSIL to Javascript & does some stuff to make the code distribution/execution environment transparent, something I had to google to find out? Or a critical comparison --or even a mention-- to the Google web toolkit, which to an outsider, sounds like a quite similar approach?

I suspect I'm in the majority (around here) when I say that I respond better to well-defined language rather than "the cloud". As great or not-great as this might be technically (and there's precious little way to tell from the write-up), the post reeks of marketing.

Disclaimer: This post is not intended as knee-jerk MS-bashing.

I noticed the asynchronous method decoration links to an ajax patterns website, which was a bit puzzling.

I expected this would related to asynchronous methods in polyphonic C#, is it a similar feature, but specialized to ajax?

Is abstracting away the cost of a network message not a double-edged sword? Ought not a networked interface be designed differently than an in-memory interface?

My concern is that if Mort^h^h^h^h Ben is a person who values not learning 'new stuff,' is he really going to understand / appreciate refactoring his "works on my machine" but non-scalable application into a feasible distributed application?

In GWT, users write interfaces between the client and server that explicitly capture the partitioning decision. Volta, on the other hand, seems to make tweaking this decision less painful, as you need only add/move around method-level annotations that identify methods that are allowed to run on the server. (This is presumably what Erik means by "lean programming.") However, my understanding is that Volta still requires you to explicitly label everything you want running on the server, and does not attempt automatic partitioning.

I think a more interesting comparison would be with the Jif family, which allows you to label code that you *require* to be running on the server (usually, the reason is of security). With these (minimal) constraints, and the implicit constraints that UI elements must be displayed on the client, Jif performs automatic partitioning by heuristically modeling the communication costs in a graph and finding the proper min-cut/max-flow. Aapparently, this works good enough. The partitioning also happens on a finer-grained, statement-level.

I haven't had time to learn how Links performs partitioning - if anybody has that information, please post! (It would be nice if the related work were presented by the authors rather than by readers....)

• How exactly does Volta's asynchronous annotation treat exceptions (or timeouts) in asynchronous method calls? As I understand it, you can annotate a method as asynchronous, and then the normal synchronous invocation code will be continuation-split into an implicit callback function (which is how Volta avoids the explicit, GWT-like "remote interface with extra callback arguments" pattern). How then are remote exceptions, communication failures, and other RPC-specific behaviors treated?
• What support does the environment provide for tuning the serialization behavior of objects transmitted from [RunAtServer] classes? The benefit of explicit interfaces is that your serialization points are evident in the code. With [RunAtServer] annotations, it may be a lot easier to suddenly see performance degradation because of unexpectedly many or unexpectedly large network payloads. Does the Volta toolchain currently support profiling of network traffic at the object level?

Links allows annotations (client and server) on functions, which insists that the code of that function must run only in that location. Any call to it from the other location is transformed into a remote call; client-to-server calls become AJAX calls and server-to-client calls are tunneled through the AJAX response. This technique is documented in the FMCO '06 paper: http://groups.inf.ed.ac.uk/links/papers/links-fmco06.pdf

Functions that are not annotated are allowed to run anywhere, which allows for the compiler to do something clever; in practice we just run the function in the same place as its callsite. We haven't done any fancy algorithms for partitioning the program.

Our experience has been that programmers have a pretty good intuition about where the code should run, and oftentimes don't care. The win is simply that you can change a function from running on the server to running on the client just by changing a keyword--rather than rewriting the code from the server-side language into JavaScript--which is presumably true of these other systems as well.