3 ms·

Are there any general-purpose languages that actually follow an aspect-oriented paradigm? Would such a language even be possible or desirable?

jerf 17y ago
Java has some add-on libraries that do it. It's hard to judge whether it's a good idea there because Java's OO is so brain-dead by design that it's hard to tell whether a technique is truly good, or just offsetting Java's utter simplicity. (By "by design", I mean that Java chose its simple model; it is by design. It is so simple that it is very difficult to use any sort of sophisticated programming technique without serious external libraries or immense class hierarchies.) Many other languages have things that are very similar, certainly more "aspect oriented" than CSS. Lisp can do this very easily, and emacs uses something very like it a lot, complete with similar terminology for "advice". Ruby and Javascript's monkeypatching can be seen as something very like aspect oriented programming. Writing your own aspect system is pretty easy; I've got something in work in Perl that actually has things called aspects, for instance. In each case, pedants will justifiably point out that they aren't actually "aspect-oriented" according to some strict definition, but I've sworn off caring about whether something meets a strict definition unless you can show me at least one scientific study of reasonable scope that verifies that things meeting a particular definition are good and even small deviations from the particular definition show noticeably worse performance. (See also: arguing about exactly what the "unit" in "unit" test means as if it actually has any actual force behind it.) I will say that each of them shares enough similarities that it crowds out the full technical definition of "aspect oriented". It's not a coincidence that the term became large in Javaland. See also "dependency injection", where what was common practice in other languages actually grew a pattern name in Java because it's so much harder you have to do it deliberately, instead of accidentally like you can in better languages. (Yeah, I will cop to thinking Java is a very technically weak language, in the sense it takes reams of code to do anything useful from a design standpoint. That doesn't mean it's bad, but it does mean I personally don't like it and I do not apologize for my personal preferences.)
jonnytran 17y ago
I think a better question would be, do any languages have features that help _you_ follow an aspect-oriented paradigm? At the end of the day, you can use just about any paradigm in Java. By no means does it enforce OO. Ditto for just about any other language. But certain features make it easy to use OO, so when using it, you feel compelled to use that paradigm. Do any languages make it easy? Ruby, for example, allows it. But it feels like it was never intended. Someone actually just posted about this on HN: http://cfis.savagexi.com/2007/09/05/rails-unusual-architecture http://cfis.savagexi.com/2007/09/05/rails-unusual-architectu...
amatriain 17y ago
The Spring Framework for Java is supposed to have pretty good support for AOP in Java. I haven't used that particular feature of Spring so I can't vouch for it, but Spring is generally excellent so I expect no less from this.
- lucifer 17y ago
  Its actually watered down aop. AspectJ sets the standard in AOP for Java.
- fforw 17y ago
  Spring has support for both container based aspect, which applies to the beans under spring's control and "real" AOP based on AspectJ.
