Viewpoints Research Trip

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.


Comments (8)

  1. James Noble wrote::

    There is also the question of why mobile code hasn’t been widely successful to date.

    Not sure quite what you mean by “mobile code” – but JavaScript seems pretty successful to me.

    Also, why do you think you’d need to interpret bytecode rather that sourcecode (again as in JS)

    Thursday, December 1, 2011 at 1:54 am #
  2. w7cook wrote::

    Hi James,
    Yes, you are right that JavaScript is code that moves around. Another successful case is SQL. I think what Alan was suggesting is that the entire content of a web page should be code (possibly with embedded data). That is the way Postscript worked originally. But it is not the way JavaScript works, or PDF. In these systems, the content is mostly declarative, with small amounts of behavior added. HTML 5 is trying to push the balance back towards more declarative and away from random code. Thus I see this as an epic struggle which no side can ever win. But you are right, the term “mobile code” is not very clear… and I’m still uncertain about where to draw the line. However, the extreme case of “all web pages are 100% code” has not been successful.

    Sunday, December 4, 2011 at 1:12 pm #
  3. Mathnerd314 wrote::

    My reply was rather long, so I wrote it here.

    Sadly there is no narrative; but such is life.

    Thursday, December 1, 2011 at 6:57 am #
  4. w7cook wrote::

    Hi Mathnerd314,
    I’m not sure exactly how to respond to your comments, as they are mostly philosophical. To paraphrase an old saying, “Data is hard to define, but I know it when I see it”. I agree that “Data should reign supreme”, and that HTML is good for presenting info… but it is not better than Word, PowerPoint and Excel, because they are not comparable. I completely disagree that 99% of the web is javascript. If you run a browser with no javascript, you can still visit and use 99% of the web, I would say. And HTML 5 is pushing back, moving more behavior into HTML so that we don’t have to write javascript. We are just trying to write programs that work, and solve the hardest problems we know about in the best way possible. I’m sorry if my post sounded too philosophical.

    Sunday, December 4, 2011 at 1:21 pm #
  5. Andreas Semt wrote::

    Hello William,

    thank you for sharing your thoughts from your VPRI visit! This “data” vs. “code” you had discussions about is an interesting point of view (no pun intended) and as it seems to me still an open question (if there is an answer at all).

    Another open question: Any ideas when Enso will be in a usable state and available to try it out?

    Best regards,
    Andreas Semt

    Sunday, December 4, 2011 at 5:41 am #
  6. xavier wrote::

    I agree with the fact that data has not to be stored with its behaviour, but of course with as many information as possible around. The REST paradigm insists on this fact ; Data consumned by a system are only a sub-part of the data with is somewhere stored, and this subpart is accessed through a specific representation understable by the consummer.
    It is like the notion of Truth with a T. Human beings only know projections of this Truth and these projections are called truths with t.

    Sunday, December 4, 2011 at 5:48 am #
  7. Paolo G. Giarrusso wrote::

    It’s interesting to see a discussion of Alan Kay’s point—I think he mentioned the same point in his ECOOP 2011 banquet speech, but very briefly and not very clearly.
    I know understood where Alan’s idea come from: it is important (in OOP thinking) to group data and behavior, both in non-web programming and in web programming. In other words, he seems to be talking about mobile agents.
    However, HTML+JavaScript can be understood as mobile agents together with a rich declarative and external DSL for presenting information. From this point of view, it seems that the main theoretical danger of such a DSL architecture is inflexibility: since the implementation of HTML is not expressed in JS, what happens when you need a variant HTML’ of HTML? If HTML were a conveniently implemented internal DSL, implementing HTML’ would be easy, but since HTML has a built-in semantics, I think implementing HTML’ might be harder. In fact, HTML is translated to a DOM instance, but DOM does not give much additional control.

    However, the point might be only theoretical, since HTML technologies seems to give enough control for many applications; does Alan have concrete examples where the current design is too unflexible?

    Wednesday, June 13, 2012 at 6:34 am #
  8. dmbarbour wrote::

    Thank you for sharing your experiences at VPRI.

    I’m of the opinion that your recent work on Object Grammars would offer a flexible compromise between code and API/behavior.

    Monday, September 17, 2012 at 9:18 pm #
Get plugin