41–50 of 79 posts
- code readability and maintainability takes a hit. If you don't know things are defined using AOP in files x,y,z you can read the code and miss a whole lot of things.
- AOP implemented at runtime is a mess when you're trying to debug things
So yeah, instead of having aop defined somewhere else to wrap a function call, i tend to prefer doing it explicitly transaction(function())
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.
I think I prefer Springboot AOP, especially with SpEL.
The term “cross cutting concerns” is thrown around a lot when discussing AOP. Took me a while to appreciate just how powerful it is in this context - sprinkle an AOP annotation here or there to avoid massive refactors in a large codebase, or avoid rewriting classes in a way that makes your classes themselves “cross cut concerns.”
> 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!
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.
LLMs really like the most important context to be clustered in the most recent section of their window. Dividing up cross-cutting concerns into their own documents would seem to be pushing in the other direction.
> 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.
> 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.
Earlier 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…
I've feel like AOP is Spring on steroids. Same downside for both IMO.
Earlier quoted context omitted.
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!
That's what all the customers are demanding.