3 ms·
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:
by nmehner 3mo ago
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.
- torginus 3mo agoThis 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.
- mohamedkoubaa 3mo ago>it's kind of common knowledge If only.
- mathisfun123 3mo agoyea it's amazing how many goofy ass "senior engineers" are still cargo-culting inheritance.
- hbn 3mo agoIn my experience it's mostly pushed by university professors that haven't worked in the industry since the 90s.
- rf15 3mo agoAnd thus the people who most graduates learned under, and sometimes start founding their own companies with these principles right after.
- hbn 3mo agoI 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.
- rf15 3mo agoIt took me so long to beat the following into my team: Inheritance and instantiation by default is a no-no. Use instances when state would be useful to the process, and use Inheritance when you have a lot of overlap between two processes/concepts and want to simplify/unify the code base. Application of inheritance is a reaction to the current state of the code, not a foundation you start with.
- rapind 3mo agoI 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 is the last thing I'll be using these days. With LLMs I've been moving in the opposite direction with a focus on explicitness and correctness. Typed, compiled, non-null languages with clear, obvious, and well documented conventions.
- yiggnewer 3mo ago[dead]
- jolt42 3mo agoI've feel like AOP is Spring on steroids. Same downside for both IMO.
- ctkhn 3mo agoI think that's a good point, never thought about it like that. I like the abstraction level that Spring Boot brings, but working with a principal engineer who was very into AOP on my previous team was a huge pain. Like you and GP said, AOP absolutely destroys readability. Current team has code split into a million xyz-common libraries, which isn't my preference, but I can still click through to see the source of the library. I will never get what AOP truly improves on
- rapind 3mo agoI think the issue is that a lot of concerns that appear to be "cross-cutting" at first glance, don't hold true to that design... but teams will try to stay the course, possibly due to existing debt, and it goes south pretty quickly from there. That's what I mean when I say there are some patterns that are obvious and proven cross cutting concerns (like logging), but there's really not a ton of them IMO, and if you're going to experiment with new potential concerns, then you must be ready to rip it up when it proves not to be the shape you thought it was.
- kakacik 3mo agoAspects are one of those categories of 'too powerful to be considered', or 'return value not worth the cost of troubles it can bring'. I completely agree with you, saved stuff is normally trivial, nightmare it can bring down the line makes those war stories that are fun to listen to, but certainly not fun to walk through. I simply skip them despite ie Spring offering powerful ways to manage transactions, logging etc. decoupled from places things are actually happening. I can imagine it working well in a disciplined team who consists of senior folks knowing their craft. Certainly I have never been part of a team with only such composition.
- coldtea 3mo ago>return value not worth the cost of troubles it can bring That, funnily, could be the motto of Forth
- Someone 3mo ago> 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 https://en.wikipedia.org/wiki/DTrace#Command_line_examples) and the hard cases possible (examples at https://github.com/opendtrace/toolkit 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.