The only thing worse would be GOTO + OOP, which of course = C++

Wikipedia linkage [wikipedia.org]

In computing, the programming paradigm of aspect-oriented programming (AOP) centers on constructs called aspects, which treat concerns of objects, classes, or methods. The aim of AOP is to separate program code related to the main purposes of the application (its core concerns) from code related to secondary purposes (cross-cutting concerns).

For example, a telecommunications application might have a core concern of routing calls, while code for timing and billing those calls would crosscut the whole object hierarchy. AOP aims to separate the billing concerns from the core concern. It moves code not related to solving the domain problem from the business logic into a separate module. The application code no longer contains pieces of crosscutting concerns scattered across modules; instead, programmers maintain crosscutting concerns in aspects; this makes it easier to maintain both core and crosscutting concerns.

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.

who is going to shell out that cash for 5 pages?

"Powerful language constructs can be dangerous when misused"

Thank you for the wonderful advice and welcome to 1971!!

As for the GOTO comparison, it is disingenuous. The problem with GOTO is not that it is a flow control change, the problem is that it is an [i]unstructured[/i] flow control change. AOP is nothing if not structured, in fact its potential flaw lies in that the structures it represents can be so complicated the programmer can lose track. It's the absolute opposite of GOTO.

Really, I did read the article, but the headline is kind of discomforting. I mean, how is it harmful? If I were reading this headline while writing aspect-oriented code, should I stop immediately? I wouldn't want to die, you know. If I'm going to die, Slashdot, you need to let me know!

Useful technique, chemical, or product can be dangerous when misused! With this groundbreaking announcement, aspect-oriented programming joins up with jet planes, oxygen, razor blades, and almonds. Scientists urge all Americans to avoid anything that could, in any way, be harmful to anyone, and the government will begin production of mandatory Full Isolation Spheres (tm) within the week.

http://angryflower.com/aposter.html [angryflower.com]

The one-paragraph 'article' is just a tagline for a 250 dollar document. Quite dissapointing to read that lead in and find that I won't actually be aquiring any new information on the topic. :\

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*

I like OO but is isn't great for every task. For instance, logging (which is the default example for AOP) is really bad in OO. This is because you have to add something like

Log.printLog("some message " + someObject.toString());

everywhere you want to log something. But with AOP you can used kleen operators (*, +, ?, etc) to add Log.printLog() to certain methods of certain objects. Aspects allow you to inject code into method call boundaries. But like all programming constructs it can be abused. This is because you might get an exception stack trace that indicates a specific method call has thrown an exception when the exception came from code inserted by an aspect. But other languages can be abused too (Perl anyone). So I think this type of critism of aspects says more about the critic than about the programming construct. I don't use C++ to implement logic evaluators (I would use Prolog or another logic or unification based language). Nor do I try to write OO code in LISP (despite the horrid OO extensions for LISP) because each language has it strengths and weaknesses. For each application choose the language that best suites the task.

On another note, I think these types of critisms are really from people who are afraid of learning new languages or skills. They have worked long and hard to get good at C (or Java or some other language) and don't want to have to learn another language. Well suck it up, there aren't many Fortran programmers anymore and if you want to keep working, you must keep learning new languages and skills. Not that you should jump on every bandwagon, but if I'm writing something that needs to be really, really fast I use C. If I'm writing something that needs to be maintainable forever and speed isn't that important I use Java. The best tool for the task.

What the submitter failed to mention is that to read this article you have to stump up with $250. The comment in the submission is merely from the executive summary.

'It's worth it'. Come on, how many people here read the article, let alone will pay $250 for it?

Two fifty to hear some twat tell you that a new technology is good, but only in the right circumstances used by trained people.

What bollocks.

Do any CIOs still buy this crap? Do the sensationalist headlines do the job and actually sell this bs? "AOP considered harmful"...be afraid...be very afraid!

I personally don't have a week go by when we don't find another great use for AOP...and we write financial apps...so that blows his 'frameworks only' theory out of the water.

But I suppose "AOP, useful sometimes in the right circumstances if you make sure you train your people on how to use it, not so useful in others" doesn't exactly sell those $250 a pop articles, does it Carl

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.

GOTO doesn't cause harm (or its syntax sugared grandchildren), it's the programmer who is not able to understand when to use it or not. Such programmers are a harm by themselves :-)

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.

How do I get suckers^H^H^H^H^H^H^Hfolks to pay $250 for my 5 page speculations on computer science topics? Seriously. I'm an academic, and I write 20+ pages per month of this stuff for free. If I could get even 100 people to pay $50 per page each for it, that would be $100K per month: that's way more than I make in a year at my current job. Leaving aside the question of the price of my immortal soul, it doesn't sound like too bad a gig.

I started to list my qualifications, but got tired of typing. Suffice it to say that they're way more than that Forrester guy has. Let me know folks: if 100 of you pay me $50 per page each, I'll research pretty much whatever you want.

