Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Return of Aspect Oriented Programming

thomaswc.com

Post reply on HN
Print view View original

31–40 of 79 posts

Re: The Return of Aspect Oriented Programming

#31

Post by rapind »

nmehner wrote: post #2

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…

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 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.

Re: The Return of Aspect Oriented Programming

#32

Post by mathisfun123 »

mohamedkoubaa wrote: post #30
torginus wrote: post #21

Earlier quoted context omitted.

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 thin…

>it's kind of common knowledge If only.

yea it's amazing how many goofy ass "senior engineers" are still cargo-culting inheritance.

Re: The Return of Aspect Oriented Programming

#34

Post by yiggnewer »

rapind wrote: post #31
nmehner wrote: post #2

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…

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…

[dead]

Re: The Return of Aspect Oriented Programming

#35

Post by kakacik »

nmehner wrote: post #2

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…

Aspects 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.

Re: The Return of Aspect Oriented Programming

#38

Post by jolt42 »

rapind wrote: post #31
nmehner wrote: post #2

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…

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.

Re: The Return of Aspect Oriented Programming

#40

Post by jerf »

w10-1 wrote: post #19
jerf wrote: post #16

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…

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 othe…

For what it's worth, the last time a language exploded on to the scene so quickly that people were picking it up commercially at a large scale before there was any sort of code base that LLMs could train on was Java. (Yes, there were no LLMs at the time, but I can back-project that as a measure OK.) And that was a money-infused attempt by Sun to buy their way into dominance on the Internet. It ultimately worked for Java, but not so much for Sun.

Any new language, of any kind, optimized for LLMs or not, is going to intrinsically take multiple LLM training cycles to grow anyhow. Net-net I would still expect AI adoption to accelerate those things and at least make it easier for hobbyiests to play with at some useful scale and get more feedback faster. Of course they'll also face increased competition from the other languages riding the same waves, which is possibly the bigger problem for anyone thinking of doing this.

Post reply on HN