aspect-orientedparadigmsrole
I know there are many papers describing these three paradigms but I'm looking for a schematic explanation.
There are a few very good descriptions of aspect-oriented programming on here so I'm asking this question in the hope to get the kind of high-quality answer people at Stack Overflow are used to delivering.
Is he trying to write a "straight to TDWTF" AOP framework? I seriously still haven't got a clue what his point was. As soon as you say "All methods must take exactly one parameter" then you've failed haven't you? At that stage you say, OK this imposes some seriously artificial constraints on my ability to write software, let's drop this now before, three months down the line we have a complete nightmare codebase to work with.
And you know what? You can write a simple attribute driven IL based logging framework quite easily with Mono.Cecil. (testing it is slightly more complicated, but...)
Oh and IMO, if you aren't using attributes, it isn't AOP. The whole point of doing the method entry/exit logging code at the post processor stage is so that it doesn't mess with your code files ans so you don't need to think about it as you refactor your code; that is its power.
All Greg has demonstrated there is the keep it stupid stupid paradigm.
For the previous take, see Revision 1 of this answer. However, the comments and edits to the question further clarify what the question is seeking and allow me to be more clear.
Yes, evidence based software engineering (EBSE) is a thing. There appears to be a few efforts toward EBSE databases, such as this one at Durham University and SEED, which was started by a professor at Cal Poly. All of these efforts, as well as ones discussed in a number of papers that can be found through the IEEE Xplore server or the ACM Digital Library (subscription or purchase required for many papers in both), are based on evidence-based medicine. They provide literature reviews of published empirical (observation and experiment) data. In fact, including "literature review" in a search string on any publication search yields information on most topics - over 14000 hits on the ACM and over 1000 on the IEEE database (when limited to only computing topics).
Looking at the general types of topics discussed in these EBSE databases and literature reviews, I see a common thread - they tend to be technology-independent. The emphasis appears to be mostly centered around process and methodology rather than the specific tools used to conduct software engineering.
So, this concept exists in software engineering. Academia is aware of the evidence-based concept and can successfully apply it to software engineering.
Specifically, the question addresses applying EBSE techniques to the selection of a paradigm seems difficult, due to the sheer number of variables involved, forcing assumptions to be made as well as reducing the ability to repeat the experiment or observation. It's said right in the question - "which paradigm comes out as "the right answer" can depend on what metrics a particular study pays attention to, on what conditions the study holds constant or varies, and doubtless on other factors too". Although that doesn't mean that studying which paradigm is "best" in a given situation, it makes any kind of literature review of these documents incredibly difficult to complete and still extract information across them.
There definitely isn't a "turn the crank" solution to choosing a paradigm.
Given a programming paradigm, you can find studies in the various academic and industry databases about how that paradigm influences various aspects of software development - quality, defects, efficiency, and so on - under various specific conditions, ranging from the knowledge and experience of the team to the problem domain. Any rigorous paper should clearly identify the conditions under which the data was gathered and the assumptions. The problem becomes trying to isolate the factors that make it good in each of those conditions.
Academically, there are some statements that are easy to research. For example, the statement that the functional paradigm is well suited to applications that require concurrency stems from the Church-Rosser theorem. Because of this, it's likely that a software system written in a functional language will have fewer defects related to concurrency than the same system written in a procedural or object-oriented language.
However, from a practical standpoint, a software team can't always use "the best" tool or technique for the job just because research indicates it. Although we strive for producing the highest quality software systems, we do operate within constraints. Often, I see these constraints minimized (or even removed from the equation) when discussing the effectiveness of any methodology.
As a practitioner, when I'm involved in choosing technologies to use, I try to identify the best possible tools. But then I constrain myself to what is known and well-understood by the team that I have. Going back to my previous example, if I have a team well-versed in building concurrent applications in C++ and no experience in Haskell, it doesn't make sense to propose building the system in Haskell as I likely won't be able to make schedule and budget constraints, and my quality will likely suffer due to a lack of experience in the toolchain.
To recap, evidence-based software engineering is generally a good thing that exists and literature reviews do exist and are readily available. However, there are aspects of software engineering where applying evidence-based approaches offer little value. The selection of a programming paradigm to a large scale development effort is one of these.
If you want to find out about how object-orientation addresses reusability or defects in functional programming - you'll easily find publications on those. However, I didn't find (nor would I put any amount of trust in) a publication that was able to effectively address paradigm selection across the broad range of real-world software engineering projects.
Best Answer
One can answer this by writing a book on this. However, here is a basic comparison
1. Subject oriented Programming
Subject-Oriented Programming is radical departure from the Object oriented as follows. In OO, objects are defined in terms of intrinsic (i.e. based on a model that independently describes it). and based on this its attributes (properties) and methods (behavior) are derived. The application makes only the use of these properties and behavior. Contrary to this, in subject oriented programming, no object exists (and modeled) in such an isolation. In the process, but behaviors of the objects is been provided by the various other "subjects” of the objects which are beyond the scope and control of the author of the original object. Think of it as a way of extending various "independently definable behaviors" on the object. I think this would be way beyond defining templates of inheritance compared to what is being discussed here.
The undisputed origin of terms (and concept) comes from the paper "Subject Oriented Programming: A Critique of Pure Objects, William Harrison and Harold Ossher". Here is another good paper. Though personally i believe this is a theoretical framework. I don't know if there are any languages/implementation
See this, this and this for more info.
2. Aspect Oriented Programming
Aspect oriented programming has originated from the concept of "Separation of oncerns". Basically it extends the either procedural or object oriented programming for concerns which are cross-cutting. Over simplifying one can say that software has functional requirements and non-functional ones. These cross cutting requirements includes examples like logging, exception handling, thread synchronization, memory management, optimization and so on. These cross cutting ASPECTS should be expressed and implemented separately and independently to any other functional parts.
A comprehensive work in this area is from IBM; basically each such concerns or aspects can be independent from each other forming multidimensional "concern space". , (read this).
Some of the good practical implementations of Aspect Oriented are AspectJ and AspectC++ and many more. See this.
3. Role Oriented Programing
As we evolve towards agents, many a times it is necessary to define "roles" and objectives where as exact activities that agent ends-up performing depends on the environment it is in. This is analogous to human conceptual understanding.
The primary objective is to decouple objective of task from it's co-operation capability by defining explicit construct called cooperation processes. A role is modeled as a set of the capabilities and an expected behavior. however, these approaches also allow modeling of the execution environment and how agent/object can perceive the environment as well. See this.
There are various frameworks proposed in the research for role based modeling and implementations. A few of them are ROPE, BRAIN, ALAADIN and more.