[Look out: there is hand-waving! -ed.]
I was reading the background on Dylan's condition system, where the author describes exceptions as "situations that must be handled gracefully but that are not conceptually part of the normal operation of the program." Exceptions are a nice example of a linguistic abstraction that strictly increases the expressive power of a programming language. (Stated without proof, but we've all seen the exception monad.) And they introduce the possibility of non-local effects in code that can't in general be detected by local inspection.
AOP is often described as an answer to the problem of "modularizing cross-cutting concerns." Any time you have something that can't be expressed with the abstraction mechanisms of your given language, it ends up being scattered throughout the program in multiple modules. Well, it sounds like they're trying to take credit for all of linguistic abstraction. But nobody is going to come up with the once-and-for-all abstraction mechanism to eradicate all need for new linguistic abstractions.
On the somewhat less over-reaching side, AOP has popularized a set of (relatively) new linguistic abstractions to the lexicon, and they're useful ones. The few that stand out are before/after and around patterns and control flow inspection. These are useful linguistic abstractions, and as usual, they introduce expressive power at some cost of local reasoning.
I wouldn't be upset if history forgot AOP as a field per se and just kept the collection of useful programming mechanisms it's produced. Because the heady claim that AOP "modularizes cross-cutting concerns" is really just hype. Or at least, it doesn't distinguish AOP from any other linguistic abstraction; any language feature that modularizes scattered code--exceptions, for example--helps separate cross-cutting concerns.
Dave Herman's research blog.
Blog Archive
-
▼
2005
(122)
-
▼
June
(23)
- I made some science.
- Tail-applicative continuations
- Quickest way to circumvent tail-recursion in Scheme
- Strict Haskell
- Welcome to the future
- Literate programming
- 1000th site visit
- Observing tail calls
- We have met the enemy, and it is... hidden invariants
- Real world PL design
- Eich on Javascript's future
- ClassicJavascript
- Too much recursion
- (TMTOWTDI)
- Point for The Economist
- DHTML resources
- Javascript surprises
- There and back again
- AOP is...
- Deep ideas lurking in Object-Oriented Style, part II
- Deep ideas lurking in Object-Oriented Style, part I
- Curry-Howard, logically
- Multi-stage web programming
-
▼
June
(23)
4 comments:
After seeing several talks about AOP, I came to the conclusion that the best way to think about them is as an object-oriented programmer's rediscovery of monads in the same sense that XML is an object-oriented programmer's rediscovery of s-expressions. When you cut through the thick layer of (from what I can tell) nonsensical hype and kind of crufty technology, what you've got is a way of overriding a program flows from one expression to the next in such a way that you've got an opportunity to do all kinds of sneaky stuff. I suppose if you want to call that "separating out cross-cutting concerns" you can reasonably to so, but it seems like the cross-cutting-concerns terminology is one of those businessy terms that sounds impressive but is hard to pin down to an actual meaning.
I think you've done a lot more studying of AOP than I have, so if you disagree with me you're likely to be right :), but the aspects-as-monads paradigm has served me well in understanding what aspects are all about.
I mostly agree; it's an important correlation, insofar as both AOP and monads are trying to address the idea of linguistic abstraction. Both are frameworks for extending the semantics of a base language in a way that increases its expressive power, though at the expense of local reasoning. But I don't think either deserves to be considered "the" answer to solving cross-cutting concerns.
You could put all of the following technologies under the same umbrella of "growing a language:" AOP, macros, monads, meta-object protocols.
I know that at some level of abstraction any set of things can look the same. But for me, the most useful aspect (*cough*) of drawing this correlation is that it makes it clearer why you keep seeing the same controversies appear over and over in each of the different areas, e.g.:
A: Ooh, look at my pretty new abstraction!
B: Where's my local reasoning?
A: The tools! The tools!
If you turn AOP inside-out, and insist on types, it is possible to deal with all this cross-cutting concerns mumbo-jumbo in nice ways. Oleg Kiselyov and I have been working on this in MetaOCaml with some nice results. We talked about Template Haskell, but because it is untyped (ha!), that did not seem very satisfying.
We ended up having to use a Monad, CPS, higher-order Functors, a bit of syntactic sugar, polymorphic variants as well as meta-programming, but that is all in the infrastructure, the final code isn't too bad. (This was accepted to GPCE 05)
The real difference in our work (other than all the types!) is that we do not modify pre-existing code, which destroys all local reasoning, but rather build code from the ground up by weaving together all of its aspects. This restores the ability to do local reasoning!
If you turn AOP inside-out, and insist on types...
I'm not insisting on types, just some kind of reasoning tool, of which types are only one example. (It's not too controversial a point, really. When people decry the loss of local reasoning, AOP apologists tend to promise tool support as the solution.) For example, Kathi Fisler's and Shriram Krishnamurthi's work on verification techniques for AOP looks like an interesting alternative to types. I have yet to look deeply at this, though.
Your paper looks interesting--I'll take a look. Thanks for the pointer!
Post a Comment