Informality sans Mysticism

Gregor Kiczales (of Aspect Oriented Programming fame) gave a keynote talk at OOPSLA’07 titled Effectiveness sans Formality (podcast and slides). Roly Perara has posted a critique, which reminded me that I wanted to discuss it too.

Gregor’s talk triggered a bipolar reaction in the audience: some people said it was the deepest thing they had heard in ages, and others said they didn’t understand a word of it. What impressed me most was his determination to dig down to the true nature of programming, whatever the obstacles. I may quibble with his technique, but I have the highest respect for his intention, and can only hope to emulate him.

I believe that Gregor is raising the central problem of programming. I count Gregor as a fellow anti-formalist. By formalism I mean the belief that we should treat software as a mathematical theorem to be proved, or as a machine to be engineered. Dijkstra is perhaps most associated with the former idea, and Parnas with the latter. Of course every program contains a theorem, and can likewise be seen as a machine, but to view them as such is to miss their most salient features.

Gregor observes that “things are not formal at the top”. By this he means that there are no formal requirements for most software, nor can there be. Most software exists in a social context that has no formalized rules, and which continuously evolves, sometimes in reaction to the features of the software itself. The formalist enterprise presumes a fixed precise specification of requirements. But humans, and their social systems, are not formalized. What are the formal requirements for a Word Processor? How can you derive a design for paragraph style sheets from the nature of writing itself? The hard part of programming is not implementing requirements, but designing the requirements. Formalism begs the most important questions.

Gregor also says that “things are not formal at the bottom”. He quotes Brian Cantwell Smith about the inherent “slop” of the real world as compared to formalizations of it. The point here is that formalization is subjective and provisional. Gregor seems to think highly of Smith, but I found On the Origin of Objects maddening. Instead try William Kent’s Data and Reality, written 30 years ago, a clear and still-relevant discussion of the inherent subjectivity of data modeling. Kent says: “This book projects a philosophy that life and reality are at bottom amorphous, disordered, contradictory, inconsistent, non-rational, and non-objective.”

I believe that it is actually worse – software design is not just subjective – it is chaotic. Designs change abruptly and non-locally in response to tiny fluctuations in requirements, or even the programmer’s emerging understanding of the design itself. The crucial fact is that software is in general a work in progress, never finished. As such, designs never reach equilibrium. The ideals of mathematics and engineering are to optimize a design for simplicity and power. Such optimization does not make sense for a moving target, and wastes energy in design turbulence. I call this “premature design optimization”, and I believe that it is incited by the naïve formalist ideology rooted in our languages and tools.

Anti-formalism has a long intellectual history – whenever there is a movement to reduce some complex domain to be “just” some formal system, a reaction against it emerges. Modern anti-formalists often invoke emergence. The latest fashionable metaphors in software are biology and urban planning. The problem is that all these anti-formalisms are better at explaining what they are not than at offering a constructive alternative. You get a lot of metaphors and hand-waving bordering on mysticism.

This philosophical argument has been raging for centuries, but I believe that software, for the first time ever, gives us a chance to make lasting progress. That is because software is the first human-built artifact with sufficient power and flexibility to expose the problem. Biological, mental, and social systems also challenge the ideology of formalism, but we can’t build them to experiment with alternative approaches. Software for the first time lets us do Experimental Philosophy.

Metaphors and mysticism don’t build systems. This is the problem Gregor frames in his title: Effectiveness sans Formality. Effectiveness means having some way to make things work, even though we reject formalism as the account of how they should work. I paraphrase it as Informality sans Mysticism: the search for a constructive way to build informal systems. That is the central problem of programming.

Gregor gives us some examples of the sorts of informal techniques he has in mind. Read the slides and listen to the podcast. A common theme is the coexistence of multiple views, none of which is authoritative. Roly also talks about pluralism, points of view, and “a paradigm where software components are intrinsically, persistently and bidirectionally connected”. The multiple-view idea is a perennial theme of anti-formalism, to such an extent that I see it as the identifying characteristic of the movement. It is our secret handshake.

My spin is that we don’t need to invent arcane methods to build informal systems. They are already right in front of our noses, in our everyday practice. Informal systems are simply “broken” formal systems. The ideology of formalism makes value judgments about designs, endorsing such things as simplicity, power, efficiency, analyzeability. These properties are optimal – when you have a fixed final design. I claim however that when we look at designs-in-progress, these properties are in fact quite sub-optimal. When you optimize for flexibility and adaptability you want different sorts of properties to take precedence. You want to support half-baked, half-working systems. The problem is that our languages and tools are all imbued with the ideology of formalism, and often take the idealistic stance that the language should only let you state largely settled designs. Static type checking is one example of this tendency: you can’t even compile a program that doesn’t have a large part of its act already figured out (flame retardant: I love types – it is just impractically idealistic to treat a program that doesn’t type check as meaningless and unexecutable).

