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

21–30 of 79 posts

Re: The Return of Aspect Oriented Programming

#21

Post by torginus »

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…

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.

Re: The Return of Aspect Oriented Programming

#23

Post by cyberax »

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.

Re: The Return of Aspect Oriented Programming

#24

Post by TuringTest »

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…

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.

Re: The Return of Aspect Oriented Programming

#25

Post by ratelimitsteve »

gavinray wrote: post #20
kstenerud wrote: post #5

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

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?

Re: The Return of Aspect Oriented Programming

#26

Post by ratelimitsteve »

AlpacaJones wrote: post #13
kstenerud wrote: post #5

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

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.

Re: The Return of Aspect Oriented Programming

#28

Post by dragonwriter »

pjmlp wrote: post #22

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.

Re: The Return of Aspect Oriented Programming

#29

Post by agumonkey »

rjbwork wrote: post #10
nh23423fefe wrote: post #8

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.

How was it ? Useful or mild or dreadful?

Re: The Return of Aspect Oriented Programming

#30

Post by mohamedkoubaa »

torginus wrote: post #21
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…

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.

Post reply on HN