When i worked at IBM research labs, i criticized AspectJ using almost exactly the same words: they try to solve specific issues (logging, persistency, etc), that deserve specific solutions, using a completely generic approach. They failed to provide more examples for those specific problems that AspectJ will solve. Of course, i was silenced - because that's the way it works in IBM Haifa - they just can't deal with criticism :)

The concepts behind AspectJ, TMO, are not bright. They break encapsulation, they are too ambitious and far from real-world understanding of programming concerns. All in all, they introduce too many problems.

TMHO,Aspect Oriented Programming should be different, and should be based on something much simpler, much more down-to-earth ideas and more consistent with real-world needs.

Today it is easily possible to do using Java Annotations, that will specify class member's affinity with an aspect, and thus provide:

A) a mechanism by which the compiler could limit access (errors & warnings) to members according to their affinity with a common aspect or aspects (common to it and its caller);

B) a programmer, using a proper IDE, can view a breakdown of his code according to aspects.

C) in runtime, the current aspect should be visible to the program thus extending the ability to: I) log, and trace errors; II) affect work-flow according to the aspect in action (that's an intense feature so im not too sure about that)

Doing more than the above, looks to be like an abuse of proper programming concepts.

The Annotation mechanism introduced in Java 5 is quite powerful and maybe already provide all that is needed for the job, including hierarchical arrangement of aspects (slash annotations), attributes, etc. Very little is needed in order to implement what i propose.

Maybe i'll propose is to the JCP. What'd ya think?

So let me get this straight..

AOP basically means that when an object is created, or a method is called you wan't to run some code?

So if we tried to put this into a non-OOP example you would basically be calling something else whenever certain functions were called? Eg calling a 'save', 'load' or 'start' function would result in running the 'logging' function too?

But as I gather (and its pretty hard to find a simple explanation around here) the idea of AOP is that it allows you to do this without having to put any function calls in your code, ie it 'captures events'. So if for example you had to implement some security checks but you were worried that someone in your project would forget to put the 'if(secure)' lines into their modules you could rest assured that AOP would be on the case.

Then theres COME FROM which is basically an event handler that says 'when you get to this line/label in your code, come over here and run me.

I see no problem with this in a relatively high-level environment where the goal is to write less code and where so much crap is going on in the background anyway (dynamic this and managed that) that another overlay is just going to make things look simpler.

Isn't this however almost exactly the same as an interrupt?

And since Aspect-Oriented programming is a patented technique [mit.edu], basically nobody can legally use it unless you're a personal friend of the inventor.

So, who really cares if its theoretically any good, when legally it is worthless?

I've been following AOP (cautiously) for some years now. Here's a few salient points for those who don't have $250 to splash out.

The underlying principle of AOP is about "separation of concerns", a term introduced by Dijkstra back in 1974. Separation of concerns is a Good Thing[tm], but there's more than one way to do it. It's a conceptual thing more than it is any one particular implementation technique.

Both structured and OO programming offer techniques that allow the hacker to more clearly separate concerns: by organising their code into subroutines, modules, objects, methods and so on. The problem with OOP is that real world problems don't always break down into a set of clearly defined, independant object classes. In some cases you can end up with a problem fragmented into so many small pieces that you can no longer see the wood for the trees.

AOP tries to address this by allowing you to identify those concerns that don't fit neatly into an object model. These "cross-cutting" concerns are typically things like logging, debugging and security that affect many of the objects in your system. If you decide to change the way logging is handled, for example, you don't want to have to go and edit every single object that generates logging information. But that's often what happens in OO based systems - you design your class hierarchy with Products, Customers, Orders and other real-world entities in mind and implement them as "black-boxes" with internal functionality neatly hidden away. That's fine when the functionality really is local to the object, but not when it relates to a system-wide aspect like logging, etc. These are the kind of undesirable artifacts that can arise from the decomposition of a problem into objects.

However, that's not to say that there aren't ways of achieving the good parts of AOP in a non-AOP language. Many Design Patterns are examples of separating concerns. The Model/View/Controller and Model/Visitor patterns come immediately to mind. Going back to the early logging example, we could implement this in AOP fashion in an OO language, by creating a "Logger" object which implements all the logging functionality. Just make sure all your other objects delegate to the logger for logging rather than trying to do it themselves. Now you have all your logging code in one place, and you just have to worry about how you're going to pass the logger object around so that all your other objects can call on it... (and this is often the start of the rest of the problems...)

So AOP-a-like can be done in OO languages, but most OO languages aren't really cut out for it - you have to code the magic manually if you want it. Hence the rise of AOP languages (usually just bolt-on syntax additions to existing languages) that make this process that little bit easier.

AOP in Java does smell a little like GOTO, IMHO. In brief, it uses "join points" to connect different aspects together (e.g. call this logging method just before calling that other method). One can certainly argue that it's a more structured form of GOTO, but I believe the same fundamental problems remain: control flow jumping all over the place, with actions-at-a-distance waiting to catch out the unsuspecting programmer.

So my advice on AOP would be to treat it like OOP, XML, Java, and all the other "silver bullets" that over the years have claimed to be the next big thing that will save our collective software sanity. Recognise the problem that it's trying to solve, realise the benefits of the particular solution(s) presented, and ignore all the hype!

A very well respected (if a bit obscure) OO language is Objective-C. It has a few features that are analogous to aspects.

First it has categories, which allow you to add new methods, or replace the implementation of a method in a given class. You add a category to that class that includes, say, a replacement description method, and the new implementation replaces the old. Or you can add a path utility methods to the String class, as another example.

It also has "poseAs", which allows you to insert an object into a hierarchy. Say you have Class B which extends Class A. But you want custom behaviour to be accessible to all As children (including, for example, B). You create Class C, which extends A, and make it poseAs Class A. Now the runtime hooks all clesses that inherit A off of C, which replaces A. A still exists, but is in the background, providing normal inherited functionality to C.

These abilities were one of the things that made Objective C a very powerful OO language. In particular, it allows a particular kind of reuse, by virtue of allowing one to patch someone else's library without having source. So if you want to add the aforementioned path utilities to NSString, you just added a Category in your own code, and your code would run with the extended functionality in NSString (no one elses would, unless they used your category too). This means that often you can make the most out of someone else's code without a complete rewrite.

It isn't all powerful. There are access and visibility restrictions. It is also used to partition code for ease of organization and better modularization. Here's the point:

Because it is a well known feature of the language, you think in terms of categories, and you know to look for categories. This can be aided by tools, but you most definitely need to pay attention to them. But because of this, they are only "dangerous" if you aren't paying attention. And guess what! That's true of programming, period.

AOP is not the answer to everything, but one of the main points of a talk I give at the NFJS [nofluffjuststuff.com] show is that you can find tons of uses w/ development aspects without ever having to migrate them into production.

You can enforce (and detect violations of) various architectural decisions (i.e. no direct JDBC connectivity without going through a facade), define and enforce contracts (and leave them out of production), detect threading issues (How would you find all Swing thread abuse cases in a large, multi-threaded application?), get a sense of code coverage, etc. around any arbitrary cut of your system.

If you take the time to build around interfaces and support Object decoration via some variant of factories, you can do some of these things using Decorator and Dynamic Proxies, but you don't always have that luxury.

Tool support has been fundamentally lacking until things like recent versions of the AJDT. It still isn't perfect, but should serve to answer many of the early critics complaining about debuggability and losing track of what is going on.

I am an advocate of AOP in production systems, but you don't have to drink the whole glass to find aspects tremendously useful in development alone. With support for Ant-based builds and whatnot, it isn't even really an onerous task to give it a try.

Don't use AOP for things it isn't a good fit for, but there are quite a few things that can't be done as easily and elegantly without it (at least in Java). As others have pointed out, languages like Lisp and Objective-C have support for AOPish things built in.

Just like goto, which I would not totally consider harmful. Goto has its place in programs which need a precise command which maps directly to a processor jump instruction, therefore goto or similar constructs are widely used in system near programming.

I have to admit, I stayed away from AOP for a long time, but that stuff can be really useful if applied in the proper manner. The usual application has lots of sideconstraints which basically stain your algorithms up to a point, where you end up having 2/3rd side constraint code, 1/3rd algorithmic code. The side constraint is constantly the same over and over again, only altered slightly according to the state of the algorithm.

Now if you move that code in a well documented and clean manner into aspects, you can gain a lot. Aspects however are a deadly construct, if you go the AOP is everywhere manner and dont limit yourself to the basic rule, use it seldom and use it wisely but use it whenever you can achieve a cleaner code with it. If you go the aspect here aspect there route, you end up in a bigger mess than with a huge spaghetti code and 100 gotos in there.

Perfect examples for AOP are, to move the error handling code of checked exceptions out of the algorithms into aspects, another one would be to get a clean semi automatic transactional scope in methods which are called from the outside. Both things can be achieved with aspects in a much cleaner way, than with traditional programming, but if you use this stuff in that manner, document it and comment it, otherwise the persons who will follow you cannot see that the method is in a transactional scope.

So aspects are definitely worthwile using (I learned that once I jumped over the wall of considering it a deadly construct), but you really have to be careful to limit it to a few problem domains.

Aspects 'inject' behaviour into your classes. This is fine if the behaviour is completely orthogonal to the workings of your class, e.g. you're injecting enter/exit logging. If you start to inject functionality, however, the workings of the class can be substantially obscured. A number of the examples I've seen can be as properly done with more broken-down normal methods and a naming convention (e.g. before_x, after_x).

That said, chances are that the true benefits of aspect-oriented programming are not going to come from it being a mere curiosity to add to object-oriented programming. Someone is going to have to discover how to program in AOP where the focus is on AOP.

Possibly, it will have a journey like object-oriented programming. Started out with being used as object-based programming (just a more convenient way to associate data with functions), grew to some standard uses, then exploded into class libraries and eventually patterns.

Even 'interface-oriented programming' requires a slightly different tack than plain object-oriented programming does.

That's not to say that AOP will be the next actual big thing, or even really find its niche. There are plenty of good ideas that never really 'made it'. Time, and a whole passel of people with a lot of on their hands, will tell :)