Section 5.1. A MATTER OF STYLE

5.1. A MATTER OF STYLE

Giving an historical perspective of a technology involves stating facts as much as it involves describing the technical context in which the technology emerged and understanding the dynamics of the group of people who created it. Having been part of that group, I am in a privileged position to tell the AOP story, or at least a rendition of that story. I have not been active in the AOP project since the summer of 2000, so I can't report the project's history since then. Many people have joined the team after I left and have made significant contributions to the current version of the language.

Like most historical perspectives, this one is based on facts, but the interpretations and comments are entirely my own. Also like most historical perspectives, this one is incomplete: It focuses on the period 19951998, the time when AOP and, later, AspectJ emerged. A lot had happened before, and a lot has happened since then.

AOP, as such, started emerging in 1995 when I was already at PARC as a visiting student. In the years that followed, one of the types of questions I was often asked was, "What is AOP?" Is it a programming language? Macros in disguise? A design methodology? A clever pre-processor? Meta-programming? How is this different from X (replace X with your favorite programming trick or language feature)? The other frequent question was, "What are aspects?" Synchronization and tracing feel like aspects, but what else? And what makes an aspect an aspect, anyway?

As I'm writing this chapter, eight years later, I have good answers for all of these questions, but that wasn't the case back in 19951998. In fact, many brilliant minds have blamed the AOP group for propagating subversive ideas without having clear definitions for what we were trying to do. They were right: Our definitions were fuzzy and got clearer over time. Back then, we had two options: We could lock ourselves in the office for a few years, brainstorm and beat the thing to death until we figured it all out; or we could bring a semi-baked idea to the public and iterate it with a larger community until the clear definitions would emerge. We chose the latter. The reasons for this choice are as much pragmatic as they are a matter personal style. The pragmatic reasons included the following. First, we all believed that the validation of the AOP thesis (i.e., that it led to better programs) could only be done outside the controlled environment of our offices. So there was no point in locking ourselves up to come up with a beautiful formal semantics, because that would miss the core of the thesis. Second, we also believed that what we were doing crosscut the boundaries of the traditional communities in software engineering and programming languages. We needed to get early input from different kinds of people, especially from "real programmers," our ultimate evaluators.

Many researchers will probably identify with this need to reach out in order to validate their work; others won't. Again, a matter of style. But among those that do, not many can do it successfully, even when their work is impressive. It takes financial support, a good team and a good team leaderthese are all management issues that many researchers tend to overlook. The popularity of AOP and AspectJ is due, firstly, to Gregor Kiczales, not only for his technical leadership but also for his natural ability to secure resources and attract people.