IBM Developer Works has an interview with Grady Booch. He has some mildy interesting things to say, and tries yet again to explain aspect oriented programming. Unfortunately, I still don’t exactly get it. Here’s his description:

Moreover, if I polish off my crystal ball I foresee the rise of aspect-oriented programming (see Resources). Today’s large software systems, systems of quality economic value, include tens of thousands of moving parts, so we tend to never turn them off.

This is easy enough to understand. Total agreement here.

Therefore, the challenge becomes how to morph such systems without turning them off and yet add value with many stakeholders as part of the solution. Stakeholders can range from graphic artists, to network types, to security people, to business experts.

So he’s saying that we need a way to make changes to systems that have to have as close to 100% uptime as possible. I’ll buy that. It would be great to have a way to improve existing systems without taking them down or more often, completely rewriting them using the latest and greatest tools.

In such cases, you can’t face the problem as a traditional programming problem. In fact, you’re no longer building a program — it’s morphing parts of a large system with those parts interconnected with each other.

So the problem aspect oriented programming attempts to address is modifying a part of an interconnected system without having to make changes to the other parts that are connected to the part that you’re changing?

In that context, with aspects you build those systems from threads that cross-cut through those pieces and let domain experts from those particular views express an aspect. In the next two years or so I think aspect-oriented programming will bear fruit in testing, deployment, and business rules.

Here’s where I get confused. Don’t we already build systems using “threads” that cross-cut through various parts of a system? I’m not sure what “thread” means in this context, but when I build a large application, I use a common logging system for all parts, a commond database driver for all parts, and many other common pieces of all parts. I generally refer to these pieces as libraries. How is an “aspect” different? How is abstraction achieved so that you can modify one of these so-called “threads” without changing everything that uses it? Let’s say changes are made to my logging system of choice — log4j. Either the changes are all internal and the outward facing interfaces remain the same, or the change is radical enough that the interface changes. If the API doesn’t change, I can probably just drop it in and reap the benefits. If the API changes, everything that calls that API has to be updated. How does a logging “aspect” differ? Is there something going on here on the tools side that enables the application that uses the aspect to be modified on the fly to take advantage of changes to the logging system’s API?