arebop 17y ago
AspectJ (http://www.eclipse.org/aspectj/ http://www.eclipse.org/aspectj/) is IMO a pretty good implementation. I've used it recently for an Android application. Gregor Kiczales (http://www.cs.ubc.ca/~gregor/ http://www.cs.ubc.ca/~gregor/) used it for a conference tutorial I attended a few years ago, so that's a sort of implicit seal of approval from him as well. On the other hand, he did point out that it couldn't handle all the examples he showed in his paper (which were implemented in Lisp). I was not impressed by the various AOP libraries for .NET when I looked at them several years ago. They imposed so many requirements on my code that it seemed to defeat much of the benefit of AOP's beautifully elegant combination of joinpoints and advice. A problem with AspectJ and I suspect with most implementations is that weaving and optimization can conflict. For example, if a method invocation is inlined by a compiler, the compiler needs to know about applicable advice. This complicates pointcuts and it means that AspectJ can't necessarily be used like dtrace to instrument code you didn't write.
- lucifer 17y ago
  Don't think the optimization point holds. Optimization for Java really kicks in at runtime and the JVM is fully in loop regarding byte code modifications.

jerf 17y ago

Java has some add-on libraries that do it. It's hard to judge whether it's a good idea there because Java's OO is so brain-dead by design that it's hard to tell whether a technique is truly good, or just offsetting Java's utter simplicity. (By "by design", I mean that Java chose its simple model; it is by design. It is so simple that it is very difficult to use any sort of sophisticated programming technique without serious external libraries or immense class hierarchies.) Many other languages have things that are very similar, certainly more "aspect oriented" than CSS. Lisp can do this very easily, and emacs uses something very like it a lot, complete with similar terminology for "advice". Ruby and Javascript's monkeypatching can be seen as something very like aspect oriented programming. Writing your own aspect system is pretty easy; I've got something in work in Perl that actually has things called aspects, for instance. In each case, pedants will justifiably point out that they aren't actually "aspect-oriented" according to some strict definition, but I've sworn off caring about whether something meets a strict definition unless you can show me at least one scientific study of reasonable scope that verifies that things meeting a particular definition are good and even small deviations from the particular definition show noticeably worse performance. (See also: arguing about exactly what the "unit" in "unit" test means as if it actually has any actual force behind it.) I will say that each of them shares enough similarities that it crowds out the full technical definition of "aspect oriented". It's not a coincidence that the term became large in Javaland. See also "dependency injection", where what was common practice in other languages actually grew a pattern name in Java because it's so much harder you have to do it deliberately, instead of accidentally like you can in better languages. (Yeah, I will cop to thinking Java is a very technically weak language, in the sense it takes reams of code to do anything useful from a design standpoint. That doesn't mean it's bad, but it does mean I personally don't like it and I do not apologize for my personal preferences.)

jonnytran 17y ago

I think a better question would be, do any languages have features that help _you_ follow an aspect-oriented paradigm? At the end of the day, you can use just about any paradigm in Java. By no means does it enforce OO. Ditto for just about any other language. But certain features make it easy to use OO, so when using it, you feel compelled to use that paradigm. Do any languages make it easy? Ruby, for example, allows it. But it feels like it was never intended. Someone actually just posted about this on HN: http://cfis.savagexi.com/2007/09/05/rails-unusual-architecture http://cfis.savagexi.com/2007/09/05/rails-unusual-architectu...

amatriain 17y ago

The Spring Framework for Java is supposed to have pretty good support for AOP in Java. I haven't used that particular feature of Spring so I can't vouch for it, but Spring is generally excellent so I expect no less from this.

lucifer 17y ago
Its actually watered down aop. AspectJ sets the standard in AOP for Java.
fforw 17y ago
Spring has support for both container based aspect, which applies to the beans under spring's control and "real" AOP based on AspectJ.

arebop 17y ago

AspectJ (http://www.eclipse.org/aspectj/ http://www.eclipse.org/aspectj/) is IMO a pretty good implementation. I've used it recently for an Android application. Gregor Kiczales (http://www.cs.ubc.ca/~gregor/ http://www.cs.ubc.ca/~gregor/) used it for a conference tutorial I attended a few years ago, so that's a sort of implicit seal of approval from him as well. On the other hand, he did point out that it couldn't handle all the examples he showed in his paper (which were implemented in Lisp). I was not impressed by the various AOP libraries for .NET when I looked at them several years ago. They imposed so many requirements on my code that it seemed to defeat much of the benefit of AOP's beautifully elegant combination of joinpoints and advice. A problem with AspectJ and I suspect with most implementations is that weaving and optimization can conflict. For example, if a method invocation is inlined by a compiler, the compiler needs to know about applicable advice. This complicates pointcuts and it means that AspectJ can't necessarily be used like dtrace to instrument code you didn't write.

lucifer 17y ago
Don't think the optimization point holds. Optimization for Java really kicks in at runtime and the JVM is fully in loop regarding byte code modifications.