Foozle Wars

I saw this piece about Foozles on Phil Wadler’s blog. It’s been there for a while, but I missed it until now. It’s great satire, covering many, er, infirmities of our field, from Aspectitis through Theorititis.


Since Foozles are a category theoretic dual of Aspects, I might as well mention that one of the most interesting things at OOPSLA was the debate over aspects. For the record, I have never believed in AOP. Not that there aren’t real problems that the AOP community highlights; my problem is with the alleged solution.


In particular, colleagues I respect, like Mira Mezini, have told me that AOP is in large part about modularity. And yet, it’s become quite clear that AOP has serious problems with modularity. I’d encourage everyone to read Friedrich Steimann’s excellent essay on the topic.


Kevin Sullivan has done a great job of pinpointing the modularity problem with AOP, and to propose fixes. There’s fascinating work out of Harvard Business School that informs his approach. See his OOPSLA tutorial for starters.


The modularity problems with aspects are related to those with inheritance, but more severe. Let’s look at inheritance. If one simply copies a class (textually) and modifies it, the copy is independent of the original. We can change the original without considering repercussions on the validity of the copy. With inheritance, we have a linguistic mechanism that performs the derivation for us, recognizes the dependency and maintains it. The advantages are well know - changes to the original automatically propagate to the subclass, type systems understand the relationship between the two etc. And there is a benefit - the delta defined by the subclass is defined separately. The disadvantage is that we are much more restricted in what changes we can make to the original without causing breakage in subclasses.


The situation with aspects is not dissimilar. Aspects, like inheritance, are a linguistic mechanism that automatically derive a variant of the original base code, and maintains a dependency from the base code to the aspects. The aspect is also textually separated - this is what makes people think it helps modularity. If the base code changes, the aspect can still apply - as long as the changes are restricted enough; on the downside, if the base code changes something the aspect relies on, the aspect will break, and so we are limited in what we can change in the base code.


Over time, we’ve recognized what the interface between superclasses and subclasses is, made much of it explicit, and understood what limitations that places on superclasses (and superinterfaces).


For example, widely distributed interfaces cannot have methods added to them, which is a pretty harsh restriction. Incidentally, while the common wisdom is that you can add concrete methods to abstract classes,the truth is that these may conflict with subclasses and in principle should be avoided as well.


With aspects, this interface remains implicit, and without an interface, there is no modularity. The base code does not commit to any interface that the aspects can rely on; they can be undermined at any time. The problem is compounded because the coupling with the base is very tight. Resolving this requires giving up on obliviousness - the idea that the base code is unaware of the aspects. Instead, base code will have to declare itself as being an aspect-base in some way. The restrictions on its evolution in that situation are likely to be pretty limiting.


Interestingly, the cloning solution - making a copy of the original and applying the aspects changes to it - is more viable if you take the view that aspects are a reflective change to the base program. We can achieve the effect of an aspect using a suitable reflective API, that can quantify over and modify base code from the outside. Using reflection, the base code need not be edited, and the aspect remains textually separate. Unlike real aspects, no dependency is maintained between the base code and the changes to it. Our “aspects” are independent of changes to the original. Of course, we do have a maintenance problem, which may be eased by tools that track and warn about changes to the base - but do not enforce any dependency. One can even take a similar tack with respect to inheritance.


Given how onerous the restrictions on base code are likely to be if they commit to supporting aspects (or how weak the aspects will be if the commitments by base code are not onerous), I doubt modular aspects will be worth supporting at the language level; I’d put my money on reflection and tool support instead - but time will tell.

And the Winner is ... Self

I just got back from OOPSLA.  Far too much going on to report all of it here. One thing I will mention was the awards session.

I was very pleased to see Dave Ungar recognized twice - once as an ACM Distinguished Engineer, and once more, with Randy Smith, for the original Self paper,(if you have some difficulties with ACM's digital library, here's the journal version), which was chosen as one of the three most influential OOPSLA papers published in the years 1986-1996.

David Bacon got an ACM Distinguished Scientist award as well.

It was also great to see Bill Harrison and Harold Ossher get an award for their paper on Subjectivity.  It’s especially nice when the winners are such nice people.

I don’t personally know Pattie Maes, the author of the other (not the third - there was no ranking among the winning papers) award winning paper, but it is a classic and truly deserving of recognition.

I hope these awards get people to go back and read those papers again. They are all great idea papers. As Dave said when accepting the award, the Self paper had no proofs, no discussion of implementation, and was not an extension of anything. This is in sharp contrast to most of the work that gets published today, which is largely incremental. It’s almost impossible to get a paper accepted that doesn’t have a fairly complete implementation, or a lot of formalism.  This is perhaps inevitable in a maturing field, but it isn’t nearly as much fun, as interesting, as inspiring or as important.

It would be very good if more people understood the ideas rather than the details of particular manifestations we see today. Comparing Self with some of the languages that are popular right now would be a very good exercise for anyone interested in programming language design.  It helps gauge the quality of the designs and the implementations, and gives a perspective that most people are missing.

Why is this blog named this way?

Well, there's the obvious reasons of course. Apart from those, in a previous life I was required to attend JavaOne. I noticed that the room where they handed out goodies to speakers was numbered 101.

Apparently, no one found this disturbing. I guess they haven't come out with "The complete idiot's guide to Orwell for dummies in 21 days" yet.
In any event, I hope to find time to occasionally post thoughts about programming languages and platforms.