The art of the science of software

Gregor Kiczales gave one of the keynotes at last year’s OOPSLA (slides and audio). The abstract was promising, and it sounds like the talk was well received. Nonetheless, I think Kiczales is off target. But as the talk has a number of important themes running through it, and the subject matter is extremely pertinent to my own research interests, I will attempt some course correction, rather than just pick holes. As with my last post, I intend these remarks as friendly constructive criticism. The talk was in the exploratory spirit, after all, and it deserves a response in the same spirit. Unfortunately the various strands of the talk are woven together in ways that are both confusing, and confused.

Pluralism in software, pluralism in science

Kiczales’ central observation is this: software abstractions are transient beasts, subservient to our equally transient purposes. Abstractions in a sense represent points of view, and thus flex and mutate as we shift our perspective. Philosophers sometimes call this kind of “perspective-friendly” meta-perspective pluralism. Pluralism acknowledges that there can be a plurality of distinct descriptions of a system – perhaps with radically different ontologies – without requiring that at most one of these descriptions is “correct”. Put like this, pluralism sounds like plain common sense. And it seems inevitable that one day our languages and tools will reflect this pluralism. What’s less clear of course is how painful the journey will be.

Kiczales also makes the interesting point that the shift towards perspectivalism in software in many respects mirrors a similar shift in how we think about natural systems. (At one point he asks the audience, leadingly, whether anyone believes in “scientific objectivity”.) Here it seems that Kiczales has been heavily influenced by Brian Smith’s book On the Origin of Objects. Smith was in the office next door to Kiczales for several years, and some of his ideas seem to have cross-pollinated. I’ll come back to Smith’s book shortly. But first let’s consider this analogy between software systems and natural systems. (I apologise for the brief philosophical digression, but I think it’s one of the threads of the talk which hits on an important point.)

Twentieth-century philosophy of science, certainly since the decline of logical empiricism, was dominated by various flavours of a metaphysical position called realism. The basic supposition of realism is that there exist theory-independent facts about the macroscopic organisation of the physical world, and that these facts determine whether a given successful theory is really true, or “merely” capable of accounting for all the empirical data one could, in principle, obtain. A realist might, for example, claim that there is an objective fact about exactly how many hairs there are on my head, and that this fact exists independently of – is ontologically prior to – any particular theory of what hairs are, or indeed what heads are, or what it is for a hair to be attached to a head. Some such commitment to an objective, theory-independent, “natural kind” ontology – what Nelson Goodman famously called a “ready-made world” – is the cornerstone of any realist world-view.

What’s wrong with the realist picture is that there is something smelly about the idea of a fact which is in principle beyond the reach of empirical science. Scientific theories typically “parse” low-level ontologies into higher-level ontologies; these macro-ontologies are really nothing more than patterns swirling in the low-level structure, and the “truth”, or otherwise, of such theories is, in scientific terms, fully exhausted by the empirical success of that theory. From science’s point of view, “molecules” are just patterns in the quantum-mechanical substrate (or whatever) which satisfy a certain behavioural or structural description, and the extent to which the theory of molecules is more (or less) objectively true than any other theory is just the extent to which that theory successfully (or unsuccessfully) systematises the phenomena. There are no further scientific facts – no “trans-empirical” facts – which determine which theory is “the one true theory”.

I can’t hope to have done justice to this topic in that one paragraph, even if I knew enough about the subject to give it proper treatment (and I don’t). But my aim here is only to concede to Kiczales and Smith what I think is fair concession: that any plausible alternative to realism must be pluralistic. It must allow for there to be multiple descriptions of the same natural system – perhaps with radically differing ontologies – without imposing the requirement that at most one of them is “correct”. A theory of quantum gravity, if we ever find one, will not reveal General Relativity to have been “false” – but mysteriously successful – all along. It will just be a better theory.

