I have just been reading in the latest volume of Communications of the
ACM, which has a theme on Aspect Oriented Programming (AOP) and I must
say that I do not think I have ever seen a hot topic more well suited
to lisp.
AOP is a response to a growing realization that OO programming in itself
isn't the perfect answer to all programming problems in the world after
all. In particular there are concerns that does not decompose neatly into
class hierarchies, rather the implementation of these concerns (socalled
"crosscutting concerns") are scattered across the source code making their
maintenance, adaptability and reuse diffcult.
An example could be transaction handling. Suppose you were building a
personnel management application that needed to maintain information in a
database, with transaction control. In a traditional setting, your program
structure would match the personnel view, and the transaction handling code
would be scattered across the routines that were accessing the database.
This makes it difficult to adapt the application to a new setting in which
the transaction handling is very different (such as in non-existing) or to
reuse the transaction handling parts in a new application. The transaction
concern cuts across the entire application requiring lots of changes
everywhere.
AOP systems tries, however, to support a separation of concerns. Even if
the transaction needs to be applied across the application, an AOP approach
would allow the program to collect all the transaction code in one place
and have the system help weave the concern back into the application. Where
such weaving occurs, the AOP people talks about having Join Points.
AOP also argues that although the separation of concerns in theory could
have been handled through foresight from the designers and programmers,real
life just doesn't work that way. Identification of relevant concerns often
happens either during the implementation or afterwards, when an existing
application needs to be moved to new surroundsing/platforms/customers.
Of course, this being a hot topic, all the examples in the comACM issue
talks about Java. The fun (or should I say sad?) thing about this is that
they are busy reinventing lisp wheels for Java. Just as Patterns can be
seen very much as a systematic approach to fixing deficiencies in C++, AOP
is also a whole lot about fixing deficiencies in Java.
(When I read through the Patterns book, I very quickly got the feeling,
that they were mostly solving problems which required something as limited
as C++ to be recoqnized as problems.)
As examples of reinvented wheels, we get:
- the DJ library, which demonstrates the usefullness of reflection and
higher order functions.
(www.ccs.neu.edu/research/demeter/DJ)
- the work on composition filters which is the best demontsration I
have yet seen of why generic functions just is a much better design
than stuffing the methods inside the objects.
(trese.cs.utwente.nl/composition_filters)
- Hyper/J, where they reinvent multiple inheritance
(www.alphaworks.ibm.com/tech/hyperj)
- AspectJ, where they explain why before/around/after methods and method
combination is such a usefull tool.
(www.aspectj.org)
There is even a full twopage article on why having a MOP is a good thing.
(Incidently, the AspectJ work is being led by Gregor Kiczales, so it
is not diffuclt to see where the ideas are coming from in that case.)
There are many myths surrounding lisp, and a good part of these can be
easily dismissed as they are just plainly false, but I have always had some
problems with arguments running along the lines of: "sure, CL has a vastly
superior OO system compared to just about anything else, but do you really
need that kind of power in real life?". Well, its AOP to the rescue.
Renowned scientists in the software engineering field are demonstrating
that the basic OO mechanisms are not enough to properly and efficiently
handle the complexities of modern software. Sophisticated extensions to the
OO systems are needed, concepts that for at least a decade has been part of
lisp.
I think the analysis leading to AOP is fundamentally correct. It is
important to be able to separate the various concerns of a complex
application such that one can develop, maintain and reuse individual
concerns relatively freely, allthough it is not obvious that a lisp
programmer would ever have noticed this to be a problem.
The good news is however that the software engineering community is busy
providing an independently developed showcase for the powers that lisp has
to offer!
------------------------+-----------------------------------------------------
Christian Lynbech | Ericsson Telebit, Skanderborgvej 232, DK-8260 Viby J
Phone: +45 8938 5244 | email: ·················@ted.ericsson.dk
Fax: +45 8938 5101 | web: www.ericsson.com
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- ·······@hal.com (Michael A. Petonic)
"Christian Lynbech" <·················@ted.ericsson.dk> wrote in message
···················@baguette.webspeed.dk...
I think your analysis of AOP -- and Patterns -- is right on the mark.
Only lame-ass programming languages fail to support the bulk of the
gang-of-four patterns book. FWIW, I think the book is good, but
the fact that most programming language make this difficult is astonishing.
As for AOP, I believe that you are correct that it addresses:
- the weakness of class-obsessed modularity
- the weakness of the single-inheritance model
- the weakness of the reflective facilities in most O-O languages
- lack of higher-order functions
- lack of imagination w.r.t. method combination (I'm a Dylan booster,
but the fact is, we blew it on this)
- the failure to realize the importance of syntactic abstraction and
extension
(I avoid the word "macro" these days because of lame stuff like #define.)
> As examples of reinvented wheels, we get:
>
> - the DJ library, which demonstrates the usefullness of reflection and
> higher order functions.
> (www.ccs.neu.edu/research/demeter/DJ)
>
> - the work on composition filters which is the best demontsration I
> have yet seen of why generic functions just is a much better design
> than stuffing the methods inside the objects.
> (trese.cs.utwente.nl/composition_filters)
>
> - Hyper/J, where they reinvent multiple inheritance
> (www.alphaworks.ibm.com/tech/hyperj)
I quizzed the guy from IBM about this, and he admitted in front of a room
full of people that he would much rather have been using Lisp. Frankly,
this work pisses me off because it so blatantly is a half-baked attempt to
work around Java dogmatism.
> - AspectJ, where they explain why before/around/after methods and
method
> combination is such a usefull tool.
> (www.aspectj.org)
If you speak to Gregor privately, he will admit that Aspect/J is meant to
bring
method combination to Java.
Rather than complain about this, somebody should simply spend one
week-end reimplementing the ideas of Aspect/J and HyperJ in Lisp,
carefully noting how long it took to do it, and describing anything that
needed to be done outside of what is trivially supported by Lisp and
the CLOS MOP.
> There are many myths surrounding lisp, and a good part of these can be
> easily dismissed as they are just plainly false, but I have always had
some
> problems with arguments running along the lines of: "sure, CL has a vastly
> superior OO system compared to just about anything else, but do you really
> need that kind of power in real life?". Well, its AOP to the rescue.
>
> I think the analysis leading to AOP is fundamentally correct. It is
> important to be able to separate the various concerns of a complex
> application such that one can develop, maintain and reuse individual
> concerns relatively freely, allthough it is not obvious that a lisp
> programmer would ever have noticed this to be a problem.
Agreed.
"Scott McKay" <···@mediaone.net> writes:
> - lack of imagination w.r.t. method combination (I'm a Dylan booster,
> but the fact is, we blew it on this)
Could you elaborate on that? I am collecting "things to do better next
time".
Andreas
--
"In my eyes it is never a crime to steal knowledge. It is a good
theft. The pirate of knowledge is a good pirate."
(Michel Serres)