OOPSLA report

OOPSLA was great. I got a lot of positive comments and encouragement. It was quite heady to have established researchers, whose work I respect, introduce themselves and tell me that they liked my work. Perhaps a bit too heady: it wasn’t until the last day of the conference that I realized I should be using the opportunity to seek criticism and advice from the masters.

I got feedback in six areas:

  1. Generalize the model from functional programming to logic/constraint programming. This fairly begs to be done, since the “syntax” is already much like a set of clauses or equations. However my intuition is that I should more fully understand the consequences of simple functional computation before exploring in another direction. Logic and constraints might be a good subject for a future collaboration with someone who knows that world better.
  2. Elaborate the model of time to include transactional concurrency. This is my favorite. If I can introduce a merge primitive into the model, concurrency and transactions may fall out quite nicely. This whole area of research is quite hot at the moment, and I might be able to produce a theoretically novel result. That would give me some cred with the “real” Computer Scientists. The merge primitive is also at the heart of many other ideas I want to explore, and I have already failed once to implement it, so I really want to nail it.
  3. Develop a clear description of the underlying model. Some say it should be in Greek, some say English. The merge primitive will at the least complicate matters, and perhaps require wholesale revision. My current feeling is that I should quickly produce an informal description of the current non-merging model, and then try to recruit a theorist to collaborate on a more formal treatment.
  4. Modularity and polymorphism. At the end of my talk, Dave Ungar asked (after some nice praise) whether my elimination of names would also eliminate important features like polymorphism. I could only lamely acknowledge that I needed to come up with an answer to his question. The way I see it, I am recapitulating the evolution of programming languages, and have only worked my way up to about 1960. Modularity and polymorphism are from the 70’s and 80’s respectively. These ideas evolved in response to the alarming growth in code size and complexity back then. I think it would be foolhardy for me to speculate about scalability mechanisms before I have any actual experience with doing large-scale programming in Subtext. The best way to get such experience is to build something that is actually useful. Cue next issue…
  5. Find an application niche where Subtext could quickly become useful to real people. A number of people suggested games. Ward Cunningham made an intriguing suggestion: use Subtext as a tool for generating mashups. A mashup is a patchwork of web resources and services repurposed for a new application. Very web 2.0. If you don’t know what that is, then you aren’t cool enough to be reading this blog :-). This may be a crazy idea, but some of Ward’s crazy ideas have been extremely influential, so I am going to take it seriously.
  6. Improve the user interface. The most surprising (and hence valuable) feedback I got was that people find my user interface unintelligible. Of course that shouldn’t come as a surprise: the canonical blind spot of all developers is being unable to see through the eyes of their users. I guess I got carried away with the flush of success from inventing a UI that works at all. The current UI is really just an existence proof that something like Subtext is possible. I have to go back to the UI drawing board to get from possibility to desireability.

Overall, this OOPSLA was a giant milestone for my research. I am greatly thankful for the Onward track. No other venue would touch this kind of wildly speculative work. The Onward community has not only let me speak, but seemingly gone out of their way to give me encouragement (or is it incitement?).

2 Replies to “OOPSLA report”

  1. Some thoughts on the comments/suggestions that you recieved in response to your OOPSLA 05 presentation.

    On the UI, I’m not sure how much it is necessarily the UI’s fault for making things unintelligible. Although I don’t know the specific criticisms of the people you spoke with, I can understand how, for example, the factorial implementation is confusing. My confusion on the topic largely stemmed from the programming paradigm that did not include control-flow, which I think may be a major challenge for established programmers attempting to learn subtext. It can be very difficult to think of most problems in terms of declaring data, when we are so used to thinking of them in terms of actions. There may be some things that the UI can do to help in this mental transition, however.

    Other ideas for the UI, which I understand you are not focusing on at the moment, but might be useful later on down the line:

    A sidebar search area, for finding nodes by their given label. Obviously this feels like it’s subverting the whole idea of referencing nodes directly without any sort of name resolution, however in any kind of substantial programming project, there will definitely be far too many nodes to wade through for each reference. Also on that note, perhaps a richer set of labeling that could allow some sort of meta data, or include a larger text comment.

    The ability to view only a specific segment of the state tree at any time. On a large programming project, most programmers won’t need to deal with the entirety of the project at any time, and only a small segment at any one time. Imagine if you had to write the entirety of, say, Eclipse in a single file! Clearly being able to view only a small part of the state tree (and import new segments as necessary), would be essential to keeping down the complexity.

    I’ve thought a bit about the copying mechanisms that you explained in your demo, and I believe there may be some simplification possible, and it may help with the polymorphism issues.

    Basically the idea stems from what I’ve been calling “Deconstruction and Unification”. Deconstructing the various programming constructs that we’ve built up over the years, such as objects, functions, and variables, and then unifying them into a single concept, a node in a tree. Each node has a value, which is just one or more other nodes. (This of course does not include the special built-in nodes who’s values actually represent a value in the underlying machine, say an integer for 1000, a string, or most importantly, an action.)

    Using this model (and the possible concept that each node can take arguments that are like metadata for the node), there is only really one copy method: a recursive reference copy. Basically, it’s a reference copy with a variable depth before created subnodes are just references to the original node’s subnodes. For example:

    The original state is nodeA with subnodes node1, node2, and node3. Using a copy with depth 0, copy(0), is essentially a reference copy, meaning 0 “layers” of nodes are created before all other nodes are references:

    copyNode -> nodeA.

    copyNode has subnodes node1 -> nodeA.node1, node2 -> nodeA.node2, node3 -> nodeA.node3

    copyNode has subnodes node1, node2, node3, and their subnodes are references to the subnodes of nodeA.node[1-3]

    I realize this is probably a rather garbled explanation, but I would really love to talk with you about it. I know that you have been working much longer on these ideas than I have, and I’m sure that you have a better perspective on the possible usefulness of the above.

    Finally, I think that subtext is a great idea, and could certainly be the basis for a very useful new operating environment, and I’m very interesting in helping in any way I can.

  2. Corrections:

    I was incorrect about the “solution to the polymorphism issue” comment. The solution is simply that Polymorphism is a concept based upon an abstraction-rich programming methodology, and largely don’t apply to subtext’s method. One uses polymorphism to enable modular code, allowing several pieces of code to fill the roll required by an abstract function. When using subtext, however, each “function instance” has direct references to it’s required variables, and there is no ambiguity about what properties etc. that variable has.

    I was also incorrect about nodes having a value only of one or more nodes. Obviously this would create an infinitely recursive situation if each node simply contained atleast one more node that was it’s “reference.” Instead, some nodes would be actual, direct references to other nodes.


    On the topic of the UI, it also seems, initially, that density and speed of coding might be issues. After some careful thought it appears that while density is rather low in the current implementation, it definitely improves reading ease, and indeed in the demo the UI is not at all a hinderence to understanding what is going on. As for coding speed, I believe some data would probably be required on just how much an average coder actually writes in one long stretch (and how much is actually useable!), before we can make judgements on whether the click & drag method is alright. Certainly coders spend most of their time reading, so it may not be a hinderence to have some minor slow down in coding speed.

Comments are closed.