The purpose of most work in programming language abstraction is separation of concerns, it's not like we weren't doing that before someone coined another name for modularization and a new mechanism (AOP) for doing that.
I'm not an AOP practitioner or apologist (Greek definition) but I think that AOP is emphasizing separation-of-concerns that are non-functional and non-core algorithm. Logging, audits, safety, etc. This is different emphasis of thinking from the abstraction/modularization of passing a custom compare() as a function pointer to quicksort().
I believe that speaking of AOP as an isolated concept is reasonable. Whether it reduces down to "hooks" or reduces even further down to assembly language "mov, add, jmp" instructions is not that interesting to me.
We have text editors that are 1-dimensional and linear. The programming code is not in "layers" like layers in Photoshop or AutoCAD drawings, and yet we're trying overlay N-dimensions of concerns throughout the code. We have some crude attempts such as text editors outlining collapse/expand of code regions (code folding). We have syntax coloring of programming language keywords but not of the higher-level concerns. Can the tools make this better?! Maybe. We (the computer scientists and programmers out in the real world) are trying to figure out how to interweave all this in a sane way. A focus on this issue of coding all the N-dimensional cross-cutting concerns will naturally lead to a umbrella concept that's researched in isolation.[1]
I don't believe in AOP as the The Next Big Thing. I also don't believe reducing it to just "hooks" adds to the research about it.
You'll get N different definitions of AOP if you ask N people for them. Separation of concerns was actually coined (aside from dijkstra's original usage) by Peri Tarr for hyperspaces, which was focusing on functional concerns (just around multiple dimensions) and not the non functional concerns of AspectJ. But for functional concerns we have lots of direct options, while for non functional concerns we also have indirect options like garbage collectors. The space is quite big and well travelled.
Regardless of all the fuzziness around terminology, we still try to advance knowledge forward, improve the tooling, possibly improve language syntax, codify and/or formalize best practices.
Just wanted to agree, kudos to better tooling support being an important enabler of AOP (beyond research prototypes, that is). It is not separation of, but cross cutting concerns what is highlighted, i18n, logging, error handling, target platform, etc., all with potential variations. While these commonalities are usually dealt with by throwing them to a library, the interactions of the alternative layers (there will be since they are going to be heavily coupled by the very definition of "cross cutting") is better dealt with, or could potentially hurt less using some version of AOP ideas (EDIT deleted FODA reference).
Right. The main question in our field is whether the term "AOP" is useful or not. The current popular thinking is that it is not very useful, but modularity, as always, is a great concept.
Comments
The purpose of most work in programming language abstraction is separation of concerns, it's not like we weren't doing that before someone coined another name for modularization and a new mechanism (AOP) for doing that.
I'm not an AOP practitioner or apologist (Greek definition) but I think that AOP is emphasizing separation-of-concerns that are non-functional and non-core algorithm. Logging, audits, safety, etc. This is different emphasis of thinking from the abstraction/modularization of passing a custom compare() as a function pointer to quicksort().
I believe that speaking of AOP as an isolated concept is reasonable. Whether it reduces down to "hooks" or reduces even further down to assembly language "mov, add, jmp" instructions is not that interesting to me.
We have text editors that are 1-dimensional and linear. The programming code is not in "layers" like layers in Photoshop or AutoCAD drawings, and yet we're trying overlay N-dimensions of concerns throughout the code. We have some crude attempts such as text editors outlining collapse/expand of code regions (code folding). We have syntax coloring of programming language keywords but not of the higher-level concerns. Can the tools make this better?! Maybe. We (the computer scientists and programmers out in the real world) are trying to figure out how to interweave all this in a sane way. A focus on this issue of coding all the N-dimensional cross-cutting concerns will naturally lead to a umbrella concept that's researched in isolation.[1]
I don't believe in AOP as the The Next Big Thing. I also don't believe reducing it to just "hooks" adds to the research about it.
[1]https://www.google.com/search?q=n-dimensional+concerns+progr...
You'll get N different definitions of AOP if you ask N people for them. Separation of concerns was actually coined (aside from dijkstra's original usage) by Peri Tarr for hyperspaces, which was focusing on functional concerns (just around multiple dimensions) and not the non functional concerns of AspectJ. But for functional concerns we have lots of direct options, while for non functional concerns we also have indirect options like garbage collectors. The space is quite big and well travelled.
This is true for many computer industry concepts:
"object-oriented", "functional programming", "garbage collection", "big data", "programmer", "hacker", "technical debt", etc.
Regardless of all the fuzziness around terminology, we still try to advance knowledge forward, improve the tooling, possibly improve language syntax, codify and/or formalize best practices.
Just wanted to agree, kudos to better tooling support being an important enabler of AOP (beyond research prototypes, that is). It is not separation of, but cross cutting concerns what is highlighted, i18n, logging, error handling, target platform, etc., all with potential variations. While these commonalities are usually dealt with by throwing them to a library, the interactions of the alternative layers (there will be since they are going to be heavily coupled by the very definition of "cross cutting") is better dealt with, or could potentially hurt less using some version of AOP ideas (EDIT deleted FODA reference).
Right. The main question in our field is whether the term "AOP" is useful or not. The current popular thinking is that it is not very useful, but modularity, as always, is a great concept.