Slashdot Mirror
Aspect-Oriented Programming Considered Harmful
kupci writes "The 'x considered harmful' cry is a little overused, but there is a Forrester report that discusses some of the pro's and con's of Aspect-oriented Programming, and includes some interesting links. It is mainly based on papers from the University of Passau. It's worth it just for Clark's 'COME FROM' article." From the article: "Aspect-oriented programming (AOP) is intended to address common problems that object-oriented programming (OOP) doesn't address well, plus some problems that OOP itself created. However, AOP is a risky solution: It is a very generic mechanism for solving some very specific concerns and has been likened to a kind of "GOTO" statement for OOP. Like GOTO, it can cause more harm than good."
There's a new idea in field I am incapable of getting a job in that is gaining in popularity among people I wish cared about my opinions. Buzzword I am dissing is intended to address common problems that buzzword everyone likes doesn't address well, plus something into which I have no insight. However, buzzword I am dissing is a risky solution: Complaint which betrays my ignorance and has been likened to somthing everyone hates. attack by analogy. Buzzword I am dissing will find some uses among people I secretly envy, but for the needs of (me) typical application developers, language gurus would do better to write something I can understand. My paper is important, pay me $50/page to read it.
At the risk of being modded troll, nuking my karma, being yelled at, laughed at, and otherwise folded, spindled, and mutilated, I'm gonna say it:
I like GOTOs. GOTO has it's place. Even in C++. Sorry all you purists, but there are times when it just plain works.
*runs and puts on Chinese wicker fighting suit and hides, trembling, behind a flame-retardant wall*
Nothing is inexplicable; only unexplained -Tom Baker, Doctor Who
Any program has principled points (join points) where programmers can identify and modify the program semantics. In AOP, programmers specify join points using a language feature called a pointcut, and specify the behavior to join those points by using advice such as methods or functions. Some variants of AOP allow programmers to extend the types in the system. These features enable aspects to implement behavior for concerns that crosscut the core concern of the application.
Excuse me, but was that supposed to mean something?
Let's say you've got objects a, b, and c.
Objects a and b do something useful (the core of the application)
Object c (an aspect) wants to perform an operation when something happens in object a (a concern).
Object c (an asepct) also wants to do different things when something happens in object a and b (crosscutting a concern).
I look at this as a really complicated event notification system. Comments calling this 'goto for OOP' also seems rather appropriate.
The bad thing about AOP is that it adds lots of side effects to function calls and can thus make the program very hard to reason about. This is completely orthogonal to (purely) functional programming that intends to remove side effects thus making it easier to reason about programs.
Functional programming: f(1) == f(1) always, with no other effects to "global state" etc.
Imperative programming without AOP: f(1) != f(1) necessarily at every point of the code, as the function can access globals. It can also change the global state, so its effect is more than returning its value; it can have side effets.
Imperative programming with AOP: Same as above, plus the side effects may happen somewhere unrelated to the definition of f itself.
The big IT consultancies like Forrestor, Meta, gartner, etc are intellectually bankrupt. If you want an example, read the free article off of Forrestor's web page on IT metrics. It's absolutely worthless. Believe it not, it says that you should evaluate your IT department based on a balanced scorecard that is calculated by, among other things, the number of steering commitee meetings you have. Yes, you read that right, the more meetings the better your department is.
These consultancies ran out of ideas a long time ago, and are trying to turn IT ito some Six Sigma pseudo-science. It doesn't work, but idiots still buy into it because it sounds impressive.
Tristan Yates
No, the problem with GOTO is that, as a consequence of being an unstructured flow control change, it makes it impossible to trust your reasoning about code because it destroys your ability to scope it.
..."
To quote: "... it becomes terribly hard to find a meaningful set of coordinates in which to describe the process progress
I think Dijkstra's point was that any construct that does this is harmful.
Structured constructs are typically less liable to do this, but only because they are visible and the structure is known.
AOP does have the ability to inject arbitrary code in your function that can change its semantics and you cannot see this when reading the affected code.
No matter how structured that change is, its invisibility makes it impossible to fully understand your code from the source code without 'weaving in' all the aspects explicitly. Like GOTO, it destroys your ability to scope your reasoning of the code to the local view.
As much as I love AOP for a class of problems, this is a very valid concern that needs to be addressed.
It's certainly not the first language featureset that faces this problem; OOP can deal with its own issues with design by contract, either through documented best practices or by enforcing it in the language. I haven't seen much in AOP there, beyond the absence of problematic examples (which would typically come from real-world use).
Freedom is the freedom to say 2+2=4, everything else follows...