So let us grant the point that realism is a metaphysical red herring. And I think we can also agree that the analogy with what’s wrong with our traditional conception of software is compelling. We tend to think of there as being a unique objective fact about what a piece of sofware “does” – a unique theory of its behaviour. Our awareness of the existence of some underlying source code tends to fuel this intuition. But really we need to be much more pluralistic, and accept that what a piece of software “does” inescapably depends on your point of view. A security engineer might have a completely different view of a system than an end user. Each end user probably has a different view than other users, in as much as she can’t see what other users are doing. Reports or audits produced for management are really nothing more than abstractions of how the system behaves. Even a bug-fix, without too much of a stretch of the imagination, is just a view of an erroneous program that applies a correcting delta to its behaviour. And many of these views and perspectives aren’t just design-time artifacts, but are live perspectives on a running program. This pluralistic way of thinking about software is even more dynamic and fluid than fluid AOP: let’s call it superfluid AOP.

An exciting possibility, then, is that fixing our philosophy of the natural world and learning how to think properly about software might end up dovetailing rather nicely. God’s not a mathematician, he’s a programmer, right?

Deconvolve this

So far so good. But where Kiczales’ talk goes awry is in its leap from pluralism, to the ushering in of a new era of “formality-free computing”. In this fluffy new future, we will sit around engaging in social negotiation and situated action, interactions which will somehow manage not to be “formal all the way down”. Unfortunately, these are just Smith’s bad memes at play. I guess I can see how the kind of pluralism just discussed might be innocently mistaken for post-modernism of the sort offered by Smith in his cryptic book, but it’s a serious mistake. All I know is that if there is a place for post-modernist, lit-crit, social constructivist thinking in the modern world, it’s nowhere near the field of computing.

The following excerpt from the Amazon “review” of Smith’s book (presumably written by his publisher) captures the sickly flavour of Smith’s vision:

Critics of programming practice have compared it to alchemy and Smith recalls the characterisation of Newton as the last of the magicians. Is this a pre-Newtonian phase, lacking “Laws”, awaiting the differential calculus? Another position is suggested:

“… that we are post-Newtonian, in the sense of being inappropriately wedded to a particular reductionist form of scientism, inapplicable to so rich an intentional phenomenon. Another generation of scientists may be the last thing we need. Maybe, instead, we need a new generation of magicians”. [p362]

Magician? Magus? Seeking the secret of how it is we “deconvolve the deixis” – plus ça change, plus c’est la même chose. The Alchemist: not a charlatan, but one possessed of much empirical wisdom stumbling after the scheme of things; as this new Science of the Artificial must do, self constructed, self referential, post-post-modern, a metaphysics for the 21st century.

I’m sorry, what?? When exactly did Gary Gygax get together with Jacques Derrida? It’s somewhere between uninformative and downright misleading to attach significance to the idea that software is intentional (in the philosophical sense originally popularised by Dennett, and somewhat misappropriated by Smith). We can, too, skip gaily past Smith’s notions of registration and zest with no fear that we’re missing any useful insights. Like it or not, the bedrock of computing is the scientific world view, and Smith’s anti-scientistic stance and vaguely Continental-style philosophy are about as compatible with this world view as creationism. Indeed, with the situation arguably inverting – and computation gradually becoming the conceptual foundation upon which science is built – it is even more important that we keep computing free of this kind of pretentious twaddle. It matters too much.

And while it may be true that interfaces are, unsurprisingly, often socially negotiated, we must be careful what we infer from this. So is the spelling of identifiers, the pattern of whitespace in a source file, the arrangement of plant pots in an office, after all. What we must cleanly demarcate are the forces that define a particular technical problem, and any particular solution to that problem. The problem that Kiczales has quite rightly identified is just this: abstractions are essentially dynamic and context-sensitive. There is no unique “correct” ontology for any man-made system, any more than there is a unique correct theory of any natural system. And one of the key forces that happens to drive this dynamism and context-sensitivity – but only one among many – is social interaction. (“One man’s constant is another man’s variable”, as Alan Perlis nicely put it.) But it is a mistake to think that any observations about computing as a social activity offer insight into potential solutions to this problem.

Formality all the way down