To uncover clues to building informal systems all we need do is observe where the practice of programming diverges from its ideology. My favorite example is copy and paste. We all know that copy and paste is immoral, illegal, and fattening. Yet we still do it. All of the time. This fact is telling us something. It says that while we should ideally refactor all our copying and pasting into some form of parametric abstraction, that just isn’t always pragmatic. My idea is to “decriminalize copy and paste” by reifying it in the IDE into a first-class language mechanism. First class copy and paste can semi-automatically propagate changes between copies, and let us mine and refactor abstractions incrementally and opportunistically. Such a construct can be seen as a “broken abstraction”, or a “proto-abstraction”, one that is optimized for flexibility rather than a fragile elegance. I have been talking about this idea for a few years now, and I really should demonstrate it, but something else always comes up.

I should admit that I pitched the copy and paste idea to Gregor, and he didn’t totally buy it. So maybe I am misreading him and we don’t actually share a common philosophy. The multi-view conspiracy could be merely my own fevered imagining. Be that as it may, I think that Gregor’s talk was important, and I look forward to seeing where he goes with it.

4 Replies to “Informality sans Mysticism”

  1. Nice commentary. Most of what you say, I agree with and you’ve made me understand his talk much better than the last time I heard it.

    But, one thing that I think you miss is that programs and programming *can* be formal in the middle. Although that is a compromise, it is still usefull. E.g., if you accept an instantiation of some evolving, fuzzy requirements and an imperfect, changing data model then you can apply some useful formalisms to it (e.g., type checking, regression testing).

    Actually, reading your post again, I think you may disagree with this statement. “I believe that it is actually worse – software design is not just subjective – it is chaotic.” Well, maybe…but type checking and regression testing seem to *work*.

    The challenge with programming is to determine which formalisms work, which don’t (and have the courage to throw them out), and then find new (potentially non-formal) techniques to fill the gap. All the while we have to realize that some applications (e.g, device drivers) lend themselves better to formal verification than others (UI design).

    [Andrew – I quite agree that formal methods are important and useful, at the right time and place. What I am against is totalitarian formality. – Jonathan]

  2. Brian Foote contributed a question on pasting in his OOPSLA 2005 Breakthrough Ideas answer: What are the people who paste doing right? However, he misses the opportunity to discuss what people are doing wrong:

    Copy-and-paste is a form of duplication, and can therefore certainly help ease the pain of code duplication. However, it cannot ease the pain of “code triplication”. Many domain-specific languages seem to have code triplication problems. For instance, if the domain-specific language does not have an implicit reference counting mechanism, then the language must have an explicit mechanism — in fact, a heuristic — for knowing the reference count is zero and the resource has fallen out of use/scope. Now, I know the objection: “Z-Bo, you’re silly, DSLs that don’t garbage collect?!” They exist and are widely deployed. Redhat Package Manager (rpm) is a good example! rpm SPEC files are DSLs that provide rpm with it’s intelligence. rpm has a “feature” where you specify a “%dir” directive to note what directories are owned by a package. When the package is un-installed, the directory can be removed IF it’s empty. This parameter is really just a work-around for not having some garbage collection mechanism. What’s more, package management is also really just an informal system. It’s an NP-complete problem that is managed through the use of heuristics.

    My point is that even in programs that handle NP-complete problems you can have mysticism aside from the basic heuristics that pare the problem space.

    Brian Foote touches on another form of duplication in his OOPSLA 2005 Breakthrough Ideas answer: temporal duplication. Saltzer et al’s paper on End-to-end Arguments in System Design addresses exactly that phrase.

    The biggest obstacle I see for Programming as Experimental Philosophy (nice metaphor) is that it requires a complete change in the way academics think. Academics always strike me as too reactionary. Even in a field like Computer Science where things seem remarkably fast-paced, most advances are in response to trends. That’s probably why people often cringe at the statements I make, like telling people they should disregard the notion of abstraction as “central” to Computer Science and regard abstraction as a malaise – I always try to improve a sentence about abstraction by seeing how I can remove the word from the sentence. It’s not that I’m more right or more wrong than anyone else. It’s because I don’t see the value in waiting to react to what other people are doing.

  3. Formalism vs. anti-formalism, seems to me to be a variation on strong vs. loose typing, which in a way is a variation on static vs. dynamic behavior. These arguments are generally about which is right or best, but I tend to see it as a problem domain specific issue. Based on what you are trying to solve, you either need rigor to insure it does exactly what it is supposed to do, or you don’t want rigor so that the solution is shorter or more flexible. The trick is not to pick one or the other, but to allow both.


Comments are closed.