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

61–70 of 79 posts

Re: The Return of Aspect Oriented Programming

#61

Post by coldtea »

kakacik wrote: post #35
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.…

>return value not worth the cost of troubles it can bring

That, funnily, could be the motto of Forth

Re: The Return of Aspect Oriented Programming

#62

Post by jdw64 »

kazinator wrote: post #58
jdw64 wrote: post #15

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…

I went to an AOP talk by Kiczales back in 2005. When he presented join points as being driven by regular expression matches on identifiers (e.g. Get*: for all methods starting with Get) I decided to heckle. Knowing he has a Lisp background I brought up how Lisp teaches us that symbols should be treated as atoms; good programs don't break atoms apart. I think he made some Lisp joke and brushed it aside. But it's actua…

> it should be in those point cuts, or maybe not all of them.

I really enjoy hearing these kinds of war stories from senior programmers. I don't have a LISP background, but having learned Haskell, your point resonates perfectly.

In the Haskell mindset, letting string-matching rules alter the actual semantics of a program is fundamentally wrong. (At least, that's how I'm interpreting your LISP analogy since I don't know the LISP side well.)

I completely agree with you. Changing the meaning of logic based on string patterns is definitely an anti-pattern. (Though, to be brutally honest, when deadlines are incredibly tight, I've definitely caught myself mindlessly doing it too.)

Re: The Return of Aspect Oriented Programming

#63

Post by quatonion »

I did a lot of work on intentional programming at Microsoft back in the 90s on C++, and also intentional software later.

Our approach was quite a bit different to Kiczales at the time. We had "attribute providers" which were essentially compiler plugin DLLs.

These plugins could register themselves at various parse points and add work like enzymes on the AST.

So here we have a compile time attribute that writes all the boilerplate to add windowing support to a class. Adding message maps, hooking up the dispatch, life cycle etc.

[Window] class MyWindow { };

It worked, but as others pointed out, it suffers from combinatorial explosion, and issues with debug ability.

That said, as long as you stick within well defined verticals it was still very useful and saved a lot of typing, and reduced cognitive load.

I have thought quite a lot about modern versions of this using LLMs and I can see why the article notices a parallel to prompts or spec based designs.

At some point I tried to make a version of the system we built almost 30 years ago, but using an LLM as the preprocessor instead of rigid AST hackery.

It works a lot better, and you can approach a more continuous interpolations between intent blocks and generated code. Even the combinatorial problem largely disappears.

I stopped working on it though because I couldn't really see anyone wanting to adopt a new language or some whacked out extensions these days.

Maybe it does have its place though in certain fields. It might be worth having another go at it with fresh hindsight.

Re: The Return of Aspect Oriented Programming

#64

Post by mncharity »

Consider "spec -> plan -> implement" as an unremarkable agentic workflow. TFA suggests that Spec be organized by cross-cutting concerns. This seems a nice thought.

Doubts in comments so far seem around expectations of an AOP-like experience. Mainly that patching aspects/Spec makes happy changes to implementation. I'm not sure TFA intended that use. Nor that current AOP implementations provide the happy. But lets explore.

With a frontier model, a greenfield ends up with, say, some spec and plan docs, and a "woven" implementation. It's reasonable to wonder how well an LLM will then un-and-re-weave code as it makes changes. And how to express join points or equivalent. And how well code review agents will detect/check intended joins continuing to be woven correctly. And whether a baseline of the LLM simply using existing AOP tooling constitutes progress.

Coming from non-frontier models, some of that seems more straightforward. Harnesses use lots of small jobs/tasks, with subagent paperwork and reviews. Historically scarce context, precious context, encouraged tightly optimizing single-task context for each job. Including derived code "views", rather than raw code. And associated LLM-coded tooling around working with not-the-raw-code.

Thus working with name/signature pseudocode outlines. And filtering code/ast. Both get you closer to having unwoven forms, and to deterministic tooling for un/re-weaving. Consider i18n clutter - just to coddle the model, one might strip it (replace it with English), let the model work, and then restore it. Which is equivalent to un/reweaving an i18n aspect. And even read-only views, like function distillations which drop or abstract some specified variables and associated code, make that "check spec against implementation" code review easier. So, even interpreting TFA broadly, it seems at least potentially possible, no?

Big picture, I'd like to get away from traditional "repo as single point in design space, laboriously nudged around", to something which preserves the multiplicity of model/run/prompt ensembles, and allows playing on design space manifolds. "This exact code has been in prod" is useful information, if underutilized, but not so useful as to be worth discarding so many new possibilities.

Re: The Return of Aspect Oriented Programming

#66

Post by fur-tea-laser »

aspect-oriented programming is an apt name for what i imagine will be llm-science 101 in the not-too-distant future... though i found the "joint point model" details superfluous, and the piece as a whole to be cursory... modern aspect-oriented programming will become a much richer & more robust ontological and application tapestry than its legacy predecessor... one of the core fundamentals of aspect-oriented programming in the context of llms is the need to accurately model the entanglement of related aspects... let's look at an over-reduced and isolated example using english expressions as our subject... let's define two aspects of an english expression: brevity and precision... if we amplify one aspect, the other begins to degrade... thus we need to align our models with the nature of english, and entangle the two aspects... entangling aspects changes the nature of optimization itself... we go from maximizing in one direction to pushing to the entanglement's frontier (pareto), and then steering along that frontier for taste... this doesn't mean we don't define aspects in isolation... it just means we need to align our aspects with reality and reflect its nature via entanglement...

Re: The Return of Aspect Oriented Programming

#67

Post by pjmlp »

dragonwriter wrote: post #28
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…

Same outcome, different implementation, instead of compiler plugins or bytecode rewrite, it gets patched via the languages dynamism.

I would say not having language support is a king of way of language designers not approving of its widespread use.

If anything Java and .NET are slowly closing some avenues that make patching possible, like final really means final JEP in Java.

Re: The Return of Aspect Oriented Programming

#68

Post by rf15 »

hbn wrote: post #55
mohamedkoubaa wrote: post #30

Earlier quoted context omitted.

>it's kind of common knowledge If only.

In my experience it's mostly pushed by university professors that haven't worked in the industry since the 90s.

And thus the people who most graduates learned under, and sometimes start founding their own companies with these principles right after.

Re: The Return of Aspect Oriented Programming

#69

Post by rf15 »

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.

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

Post reply on HN