But when will we see a return to "aspect and subject oriented programming": https://web.archive.org/web/20080705061956/http://www.alenz....
The Return of Aspect Oriented Programming
71–79 of 79 posts
Re: The Return of Aspect Oriented Programming
#72I actually dont see AOP ever coming back.
Primarily because its authors were modeling smalltalk which ironically didnt even need AOP.
At first it hooks you these cross cutting concerns, but then you realize it handled better as a simple dependency.
AOP as a concept is great, however in practice using real world tools never lived up to the implications.
Its all or nothing, almost if not all code can be written as a "cross cutting concern"
I could write one function for the rest of my life, and simply use AOP to inject a different program.
but WHY would I do that? Something so incongruous with my mission as a software engineer. AOP was pretened smalltalk MVC glue for other languages that didnt have it at the time.
It didnt last long and it wont be back.
Re: The Return of Aspect Oriented Programming
#73I did a lot of work on intentional programming at Microsoft back in the 90s on C++, and also intentional software later. Our approach was quite a bit different to Kiczales at the time. We had "attribute providers" which were essentially compiler plugin DLLs. These plugins could register themselves at various parse points and add work like enzymes on the AST. So here we have a compile time attribute that writes all th…
The Roslyn C# has a very developed system for injecting code at compile time in a very similar manner to what you described.
On the 'experimental' side you have Jonathan Blow's language, Jai, which has integrated codegen (AST macros that look like code) + type inference into the language on a very deep level, and from the podcasts I've listened to with veteran C programmers, was that during the 90s, when the mass adoption of OOP began, but performance still mattered a lot - there were a lot of ideas around OOP that were different from how C++ ended up doing this.
The most famous example I guess being COM, which is a C object model, that solves a bunch of issues that plague C++ to this day, such as reflection and code reusability, among others.
But COM is C and entirely incompatible with C++. And the big issue imo with C++ is that like AOP here, it has elevated a bunch of arbitrary magic behavior to language level, that honestly could've been done very differently, and the C++ implementation often ends up worse (multiple inheritence is a typical example).
A similar battle played out in Linux-land, with GTK creating its GObject system, which was roughly analogous to COM, and Qt opting to hack up C++, not unlike MFC.
Re: The Return of Aspect Oriented Programming
#74My problem with AOP has always been that it makes the simple case trivial and the hard case much harder. Looking at transactions: The 99% solution is trivial: Every service call is a transaction. AOP can save me a few lines for every method and things look much cleaner. But then comes the huge excel upload that is performance critical. Batch more service calls to fetch additional information in the background, commit…
> My problem with AOP has always been that it makes the simple case trivial and the hard case much harder.
Not always. DTrace, for example, is a tool to use AOP with programs and/or the OS kernel that makes the normal cases trivial (https://en.wikipedia.org/wiki/DTrace#Command_line_examples) and the hard cases possible (examples at https://github.com/opendtrace/toolkit)
By carefully limiting what code you can inject, it prevents you from accidentally making hard cases hard to reason about.
Re: The Return of Aspect Oriented Programming
#75Earlier quoted context omitted.
I always thought AOP was super cool, but also that it completely destroys readability and the ability to understand a codebase. I also think it's probably one of the worst concepts to embrace in the age of agentic coding. That would be like a foot missile. There are a limited number of patterns that absolutely do benefit from AOP though. The obvious one is logging. I don't think there's many though. Regardless, AOP i…
> destroys readability and the ability to understand a codebase. Aha! That's exactly the sort of thing that can make code impervious to LLM AI. LLMs have no grasp of any issues that are not visible in syntax, like concurrency. Code that has deadlocks or race conditions (because of other code not seen elsewhere) can look right, but be wrong. In other words, if you write a program using convoluted spaghetti logic full…
This is not true, LLM can write and run code to check for deadlocks or race conditions.
Re: The Return of Aspect Oriented Programming
#76Earlier quoted context omitted.
In my experience it's mostly pushed by university professors that haven't worked in the industry since the 90s.
And thus the people who most graduates learned under, and sometimes start founding their own companies with these principles right after.
I think most university graduates from the past ~15 years are more likely to get taken in by trendy new cargo-cult fads than repeat things taught to them by dinosaurs in their boring university classes.
Re: The Return of Aspect Oriented Programming
#77Earlier quoted context omitted.
> Also one would say monkey patching on Python and Ruby frameworks is another way to do AOP. IIRC—and it may have changed in the several years since I made use of it for this, but I don’t see why it would—the standard way to do AOP in Ruby is leveraging modules-as-mixins which are a core language feature, monkey patching is unnecessary (but since classes in Ruby are open, modules-as-mixins can be used to monkey patch…
Same outcome, different implementation, instead of compiler plugins or bytecode rewrite, it gets patched via the languages dynamism. I would say not having language support is a king of way of language designers not approving of its widespread use. If anything Java and .NET are slowly closing some avenues that make patching possible, like final really means final JEP in Java.
> Same outcome, different implementation, instead of compiler plugins or bytecode rewrite, it gets patched via the languages dynamism.
While the robust dynamism of Ruby (or Python) can allow it to be used in a patching-like way, the only dynamism that is essential to the implementation is the dynamism of runtime polymorphism (common in statically-typed, AOT-compiled OO languages.) The language feature it relies on that C++ and Java don’t have is multiple inheritance that gets resolves to a defined order you can call back up from a concrete method with “super”. There is no reason a static OOP language that supports runtime polymorphism couldn’t support this; it wouldn’t even need to add overhead to compiled classes that don’t make direct super calls from their own methods.
Re: The Return of Aspect Oriented Programming
#78Earlier quoted context omitted.
> destroys readability and the ability to understand a codebase. Aha! That's exactly the sort of thing that can make code impervious to LLM AI. LLMs have no grasp of any issues that are not visible in syntax, like concurrency. Code that has deadlocks or race conditions (because of other code not seen elsewhere) can look right, but be wrong. In other words, if you write a program using convoluted spaghetti logic full…
This is not true, LLM can write and run code to check for deadlocks or race conditions.
Generating code on the topic of deadlocks and race conditions is different from understanding those issues and recognizing them in a wide variety of contexts.
Re: The Return of Aspect Oriented Programming
#79Earlier quoted context omitted.
This is not true, LLM can write and run code to check for deadlocks or race conditions.
Generating code on the topic of deadlocks and race conditions is different from understanding those issues and recognizing them in a wide variety of contexts.
I don't know about understanding but Claude and GPT can "recognize" lots of race conditions/possible deadlocks and then run Go with the race detector to figure out if they really happen (actually not all the time they tend to be overconfident that things are race conditions without testing first!).
I don't really know what to call that, if it's understanding, recognition, but it's clearly helping reduce the number of race condtions.