TITLE: Toward Less Formal Software
AUTHOR: Eugene Wallingford
DATE: March 01, 2008 3:39 PM
DESC:
-----
BODY:
This week I ran across Jonathan Edwards's
review
of
Gregor Kiczales's
OOPSLA 2007 keynote address, "Context, Perspective and
Programs" (which is available from the
conference podcast page).
Having recently
commented on
Peter Turchi's keynote, I figured this was a good time
to go back and listen to all of Gregor's again. I first
listened to part of it back when I posted it to the page,
but I have to admit that I didn't understand it all that
well then. So a second listen was warranted. This time
I had access to his
slides,
which made a huge difference.
In his talk, Kiczales tries to bring together ideas from
philosophy, language, and our collective experience writing
software to tackle a problem that he has been working
around his whole career: programs are abstractions, and
any abstraction represents a particular point of view.
Over time, the point of view changes, which means that
the program is out of sync. Software folks have been
thinking about ways to make programs capable of responding
naturally as their contexts evolve. Biological systems
have offered some inspiration in the last decade or so.
Kiczales suggests that computer science's focus on
formality gets in the way of us finding a good answer
to our problem.
Some folks took this suggestion as meaning that we would
surrender all formalism and take up models of social
negotiation as our foundation. Roly Perera wrote a
detailed and pointed review
of this sort. While I think Perera does a nice job of
placing Kiczales's issues in their philosophical context,
I do not think Kiczales was saying that we should go from
being formal to being informal. He was suggesting that
we shouldn't have to go from being completely
formal to being completely informal; there should be a
middle ground.
Our way of thinking about formality is binary -- is that
any surprise? -- but perhaps we can define a continuum
between the two. If so, we could write our program at
an equilibrium point for the particular context it is in
and then, as the context shifts, allow the program to
move along the continuum in response.
Now that I understand a little better what Kiczales is
saying, his message resonates well with me. It sounds
a lot like the way a pattern balances the forces that
affect a system. As the forces change, a new structure
may need to emerge to keep the code in balance. We
programmers refactor our code in response to such
changes. What would it be like for the system to
recognize changes in context and evolve? That's how
natural systems work.
As usual, Kiczales is thinking thoughts worth thinking.
-----