This leads us to the final Smithesque strand we need to extract from Kiczales’ talk and lay to one side. We are all familiar with the observation that simple interactions between parts often give rise to “emergent” phenomena, behaviours that are somehow novel or surprising, such as the macroscopic behaviour of ant colonies or eBay shoppers, but which are not in any way mystical or magical. As Figure 1 attempts to show, emergent behaviours are in a sense dual to the requirements on a solution. Requirements are known and obligate the system in certain ways, whereas emergent behaviours (“emergents”, one could call them) are those which are permitted by the system, but which were not known a priori.

Figure 1: Required behaviours vs. emergent behaviours

Emergence is an important topic. But again, we must be careful not to make the leap from the uncontroversial phenomenon of emergence, to the highly controversial idea that reality (and by analogy software) might not be “formal all the way down”, as Kiczales, following Smith, suggests. Formal all the way down is exactly what reality is. What else could it possibly be?

Smith’s new-age version of emergentism is just an invalid inference from the failure of the reductionist programme in science. In the 1960’s, many scientists, as well as philosophers such as Ernest Nagel, were optimistic that we would eventually be able to deductively derive all of science from fundamental physics, by establishing the right “bridge laws” between theories. Half a century later, this optimism looks naive. There has been only limited success, for example, in deriving much of chemistry from quantum mechanics on a “first principles” basis.

But the failure of this kind of reductionist programme does not mean giving up on formalism. We simply need a more mature perspective on the relationship between two theories, perhaps seeing the relationship as closer to one of computational abstraction than one of deductive derivation. During the Q&A session after the talk, someone asked whether “biology rather than formalism” was a better model of software. Yet much of the recent success in biology has come from developing new technical perspectives and formalisms. Witness the fast-evolving population of process calculi, equipped with ambients, stochasticity, branes, and whatnot, which are fast becoming mainstream tools in systems biology. Biological reductionism may no longer be plausible, but there is no inference to the inadequacy of formalism.

Once we concede this, then as with social negotiation, we can see that emergence is only indirectly related to the technical problem of enabling “perspectival programming”. We don’t need to design for emergence; what we mean by “emergent” is, after all, just that which doesn’t come built-in. There are no insights we can export from emergence itself to the foundations of computing. Emergence comes about from the way we use things, the way things contingently interact, not from the mechanisms of interaction per se, which can and indeed can only be strictly formal.

The technical challenge: a new paradigm for interactive computing

So at last, I think we can distill the central challenge lurking at the heart of Kiczales’ talk. How do we expect to realise the task-centric, perspectival model of programming that we know is coming? If abstractions indeed need only exist only in the service of specific interactions the programmer or user has with the program, then in the future we may be abstracting and unabstracting as frequently as we switch between edit buffers today. In their various ways, systems like Mylyn, fluid AOP, and Subtext offer a glimpse of what this world might look like (although Subtext is the only one of these that offers a glimpse of just how fluid the new paradigm might be). But do we have the technical maturity to realise this superfluid, aspects-on-steroids vision?

I suspect that Kiczales would agree that the answer is no. We simply lack a compelling paradigm for building robust interactive systems. But contra Kiczales, and as I argued in my last post, working out this new paradigm will require us to to embrace the formal, not reject it. The answer is not going to be to make things less effective (in his semi-technical sense of the word – roughly synonymous with “executable”, I think, or perhaps “live” or “connected”) but precisely the opposite. My own suspicion is that to make this sort of fancy stuff work properly, we will ultimately need a paradigm where software components are intrinsically, persistently and bidirectionally connected, and where interactive computation is the automatic and incremental synchronisation of distributed state. I’ve talked about this before, and will hopefully have more to say about it in the future, but for now I only wish to suggest that this, or something like it, is where we should focus our attention. It’s where the real challenge lies.

Conclusion: less pop, more sci

To sum up, I sincerely doubt that there is an impending “post-formalist” reconstruction of the foundations of computing. If we want things to be fluffy, they’re damn well going to have to be fluffy in some kind of technical, mathematically robust sense, not in some…well, fluffy sense. We should embrace pluralism and perspectivalism, both in science and computing, but not at the price of sloppy pop sci or new-age philosophy. The member of the audience who wondered whether Kiczales’ “radical thesis” had more in common with quantum mechanics than classical mechanics should be sent to bed without any tea.

