Lambda the Ultimate

There are various things. For the most part the page I linked to mentions an IDE angle (and tools are a recurring topic on LtU) namely, the ability to see not only who made a change and when but also the discussion the took place etc. Not a radically new idea, of course, but still interesting as far as I am concerned.

Alternatively, and what we began to explore in Flapjax, maybe we should challenge what we consider to be primitives of a language / environment. Reactivity, linking, sharing, versioning / navigation, etc.

Many parts of their server infrastructure seem to be aimed at providing parts for a client DSL. GFS seems like a good example as it provides the storage for server-side processes so that their results can be queried client side. The API for queries then starts to look like a DSL from many angles.

One thing that I would love to see them undertake is adding a notion of mobility to such a DSL. AJAX looks like a start for a DSL, and if anything Wave gives it a form of persistent storage to operate over. Mobile processes would certainly make this DSL very interesting as it takes a lot of the buzz and hype associated with Cloud computing and makes some of it concrete.

If AJAX provides the "gui", and Wave provides the storage then the ability to migrate DSL programs between client devices and Google's server farm would be an interesting starting point for research into both the language design, and the static analysis that they would require to establish trust on migrated processes.

Quite right.

What would you like to see, exactly? Google Apps Scripts? I don't understand the phrase "DSL as a platform", either. Do you mean DSL creation as a platform? In other words, an IDE like JetBrains' MetaProgramming System?

I do not understand Andrew's comments about mobility and AJAX, either.

I think GWT is neat and all, but it is pretty extraordinarily lame that a key component of Wave is basically being locked into GWT as far as I can see. If I want to re-use any of it, I have to use GWT just to create a Silverlight or Flex container, and have DOM notices post to the Silverlight or Flex app (unnecessary overhead). Google's solution to "fixing the Web" is to lock you into Gears and GWT, which is not the Web at all -- it is not free.

A language is simply a formal description of how one may interact with a machine. Most languages that we consider operate over quite simple machines - perhaps we provide some sort of memory semantics to describe how we can store and retrieve data, and some sort of operation semantics to describe what we do with it.

But the machine that we are programming does not have to be simple. Any API that manipulates some form of persistent data implies a semantic contract on how we order calls to the API. By persistent I merely mean between individual calls/executions into the API, not necessarily data that lasts longer than the program lifetime. If we take the implicit contacts and make them explicit, then the sequencing of calls become primitives in a language.

AJAX provides functionality to Javascript - it allows client/server network communication without performing a page update. As an API (and associated protocol) it allows stateful communication on top of a stateless protocol. There is no particular need to bind that functionality into Javascript / GWT / any particular implementation. We can see it from an abstract viewpoint purely as a language definition that allows stateful GUIs in a browser.

Code mobility is defined in several ways. The meaning that I was referring to is something akin to the pi-calculus. If we consider our execution to be a set of processes then we have several machines that they can execute on. Rearranging the process graph corresponds to a process migrating from one machine to another, taking its data and communication channels with it. One issue here is that "location" is not very well defined, and although people have tried to extend the pi-calculus to include a notion of location that maps onto what we want to express for migrating processes I don't think anyone has solved that issue yet.

Integrating mobility into AJAX is not really an issue about Javascript/GWT. It is a question of whether Google could abstract out the stateful GUI language into a form that could be expressed as mobile processes. The obvious application is that we could have persistent programs that we can pull to any browser interface, but which continue their execution somewhere in the "Cloud" in-between uses.

I hope that is more helpful, I was a tad concise the first time :)

It took me about 15 minutes of thinking about what you had to say here in your latest reply, to grasp what you are saying. (My major barrier is that you did not really focus on examples so much as theory, and I understand the theory but often struggle to see what applications people suggest for things; when they say "this has applications" I keen on on *what* those applications are.)

In a nutshell, I agree with you. I don't want to make claims here that I cannot prove, but I effectively do what you are describing today. Except, I don't have a wicked cool process calculi to show I am doing things correctly. I am not sure I need one, either. I just use Object-Oriented Model Driven Architecture principles. Unfortunately, I do not know many cool things (such as how to compose a calculi and verify it), I just know one big thing, and thankfully that distills complex problems into simple ones.

My motivations aren't really persistent programs in a browser interface, either. There are numerous UX/ID issues with serializing program state across the wire, and I discussed them a month or so ago with H.S. Lahman on USENET://comp.object so strictly speaking I think anything more than permalinks to individual objects is an object graph nightmare the sorts only the "manual persistence" E programming language folks would care to tackle. In short, I recommend shredding the graph, not persisting it. This is effectively weak mobility, not strong mobility. Strong mobility creates all kinds of versioning dependencies you do not want in a UI; I pointed this out to Jaroslav Tulach in Languages ready for API Evolution.

By the way, I also currently cheat and don't do true mobile code. Instead, if the interface wants to persist itself, it just blobs itself and sends a message to a model. The reason why I don't do mobile code like you suggest is basically because it does not solve any problems my customers have, but my current solution solves an administrative interface problem our developers have.

[Edit: A good way to understand my way of doing things is it is a lot like the linux command screen, which lets you detach a session with a keyboard command and reattach using screen -d -r]

I really enjoyed reading that discussion, and although it is not entirely related to what you were discussing I have to point to Tricki as something very cool that many on here may appreciate. It's somewhat off-topic as they are using a wiki to allow collaborative editing of the non-formal background knowledge that is useful in a domain. So it's not quite a literate environment, but it does seem like a useful collaborative research resource.