I visited Viewpoints Research Institute last week and talked with Alan Kay and his team. I presented an overview of Enso, including the concept of managed data, schemas, web applications, security, diagrams and stencils. One point of confusion was my frequent reference to “data”. The VPRI people do not talk about data much. My impression is that they take a more pure object-oriented viewpoint and only think about behavior. I teach exactly this concept in my classes, that one way to understand data is via its behavior, and that this is a very flexible way of thinking about computation, including data.
This led to a fairly long discussion about browser/internet architecture and mobile code. My understanding is that Alan prefers a model in which browsers are simply mini operating systems that download code and run it within a “page” with constrained resources. This would allow any kind of page to be rendered, and would in some ways be more open and heterogeneous than our current model. On the other hand, we would have to agree on a code representation (byte code) and also on APIs. I pointed out that this would make it more difficult for blind people to work with pages than the current model. They countered that HTML is not perfect either, so blind people cannot always access the pages properly. Alan believes that content must come with its interpretation (the behavior/code) or else it will not be able to run in the future. I think the opposite: code is fragile while declarative languages like HTML are more able to be interpreted in the future. It depends in part whether you want to retain the pixel-perfect creators interpretation, or whether you want to be able to re-interpret the information on some some future platform. Alan favors the former while I favor the latter.
There is also the question of why mobile code hasn’t been widely successful to date. As Alan points out, the technology to make it work exists. I think that mobile code is not so much a technical problem as a social and economic problem. So far nobody has figured out how to get it accepted and make it work broadly across many platforms with wide adoption. He pointed to the example of postscript, which allows very flexible printing. But I countered that postscript is not good for many things, which is why PDF was invented. Postscript is mobile code, while PDF is more like HTML. In the end they many of the viewpoints people said that the mobile code issue is not central to their approach. But Alan was out of the room at this point.
The Viewpoints people demoed Nile, their POL (problem oriented language) for 2D graphics rendering and other kinds of media processing. It is very nice. I think it resembles Matlab in some ways. There are multiple dimensions of concurrency built in, and the runtime is able to adjust the granularity of concurrency to the hardware.
They also demoed their office application, for making integrated documents/presentations. I appreciated and agree with their idea of eliminating unnecessary distinctions in the application at this level. They showed a 2D layout model based on a form of iterated property evaluation, with some form of change propagation. I was not exactly clear if this was most like constraint programming, reactive programming, or attribute grammars. However, my overall impression is that they are not following their “problem oriented language” philosophy as strongly at this level of their design. The system seemed to be mostly object-oriented, but they are experimenting with mechanisms for global constrain/property evaluation. The work is at a fairly low level, as they are currently tackling algorithmic issues like layout and animation. It was at this level that the behavioral approach became strongest, and any notion of “data” vanished. We had some good discussion, but I am not sure I got a clear picture of the overall system. My suggestion was to focus on extracting “Frank” from the Smalltalk system, and also think about how to extract “Frank” documents so that they can be sent and interpreted on non-Frank machine.
It is very interesting that the issue of “behavior” versus “data” permeated much of our conversation. While Enso uses OO programs to define the interpretation of data, I do not think that data should be stored “as objects with methods”. I believe that information must have a representation other than code. It must have meta-data that describes its structure and constraints (and this meta-data is also ordinary data, not code!). I believe that “problem oriented languages” are well-suited to this task. Examples include HTML, PDF, SVG, PNG, CSV, MathML, etc. Much of the work of the last 15 years has been creating representations that can be shared. It may be that all this work is misguided, but if anyone wants to present an alternative it has to solve the whole problem of data representation, interpretation, transmission, and re-interpretation, not just part of the problem.
I left the office stimulated to try to come up with an “Enso Office” that would support Word, Excel, and PowerPoint style documents in one unified model. It is not an easy thing to do! But I’m going to try. One thing that the Enso version will have is a “document format” that represents documents as data, not as code. One thing that will be tricky is that this format will include both data and meta-data.