Is AOP a Programming paradigm

Edited by: I.Am.Blogger at gmail dot com

Prerequisite:
“A programming paradigm is a paradigmatic style of programming (compare with a methodology which is a paradigmatic style of doing software engineering). A programming paradigm provides (and determines) the view that the programmer has of the execution of the program.”
(http://en.wikipedia.org/wiki/Programming_paradigm)

Yes:
“I would argue that by any reasonable definition of paradigm, AOP is one. You can "think aspects" starting from fairly early in the design process (probably requirements too); you can design and develop those aspects; you can make the code look like the design; the aspects can be treated as independent units, with independently assessable properties and value. All the things that I at least thought made OO a paradigm seem to apply...”
By Gregor Kiczalse(http://aosd.net/pipermail/discuss_aosd.net/2004-July/001001.html)

“…Note that the original meaning of "paradigm" entails the notion that two different paradigms are incompatible, which means that the qualification as paradigms does not depend on whether you can use them independently but rather that you _cannot_ use them together. From this perspective, none of the programming paradigms in computer science are really paradigms, because it's certainly possible to mix them altogether…The analogy that I'd propose is that AOP relates to OOP as OOP relates to imperative programming, and if you describe the move from imperative programming to OOP as a paradigm shift, you also have to describe the move from OOP to AOP as a paradigm shift to the same degree.”
By Pascal Costanza (http://aosd.net/pipermail/discuss_aosd.net/2004-July/001004.html)

No:
“Mathematically, aspects form a second-order extension of any programming paradigm: while usual programming paradigms allow reasoning about single functions, messages and so forth by a function/message signature, AOP enables reasoning about entire sets of those entities by using pointcuts with wildcards in their signature. Thus one could view AOP as a powerful, logical extension, rather than as an independent paradigm. Friedrich Steimann, for example, has proposed such a view.”
Wikipedia(http://en.wikipedia.org/wiki/Aspect-oriented_programming)

“..In OOP you have communicating objects with encapsulated state. In FP you have the notion of encapsulated functionality and side-effect-freeness, however no explicit notion of state…that all the paradigms noted above can exists "on its own". You can use FP without OOP…AOP, however as I see it, always (correct me, if I am wrong here) makes use of a kind of "host paradigm", that provides basic expressiveness and then kind of provides a way for second-order reasoning on that "host paradigm"…”
(http://aosd.net/pipermail/discuss_aosd.net/2004-July/001003.html)
“…when moving from IP to OOP,one gains the new concept of encapsulated state together with the notion of messages. This changes the whole universe of reasoning: Instead of reasoning about loops or sequences of commands executed on a machine (IP) one now certainly talks about objects that are communicating via messages.…I see the difference in the fact that when moving from IP to OOP, we change the entities we are reasoning about (objects rather than commands) while with AOP we don't really. Of course AOP claims an aspect as the additional entity of reasoning. But can one really see an aspect as a single entity ,that is without any coupling of the outer world? Objects in OOP do so, also do functions in FP (due to side-effect-freeness), aspects however don't, since in all AOP languages you will always at some point have to conrecretize when and where your aspect synchronizes with the rest of the world…An object in OOP is fully compositional without exposing any of its subunits to the outer world. For functions in FP, the same holds. However, does that also hold for aspects?....”
(http://aosd.net/pipermail/discuss_aosd.net/2004-July/001005.html)

Two citations above By Eric Bodden

Note: FP=Functional Programming, IP=Imperative Programming.