Goolgle & IDEs

At some point we will need to discuss Google Wave and its connection to the google web toolkit (GWT), but for the moment, this piece might be of interest.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.


At some point we will need to discuss Google Wave and its connection to the google web toolkit (GWT), but for the moment, this piece might be of interest.

Not to be difficult, but if this had anyone else's name on the byline, I'd expect to see it followed up by you swinging the "off-topic, not LtU" hammer at the offender. I can understand a bit of PL interest in GWT, mostly of the 'you can compile Java to what???' variety. I can't see anything interesting from an LtU standpoint from Google Wave (which, admittedly, I find interesting from many other standpoints).

I'd love to hear differently. What am I missing?

There are various things.

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

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.

Not connected with languages...

... but I did drool over the demo. If it had a plugin to handle latex equations, and a server bot to publish the result into a .tex / .pdf file then it would be the wet dream of many academics. The idea of hanging chats off of particular points in the text during editing looked very nice.

I suspect there is very nice computer architecture research to make what they promised a reality. A shared-memory machine distributed through the Wave server and each of the participating client machines, with "timely" updates... I haven't had a good dig through their API documents yet but I do wonder how they've tackled the harder issues like ensuring memory consistency when multiple clients are writing into the document.

The linear slider on the version timeline was interesting. It's not obvious if that is an inherent part of their view of updates (only one client can be authoritative) or whether internally there is some sort of branching view of updates. For example if I'm editing a node X in the tree, and another client deletes Y (where Y is an ancestor of X) then where do my edits end up? Do they get dropped silently or do they land in some branch/fork of the document?

Another reason why this is

Another reason why this is of interest to me is that I suggested here a long time ago that Google should build a DSL as a platform for google apps, and ever since GWT I have predicted/suggested that it be used for this purpose. Wave seems to be a move in this direction.

Certainly does

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.

Quite right.

I don't follow.

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.

One way to see it....

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

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]

If it had a plugin to handle

If it had a plugin to handle latex equations, and a server bot to publish the result into a .tex / .pdf file then it would be the wet dream of many academics.

Funny that you should mention that. A few weeks ago I posted on LtU about a project I am working on to aid with doing stuff like that. See: What is the best literate programming tool/environment/research work?

I plan to update the thread soon with a "Literate Programming State of the Union" commentary. Let me just hint by saying the state is quite sad, abysmal even. But there is hope!

Veering way off-topic...

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.