What this kind of question, the popularity of Smith’s book, and to a lesser degree, Kiczales’ talk, ultimately brings home is perhaps this: that if it’s socially negotiated artifacts we’re after, we need look no further than the world of technical ideas, mediated by the situation action of conference attendance. Smart people often believe strange things; maybe that’s the object lesson.

4 comments

  1. RustyF says:

    I had already listened to the keynote. Certainly, it became less interesting to me the minute I could no longer (as a developer) visualise how the less formalisms could be realised; you are effectively just trusting Kiczales. (Why do people trust him? It is probably because he has a history of producing real tools that work – at least thus far. Credit where credits due, for sure). Since reading the slides, I feel more comfortable but it’s still rather vague.

    Personally, I don’t need proof about realism, perhaps, because like the the eye of the beholder and beauty, I choose to see things *how I damn well choose!*. I chose to view the world through my own taxonomy of rose-tinted glasses. I just need the tools to allow me to express pluralism formally. I can smell it but still can’t visualise that experience.

    I guess tangibility is generally the trumping abstraction and perhaps quite rightly for humans and real objects. But secondary viewpoints (abstraction) are part of everyday life as you’ve already suggested. Of course, nobody ever tests the well-formedness of these secondary viewpoints and I guess many are incomplete, not because they can’t be completed but because one doesn’t really need them to be complete.

    However, one thing in my mind cannot be denied, which is that abstraction is already pluralism, surely? There mere fact that you can have multiple levels of abstraction of the *same* thing, the fact that two developers can build systems with exactly the same overall abstract behaviour yet internally constructed from entirely different abstractions, implies this.

  2. Gregor says:

    Sorry for not responding sooner. I put off replying so that I could get the time to write a careful response, and then before I knew it, a month went by. This response still won’t be careful as I would like, but I don’t want even more time to go by.

    I’m really glad that you listened to the talk and wrote such a substantive reply. As you correctly inferred, I was trying to highlight issues more than give a working solution. If the talk provokes responses as substantive as yours and Jonathan Edward’s then I’m very happy indeed.

    Clearly you’ve thought and read about these issues a lot, and that shows up in the substance of what you are saying.

    But I do see two problems with your critique: one is due in part I think to the talk not making its central points sufficiently clear; the second has to do with weaknesses in your critique of Brian’s work.

    (1) WRT What the talk is trying to say about computing.

    In your critique you say, that the talk aims to:

    ushering in of a new era of “formality-free computing”

    and to

    make things less effective

    These are just two quotes, but I think they get at the parts of your critique that most address what I am proposing with respect to computing.

    But I think I’m trying to say something quite different. I’m not proposing formality free computing — that’s inherently a non-starter since we run on digital computers with instruction sets etc. So formality is clearly going to be a large part of what we do. I’m also not proposing making things less effective.

    Instead I’m trying to make (at least the following) two points:

    (a) that the nature of software systems is such that they live in the space that most demands pluralism (is hardest for formality).

    (b) To date, effectiveness in computing has required formality. So if we have wanted effective access to an issue, we have had to be able to make it formal/crisp. The problem with this stems from (a) above; there are very many issues that matter to us, to which we would like to have effective access; but which are difficult to make formal.

    My suggestion is that the more we can find a way to make the non-effective–>effective and non-formal–>formal tradeoffs parametric rather than binary, the more power we will have to deal with a number of important issues.

    Here’s one concrete example. If you look at the refactorings that tools like Eclipse support these days (essentially the same as what Interlisp-D did nearly 20 years ago) they are all crisp. By the “very definition of refactoring”, they are semantics preserving and well-defined.

    They are also clearly useful.

    But now consider a larger more amorphous refactoring, that isn’t as easily amenable to being made crisp. Consider the process of trying to tease out a latent abstraction in the code. What if the tool could step into the process earlier, when its still fuzzy, and contribute. To do that, it would need to be able to work in a mode where things are not complete, not entirely well defined, negotiated, shifting etc.

    That’s the kind of power that Mylyn has. Mylyn works by making its best guess at what you care about and showing you that. If something is missing, it doesn’t know that. Moreover it can’t give you any really satisfying model of why some things are in the concern and other things aren’t. But often its very useful, and when its not you override it.

    Now returning to the refactoring example… By the time you are done of course you want the code to type check and have an assurance that you have done the right thing. You want the kind of crispness associated with the formality intuition. I’m not denying that. Instead what I’m asking is what does it take for tools of various kinds to get involved in that middle ground where things are negotiated, unclear, zestful…

    One of the things that makes it hard to think about this work is that we have to think about the times and state of being confused. Not about being subsequently clear, but about being confused and navigating that space. One of the things that I think is valuable about Brian’s work is that it helps think about that state.

    (2) The second critique I would make of your critique has to do with the comments you make about Brian’s work. Its clear that you don’t agree with Brian, and that’s fine. But in my opinion your critique of his work is not up to the same standard as the first part of your note. In some places it borders on sarcastic rather than clearly saying what you think is wrong with what Brian is saying.

    One suggestion is just to keep in mind that the talk is based on both Brian’s work and Lucy’s; and those in turn are based on lots of other work. Also note as I said above that I’m not proposing we give up what’s right about how we think about computing. I’m just proposing that seeing what should be different might give us a lot more power.

    There’s more to say, but let me leave it at that for now.

    I look forward to your response and I promise to respond more promptly next time.

    Gregor

  3. Matt Hellige says:

    Well, I too wanted to respond to this, and in fact I intended to respond to the piece as originally posted in December… Time flies, and I’m sorry for the long delay.

    I don’t have time to produce a really coherent response, but I do have a few comments. First of all, I mostly agree with you, except as regards the Smith book. I haven’t read it in its entirety, but what I’ve read has been nothing like as absurd as you suggest. I also agree with Gregor that your critique of Smith is not as even-handed as the rest of your post. But in any case, I think we can lay aside that disagreement, because I don’t believe that my views on this subject really depend in any substantial way on Smith’s book.

    Regarding “mechanisms of interaction”, you say: Emergence comes about from the way we use things, the way things contingently interact, not from the mechanisms of interaction per se, which can and indeed can only be strictly formal. That’s reasonable, but what if those mechanisms are themselves precisely the object onto which we want multiple perspectives? I can’t answer this question, but I feel that it gets at the basic tension.

    So I mostly agree with you regarding formality, but qualified by the last paragraph. It seems to me that formality is a necessary part of any particular view on a system, but there’s no particular locus or mechanism in the system you can point to and say “this part is formal, and formal in this way.” Multiple views (each formal) may exist on any particular part of the system, I think.

    Regarding the notion of effectiveness, I disagree with your position that we need more of it, plain and simple. In my view, what we need is to make it a slider, understanding when we want effectiveness and when we don’t, and how to get each of these in a useful and disciplined way. Gregor also makes this point in his comment, if I read him properly.

    But I would go further. To summarize my view, I would say that in any particular view or way of looking at a system, there is a tension between effectiveness and informality (effectiveness requires formalism, while informality is hard to make effective). There is also a relationship between the multiple views themselves, and this relationship can also be viewed in multiple ways, some more effective and some more informal. What I believe we need (I don’t know whether this is Gregor’s point, or whether he would agree) are better tools for navigating and articulating the spectrum from effective to informal, and ways to apply these tools to the connections between multiple perspectives (some more effective, some more informal) onto software systems. There is a two-level structure here, but it should not be too confusing for a programmer.

    In this connection, I’m reminded of the various attempts at defining weak n-categories, but maybe that analogy, informal though it is, still appeals to too formal a sensibility for some. ;)

    Finally, regarding the quantum mechanics question, I agree completely…

    I would love to hear your further thoughts on these questions, as well as Gregor’s! If there is some other venue than blog comments for discussing these ideas, I’d love to know.

  4. Roly Perera says:

    Wow. You make some awesomely subtle points…in fact, at the risk of appearing to be claiming that I had some of those subtleties in mind already…well, I had some of those subtleties in mind already! Um, there’s a lot to say in response, and I also have to respond to Gregor’s post. I finally have some time to get some thoughts together, so hopefully I’ll have something to say in the next few weeks.