From: Austin Ziegler Date: 2006-06-15T04:44:22+09:00 Subject: Re: Cut-based AOP On 6/14/06, transfire@gmail.com wrote: > Austin Ziegler wrote: >> We've had a discussion recently. *Convince* me that AOP will make a >> Ruby developer's life significantly better than what I have described >> ("plugin points", inheritance/composition wrapping) as well- >> understood and I'll support you. My problem isn't with your RCR; my >> problem is with AOP. Right now, it's just a buzzword with little >> value. If it has value, I am convinced that you can change my >> opinion. > Ha ha! You're funny Austin. It took over 20 years for OOP to gain > acceptance. 20 years! You expect me to do the same for AOP in a couple > of mailing list posts? The success of OOP grew out hands on work with > it's concepts. The success, or failure, of AOP will only come about in > the same way. Of course if we never have good tools for working with > AOP how will we ever know? Yes and no. OOP's biggest problem to adoption was not the concepts behind OOP as much as (1) its early proponents and (2) moronic decisions by vendors. I'm not asking for you to make me *accept* AOP, but asking you to explain to me -- in concrete terms -- why I should investigate this nascent concept further. I really see nothing that I can't do with the existing Ruby capabilities and maybe an enhancement or two along that line. (Early proponents of OOP were *almost* as bad at describing OOP as proponents of AOP seem to be. The moronic vendor decisions tend to involve significant overpricing of OO development tools given that C development tools were pretty dominant. Better options for Smalltalk could have been given, and then we wouldn't have to deal with C++ or Java as we do now. :( > While everyone's busy bashing AOP, other people are trying to see what > *orthoginal design* can do. It would be nice if we could use Ruby to > do the same and with a solid foundation like cuts (which again would > be an optional library). I'm not bashing AOP. I'm just not seeing that it gives "orthogonal design." I'm seeing a bunch of buzzword nonsense masquerading as "advancing CS" being applied to a language that is remarkably BS-free at this point (that being Ruby). I'd like to keep Ruby BS-free. I'd also like Ruby to be on the leading edge of developer thought processes. If AOP isn't BS, it should be easy to explain -- and demonstrate through pseudocode -- what benefit I would get from it now. So far, no one has been able to do that in terms of Ruby, and the examples given in various other places don't give me any great confidence about the technique for *any* language. AOP is one of those things that, to me, seems to allow moderate reuse of code *within* a project, but *never* between projects (it subverts the data hiding of OO). I really *do* want to understand this one, Trans. But so far, it makes little sense in terms of Ruby, and only a little more in terms of statically typed languges. > But to play along a bit you might be interested to know that the whole > reason I got into AOP is because I started doing AOP before I even > knew what is was or that the concepts were already out there. Perhaps > you recall GUtopIa? [...] Vaguely. I'm not really seeing why AOP would help you here in the least. > Seems like a good deal to me. Except that I have no more understanding of the practical benefit of AOP than I did before your post. That's what I want, Trans. Help me understand. I'm *not* trying to be down on this, I'm just trying to cut through the buzzwords that most AOP proponents use. At this point, I don't see any benefit that can't be replicated through far better-understood mechanisms that would suggest such a major language change (even if access is limited through loading a support library as well). -austin -- Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/ * austin@halostatue.ca * http://www.halostatue.ca/feed/ * austin@zieglers.ca