My 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 every so-and-so records in a loop depending on the data size, do a custom roll-back if things fail.
And suddenly this whole separation of concerns breaks down and creates a huge mess.
The simple case saves a few minutes, the complicated case causes weeks of depression. Not a good tradeoff from my experience.
An LLM adding to the confusion by only sometimes getting things right and explaining that the separate documents are always valid, except when they are not, well, sounds like a fun experience.
This is a retread of the 'animal-cat-dog' inheritance stuff we learned in our intro to OOP classes, where some people got together and put forward their own idea of programming as 'the way forward'.
And me, like others have tried structuring our code like this, and failed, assuming the fault lay not with the idea itself but our skill level. Of course, by now it's kind of common knowledge that inheritance isn't a thing that can and should be used to solve every kind of problem.
Same thing with AOP - it might be sometimes nice, but on the whole, elevating this to the language level seems to be counterproductive.
I think there's a core of a good idea here, but as others have pointed out, letting the LLM be your "weaver" is going to be very tricky.
It's possible that what you have here is an idea for what I consider to be eventually very likely, which is a computer languages still built for humans to be able to understand and debug it, but more primarily for LLMs to write it. Write a language designed to be an aspect-oriented language from the beginning. Equip it with the ability to run something like a language server and point it at a system and get all the "aspects" running and you might have something.
But I'm skeptical of bodging this on to an existing language.
One of the reasons I suggest making it a new language is that AOP was hampered by being able to use only what languages already supported. The need for a "weaver" is a smell anyhow. Something where the aspect code is the native representation and the "weaving" simply dissolves into the compilation process would not only make the whole thing more appealing in general, I think it would also allow for some things that even code generation might have found a challenge, like aspects that can maintain guarantees because the whole process is more aspect-aware and not broken by the embedded "payload" code written by a human.
re: dissolving into compilation, I think the machine/human separation has been at work for some time. Modern languages (e.g., rust, swift) are already pioneering tracking aspects like effects, lifetimes, regions, etc. and then using whole-program optimization at compile- and link-time, largely based on intermediate languages like LLM IR/SIL, which are surfaced as user-visible features when they compose well with other user-visible language features. LLM training on these languages makes them suitable for generative AI; I doubt LLM's could pick up some new language, particularly if it weren't analogous to existing ones.
I believe the sweet spot that makes it practical and reliable will be combining LLMs with formal verification, although I doubt current hardware is up to the task (yet).
LLMs basically solve the classic Frame problem that prevented general problem solvers to be able to reason logically about the real world; however on their own they are utterly unpredictable and unreliable.
However if the database of weights is merely used as a heuristic to guide the logical reasoning engine to promising regions of the problem space, and the program itself is written to specification directly by an inference engine, the result would be classic software not affected by hallucinations.
The LLM could even help debugging the specifications by pointing out unclear or contradicting requirements, improving the process without compromising the integrity of the result.
This is, indeed, the next generation of AOP: they've managed to evolve it from "extremely complex and hard to understand runtime behavior" into "completely undefined runtime behavior". UB as a service. True innovation!
> The LAST thing you want is a non-deterministic process monkey patching your code.
I'm not poking fun of you, but the irony here is that code-as-written is mostly a "suggestion" to modern compilers and JIT interpreters and the actual instructions emitted often look nothing like your ver-batim code.
okay but at least those are provably equivalent, unless my understanding is off. isn't that the whole impetus behind the idea of functional programming?
i feel like you've just accidentally stumbled upon primate-patching as an umbrella term that can be anything from monkey-patching to hominid-adjustment via apefoolery. As a coder for 8 years I know I'm personally capable of operating at any of these levels depending on the day and the strength of the local coffee.
Humans might be non-deterministic, but we can reason, we can learn, and we can have incentives to be careful and not just YOLO things, all of which mitigate that risk. None of those is true of LLMs.
The idea of this post - to write separate requirements for each concern and let LLM's integrate them - is much closer to the Leo version of literate programming, which allowed documents to be composed (roughly via scatter/gather operations mediated by sentinels).
But the post entirely lacks the motivation for the AspectJ/AOP join point model: to have principled time/place for concern integration that was statically determined, type-safe, understandable to users -- and suitable for integration.
> I've also always hated the specific mechanism that AOP chose to implement it with – something called the "join point model" which basically amounts to runtime pattern matching on a program's call stack and running some code every time a pattern matches.
AspectJ's join point model is only dynamic where Java as a reference-based language could not support the static analysis. At compile-time, the "static shadow" of the pointcuts was calculated and implemented where staticly determinable; only the dynamic residue is deferred to runtime (e.g., is the caller to this method of type X?).
Many of AspectJ's join points and type extensions - method call or execution, exception throwing, field access - largely have been adopted in many languages (python context managers, swift getter/setters/extensions), and the residue are a bit hard to use.
But nothing really matches the power of pointcuts: to combine these predicates and the type-safe state-management - e.g., "when throwing an exception after a transaction, capture the span id along with the user id into a log message"
AOP was great for the 7% of code that it was intended for, but was largely displaced as too complicated. Now with LLM's it's a decent hypothesis that with proper training LLM's could actually handle the more complicated but ultimately cleaner programming model - cleaner because it avoids the scattering of similar code which makes it hard to change.
The key insight is that dominant concerns establish the basic structure of the application, leaving some important but residual aspects to fit themselves to the structure. That means the dominant structure must be suitable for the AOP integration (i.e., support the right pointcuts and type extensions); solve that and you've solved most integration issues. It's especially helpful for feature architectures, where you offer code in open-source to gain API adoption, paid for by closed-source library integrations with additional features.
> 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 classes provided by someone else just as easily as being done at class definition time.)
Aspect-oriented programming has annoying implementation in languages like Java which don’t natively support the right abstractions and where you are fighting the language to do it.
Its kind of unfortunate that those are also the languages also which do the most to shape people’s understanding of AOP.
Has anyone done AOP outside of Spring Framework? That's my only exposure and it feels very library level. Nothing I would use as a the primary way to structure the code.
After reading this post, I got curious and went back to read the original AOP paper. What the OP argued feels like just top-down design. These days, the term 'SPEC-driven' is trending, but it seems like just another word for top-down. They're probably just rebranding it because top-down has a negative image.
Originally, AOP was about separating cross-cutting concerns by centralizing them in one place. It used weaving to separate infrastructure code, and implicitness was inherent in that approach. But the books I read back then said this led to 'ghost code.' It inevitably introduced unpredictability because the behavior wasn't visible in the code. And from a programmer's perspective, that becomes a problem when things break.
On top of that, while the cross-cutting concerns are centralized, they still end up being tied to the framework's syntax, like Spring AOP's Join Point syntax, so they become dependent on the framework itself.
That's why DDD became popular as another way to address OOP's limitations. DDD keeps the business logic pure and framework-agnostic, and that's where things like POJO emerged. At least that's what I read in books, just different approaches to the same problem.
AOP was first presented at ECOOP in 1997, and DDD is usually associated with Evans' book. Both are ways of handling OOP's complexity, but the article here doesn't seem to talk about problems with cross-cutting concerns, which is the core of AOP at all. And this is something AI doesn't handle well. AI makes the most mistakes with implicit knowledge.
Or maybe I'm wrong because I've been studying programming history through older books and have outdated knowledge. Maybe AOP has evolved since then.
What makes it difficult to talk about specific 'oriented' paradigms in programming is that as history moves on and certain problems get solved, if you bring up an older version, you'll get pushback from people who really know their stuff.
'That's a problem that was solved 5 to 10 years ago.'
'That issue has evolved and been covered in other books.'
So it's hard to talk about any 'oriented' approach because you have to specify which era's version you're referring to. For example, even with OOP, which everyone knows, there's a big difference between Smalltalk, C++, and the modern emphasis on composition over inheritance. Someone might say, 'Modern OOP is centered around composition and value objects — you're behind the times.'
AOP might have also evolved and introduced different solutions since then.
So while the perspective on a given 'oriented' paradigm does shift over time, it's really hard to have a conversation about programming because it all depends on which era the programmer is from and how far their knowledge goes.
That's why lately I've been thinking about problems and the approaches used to solve them, rather than focusing on the 'oriented' labels. I wish someone would write a history book about these paradigms. They'd get a lot of criticism, but for programmers like me, it would be much easier to understand.
Sometimes I think it's about time someone wrote a history book on programming
Is this a joke? Instead of using a formal aspect specification that people (and bots) can get wrong, like any other programming language, trust a bot to do the right thing spontaneously and implement an aspect oriented architecture without tools?
AOP is a big influence for how we are designing hooks, including custom ones, for louie.ai's agent harness. More principled structure to what is already expected.
I'm unclear on AOP in general, esp as proposed here. That's a bigger leap...
And one giant problem with it is the reliance on global variables. An AOP wrapper has to modify something, and it typically does not have enough access to enough context to do it.
So it has to rely on ambient data that has to be saved in a global variable. And this is _bad_. It makes data flow opaque and impossible to follow.
And then there are issues with debugging. Where do you put a breakpoint? What happens if you try to step into an instrumented method?
PS: yes, a global variable can technically be a thread-local variable. It doesn't matter, it's still a non-local ambient state.
My 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 every so-and-so records in a loop depending on the data size, do a custom roll-back if things fail.
And suddenly this whole separation of concerns breaks down and creates a huge mess.
The simple case saves a few minutes, the complicated case causes weeks of depression. Not a good tradeoff from my experience.
An LLM adding to the confusion by only sometimes getting things right and explaining that the separate documents are always valid, except when they are not, well, sounds like a fun experience.
This is a retread of the 'animal-cat-dog' inheritance stuff we learned in our intro to OOP classes, where some people got together and put forward their own idea of programming as 'the way forward'.
And me, like others have tried structuring our code like this, and failed, assuming the fault lay not with the idea itself but our skill level. Of course, by now it's kind of common knowledge that inheritance isn't a thing that can and should be used to solve every kind of problem.
Same thing with AOP - it might be sometimes nice, but on the whole, elevating this to the language level seems to be counterproductive.
I think there's a core of a good idea here, but as others have pointed out, letting the LLM be your "weaver" is going to be very tricky.
It's possible that what you have here is an idea for what I consider to be eventually very likely, which is a computer languages still built for humans to be able to understand and debug it, but more primarily for LLMs to write it. Write a language designed to be an aspect-oriented language from the beginning. Equip it with the ability to run something like a language server and point it at a system and get all the "aspects" running and you might have something.
But I'm skeptical of bodging this on to an existing language.
One of the reasons I suggest making it a new language is that AOP was hampered by being able to use only what languages already supported. The need for a "weaver" is a smell anyhow. Something where the aspect code is the native representation and the "weaving" simply dissolves into the compilation process would not only make the whole thing more appealing in general, I think it would also allow for some things that even code generation might have found a challenge, like aspects that can maintain guarantees because the whole process is more aspect-aware and not broken by the embedded "payload" code written by a human.
re: dissolving into compilation, I think the machine/human separation has been at work for some time. Modern languages (e.g., rust, swift) are already pioneering tracking aspects like effects, lifetimes, regions, etc. and then using whole-program optimization at compile- and link-time, largely based on intermediate languages like LLM IR/SIL, which are surfaced as user-visible features when they compose well with other user-visible language features. LLM training on these languages makes them suitable for generative AI; I doubt LLM's could pick up some new language, particularly if it weren't analogous to existing ones.
I believe the sweet spot that makes it practical and reliable will be combining LLMs with formal verification, although I doubt current hardware is up to the task (yet).
LLMs basically solve the classic Frame problem that prevented general problem solvers to be able to reason logically about the real world; however on their own they are utterly unpredictable and unreliable.
However if the database of weights is merely used as a heuristic to guide the logical reasoning engine to promising regions of the problem space, and the program itself is written to specification directly by an inference engine, the result would be classic software not affected by hallucinations.
The LLM could even help debugging the specifications by pointing out unclear or contradicting requirements, improving the process without compromising the integrity of the result.
> And the "weaver", to use the AOP term, is simply the LLM that generates the program from the documents.
Oh HELL NO.
The LAST thing you want is a non-deterministic process monkey patching your code.
This is, indeed, the next generation of AOP: they've managed to evolve it from "extremely complex and hard to understand runtime behavior" into "completely undefined runtime behavior". UB as a service. True innovation!
okay but at least those are provably equivalent, unless my understanding is off. isn't that the whole impetus behind the idea of functional programming?
At the end of the day aren't we all just non-deterministic process monkeys patching code?
i feel like you've just accidentally stumbled upon primate-patching as an umbrella term that can be anything from monkey-patching to hominid-adjustment via apefoolery. As a coder for 8 years I know I'm personally capable of operating at any of these levels depending on the day and the strength of the local coffee.
Humans might be non-deterministic, but we can reason, we can learn, and we can have incentives to be careful and not just YOLO things, all of which mitigate that risk. None of those is true of LLMs.
That's where I got an immediate migraine.
The idea of this post - to write separate requirements for each concern and let LLM's integrate them - is much closer to the Leo version of literate programming, which allowed documents to be composed (roughly via scatter/gather operations mediated by sentinels).
But the post entirely lacks the motivation for the AspectJ/AOP join point model: to have principled time/place for concern integration that was statically determined, type-safe, understandable to users -- and suitable for integration.
> I've also always hated the specific mechanism that AOP chose to implement it with – something called the "join point model" which basically amounts to runtime pattern matching on a program's call stack and running some code every time a pattern matches.
AspectJ's join point model is only dynamic where Java as a reference-based language could not support the static analysis. At compile-time, the "static shadow" of the pointcuts was calculated and implemented where staticly determinable; only the dynamic residue is deferred to runtime (e.g., is the caller to this method of type X?).
Many of AspectJ's join points and type extensions - method call or execution, exception throwing, field access - largely have been adopted in many languages (python context managers, swift getter/setters/extensions), and the residue are a bit hard to use.
But nothing really matches the power of pointcuts: to combine these predicates and the type-safe state-management - e.g., "when throwing an exception after a transaction, capture the span id along with the user id into a log message"
AOP was great for the 7% of code that it was intended for, but was largely displaced as too complicated. Now with LLM's it's a decent hypothesis that with proper training LLM's could actually handle the more complicated but ultimately cleaner programming model - cleaner because it avoids the scattering of similar code which makes it hard to change.
The key insight is that dominant concerns establish the basic structure of the application, leaving some important but residual aspects to fit themselves to the structure. That means the dominant structure must be suitable for the AOP integration (i.e., support the right pointcuts and type extensions); solve that and you've solved most integration issues. It's especially helpful for feature architectures, where you offer code in open-source to gain API adoption, paid for by closed-source library integrations with additional features.
Effect Systems are the answer to cross-cutting concerns in 2026.
It never went away on Java and .NET worlds.
Also one would say monkey patching on Python and Ruby frameworks is another way to do AOP.
> 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 classes provided by someone else just as easily as being done at class definition time.)
Aspect-oriented programming has annoying implementation in languages like Java which don’t natively support the right abstractions and where you are fighting the language to do it.
Its kind of unfortunate that those are also the languages also which do the most to shape people’s understanding of AOP.
Has anyone done AOP outside of Spring Framework? That's my only exposure and it feels very library level. Nothing I would use as a the primary way to structure the code.
Yeah. I've done w/ Fody, PostSharp, HTTP Handlers, ASP.NET Middleware, Castle DynamicProxy/Interceptors, Temporal Interceptors, and various custom framework interceptors.
After reading this post, I got curious and went back to read the original AOP paper. What the OP argued feels like just top-down design. These days, the term 'SPEC-driven' is trending, but it seems like just another word for top-down. They're probably just rebranding it because top-down has a negative image.
Originally, AOP was about separating cross-cutting concerns by centralizing them in one place. It used weaving to separate infrastructure code, and implicitness was inherent in that approach. But the books I read back then said this led to 'ghost code.' It inevitably introduced unpredictability because the behavior wasn't visible in the code. And from a programmer's perspective, that becomes a problem when things break.
On top of that, while the cross-cutting concerns are centralized, they still end up being tied to the framework's syntax, like Spring AOP's Join Point syntax, so they become dependent on the framework itself.
That's why DDD became popular as another way to address OOP's limitations. DDD keeps the business logic pure and framework-agnostic, and that's where things like POJO emerged. At least that's what I read in books, just different approaches to the same problem.
AOP was first presented at ECOOP in 1997, and DDD is usually associated with Evans' book. Both are ways of handling OOP's complexity, but the article here doesn't seem to talk about problems with cross-cutting concerns, which is the core of AOP at all. And this is something AI doesn't handle well. AI makes the most mistakes with implicit knowledge.
Or maybe I'm wrong because I've been studying programming history through older books and have outdated knowledge. Maybe AOP has evolved since then.
What makes it difficult to talk about specific 'oriented' paradigms in programming is that as history moves on and certain problems get solved, if you bring up an older version, you'll get pushback from people who really know their stuff.
'That's a problem that was solved 5 to 10 years ago.' 'That issue has evolved and been covered in other books.'
So it's hard to talk about any 'oriented' approach because you have to specify which era's version you're referring to. For example, even with OOP, which everyone knows, there's a big difference between Smalltalk, C++, and the modern emphasis on composition over inheritance. Someone might say, 'Modern OOP is centered around composition and value objects — you're behind the times.'
AOP might have also evolved and introduced different solutions since then.
So while the perspective on a given 'oriented' paradigm does shift over time, it's really hard to have a conversation about programming because it all depends on which era the programmer is from and how far their knowledge goes.
That's why lately I've been thinking about problems and the approaches used to solve them, rather than focusing on the 'oriented' labels. I wish someone would write a history book about these paradigms. They'd get a lot of criticism, but for programmers like me, it would be much easier to understand.
Sometimes I think it's about time someone wrote a history book on programming
Is this a joke? Instead of using a formal aspect specification that people (and bots) can get wrong, like any other programming language, trust a bot to do the right thing spontaneously and implement an aspect oriented architecture without tools?
A few weeks ago we were calling this "vibe coding"; I guess someone is trying out some new terminology.
This is not vibe coding though, it's just vibing.
AOP is a big influence for how we are designing hooks, including custom ones, for louie.ai's agent harness. More principled structure to what is already expected.
I'm unclear on AOP in general, esp as proposed here. That's a bigger leap...
Yea, no. AOP was never worth the trouble.
And one giant problem with it is the reliance on global variables. An AOP wrapper has to modify something, and it typically does not have enough access to enough context to do it.
So it has to rely on ambient data that has to be saved in a global variable. And this is _bad_. It makes data flow opaque and impossible to follow.
And then there are issues with debugging. Where do you put a breakpoint? What happens if you try to step into an instrumented method?
PS: yes, a global variable can technically be a thread-local variable. It doesn't matter, it's still a non-local ambient state.