i was thinking today about aspect oriented program...
# thinking-together
g
i was thinking today about aspect oriented programming, rails hooks, and synergies in video game strategies (eg: water type attach + your water type attacks now also strike lightning bolts + your lightning bolts have a chance to strike twice). it seems like a lot of power comes from the ability to split out concepts into distinct modules but then combine them causally. my understanding of hooks and AOP is that they were hard to reason about because ordering becomes very sticky (eg: after you save a post by the user, update the user’s post karma rating). it seems like those techniques are actually looking for some kind of constraint solving approach that’s worked directly into the language. does anyone know of papers or projects on this topic?
🥖 1
m
a far relative of this is chemical computing, the problem is that it has even less ordering guaranties

https://www.youtube.com/watch?v=cHoYNStQOEc

😍 1
i
@Garth Goldwater Someone has been playing Hades.
😆 3
💯 1
g
i was waiting for that comment
w
I miss AOP. 😢 Not sure why it didn't catch on more. Weave order isn't in principle more difficult than regular imperative coding, which of course is ordering error prone. Rails hooks in particular create an especially gnarly, overcomplicated call graph.
h
i kind of think that declarative approaches where the system figures out the order to do something in shine when the details of the execution don't matter, just the end result, and i think for the things that the rails callback system gets used for, or for turn based game programming or whatever, the order of execution really does matter
that going more declarative and towards the constraint solving world might actually make it harder to reason about if you want control over the inner bits for say a database transaction boundary or what have you
i think i am saying the manner in which and the order all the things compose is often essential complexity that you can't fully abstract away
g
right, i’m asking about systems that help you explicitly declare exactly the essential ordering complexity, eg “lightning strikes after pushback effects”
w
It's like multiple inheritance: lots of ways to do it, every one wrong. So it's best to have a common-case, easy-to-reason about default together with a flexible, explicit construct when the default isn't right. A potentially better, but more conceptually challenging step, is having a system that's really good at assisting with order. People have certainly looked into this with types and contracts and what have you, but I don't feel like it's been nailed. AOP, for instance, was good for describing long distance ordering constraints as a double check.
👍 1
g
exactly! i’m asking if there are any environments or languages that let you declare loose constraints in an ad hoc manner (eg, this requires this to happen first, this construct never happens without or before this other thing) and then just orders it for you and points out any cycles that can’t be resolved. id guess build systems (although a lot of them seem to err to extremes), and i’d be really interested in any examples with type systems
t
the power of AOP seems coming from "extract cross cutting concerns", by re-organize the code, "shorten the editing distance between related code". But that leaves two questions: 1. what is the value of re-organizing the code, just to allow me move my mouse less? 2. The pointcut / advice seems complex. My recent thought on this is: The value of re-organize the code is to re-design the dependency relationship between packages. If cross cutting concern extracted out into same package, there is little extra benefit. If extracting cross cutting concern allows us to optimize the dependency graph, so that more package can be removed from dependency list, it worth the trouble. It is just a package management game in the end.
In a typical inverted dependency relationship, the bottom package serves us integration between the top packages. It is kind of manifest file or configuration file, declaring how those upper packages integrated with each other. In this sense, introducing new language of pointcut / advice is not necessary. We just need to invert the dependency relationship, and keep the bottom package minimal.
💯 1
c
It's not the same as AOP, but "Data-Oriented" programming with Entity-Component-Systems is something that feels adjacent to these ideas. At my co, we've leveraged the "data" focused part of an ECS to make it trivial to cut through "call-graphs" and instead just look at the underlying shared state of our application. See the following demo I've just recorded: https://www.loom.com/share/b4997d40f9814144940008c51584b926 cc @Garth Goldwater
❤️ 1
g
yeah! i’m talking about exactly the part where you’re working out whether tree indexing or scope determination comes first—that’s the part i was curious about whether there were any examples of languages with those tools built in