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

Show HN: Octopus – a directed acyclic graph for app development

github.com

Post reply on HN
Print view View original

21–30 of 49 posts

Re: Show HN: Octopus – a directed acyclic graph for app development

#21

Post by bbsimonbb »

hobofan wrote: post #9

Almost every modern framework is implicitly modeled as a DAG? It just rarely used that nomenclature. Heck with Elm a whole language exists for that principle. I'm really not sure what's supposed to be different here. As is evident from the repository you obviously know about React and Vue, so maybe try to contrast it to them, or how it fits in in relation to them? To me it looks like you are building a system-in-a-sy…

As I've just written above, React components form a tree that mirrors the DOM. A graph is a much better fit. Nodes in my DAG ressemble "computed" in Vue, where they watch a value and recalculate when it changes, but... in Vue the watched value needs to exist, ie you're responsible for constructing the graph and ensuring no cycles, and the computed value is only available locally, to be used in the template. In my DAG, you just name the thing you want to watch, octopus checks for cycles. Plus you get the visualization.

The closest thing I'm aware of is Jotai. Atoms in jotai can take dependencies on other atoms, so forming a graph.

Reporting nodes in Octopus are, I believe, completely new. You can create nodes that select their predecessors with a filter function. So the "totalPrice" node takes a dependency on any node with a price property, and recalculates when anything with a price changes.

Re: Show HN: Octopus – a directed acyclic graph for app development

#22

Post by bbsimonbb »

w10-1 wrote: post #19

The DAG framing might miss the key points and attract contention. The "law of Demeter" is a design rule that says to only work with data you directly know about - i.e., friends, but not friends of friends. It make local reasoning tractable and forces any (friendly) use to be surfaced as such, which gives a better way to assess global complexity. (By contrast, the DOM is just, well, global state, whatever the data str…

The graph framing is essential. I use typescript graph libraries for the topological sort and for the visualization. I did much less work than either of those two libraries !

Re: Show HN: Octopus – a directed acyclic graph for app development

#23

Post by zem »

archibaldJ wrote: post #6

I don’t really understand what values such design pattern can bring worth (that will outweigh its own complexities) my experience working with DAGs programmatically (ie not as an abstraction (like in React) but actually handling the edges&nodes of a graph-based abstraction in code) is that it looks nice theoretically but in practice top-down (conceptual) approach like this often tends to over-complicate things would…

state machines are a common example of an explicit graph-based abstraction that people build their code around.

Re: Show HN: Octopus – a directed acyclic graph for app development

#24

Post by bbsimonbb »

archibaldJ wrote: post #6

I don’t really understand what values such design pattern can bring worth (that will outweigh its own complexities) my experience working with DAGs programmatically (ie not as an abstraction (like in React) but actually handling the edges&nodes of a graph-based abstraction in code) is that it looks nice theoretically but in practice top-down (conceptual) approach like this often tends to over-complicate things would…

Have a look at the node code. It's biblically simple. I would say it's much simpler than any comparable solution. You can forget about reducers, thunks, computed, even useState, useContext, useEffect and props are rare. I've stuck with graph terminology: nodes, predecessors etc, but you don't need to grok that stuff to use this. Once you've understood that a node is a value, some methods and a reup() function, that's it.

Re: Show HN: Octopus – a directed acyclic graph for app development

#25

Post by j45 »

bbsimonbb wrote: post #22
w10-1 wrote: post #19

The DAG framing might miss the key points and attract contention. The "law of Demeter" is a design rule that says to only work with data you directly know about - i.e., friends, but not friends of friends. It make local reasoning tractable and forces any (friendly) use to be surfaced as such, which gives a better way to assess global complexity. (By contrast, the DOM is just, well, global state, whatever the data str…

The graph framing is essential. I use typescript graph libraries for the topological sort and for the visualization. I did much less work than either of those two libraries !

This seems a useful way to imagine framing qualities about an entity to see what you know about them, be it a profile, survey, etc, which may come from many different perspectives.

Re: Show HN: Octopus – a directed acyclic graph for app development

#26

Post by bbsimonbb »

catapart wrote: post #10

Like others are saying: I think a lot of modern frameworks already fit this mold, or are so close that people can't quite tell the difference. But for a near 1-1 example, maybe look at XState? Especially given that XState has a visual, graph view which interactively indicates state in real time.

That looks interesting, and totally new to me. Thanks.

Re: Show HN: Octopus – a directed acyclic graph for app development

#27

Post by j45 »

wavemode wrote: post #17

I remember working at a company where we had a backend web framework that was essentially a DAG. You could use it to create API's where the caller simply specifies what they want, and the server figures out, through graph theory, what series of processing steps and API calls to other services should be performed (some of which can have dependencies on the results of other API calls and/or processing steps), and the o…

My guess as to why it was over engineered was to be reusable, or at the start maybe an unknown complexity was foreseen requiring unreasonableness flexibility.

Like many, I early in my career once rewrote a partial implementation of windows workflow foundation to work out of MySQL with db functions. It was .. beautiful. :) And the problem learned to behave and not need it again. Still running years later and reasonably refactorable.

Re: Show HN: Octopus – a directed acyclic graph for app development

#28

Post by bbsimonbb »

grayrest wrote: post #14
bbor wrote: post #12

A) I agree with many of the comments here arguing that this is not necessarily a new technique, and B) you’re gonna go far in this life, I’d bet! I know nothing about you but this whole README just reeks of a bright young thinker who’s not afraid to question existing paradigms and can follow through on their conceptual vision. Plus it helps that you’re a very dramatic and effective writer. I encourage you not to let…

> it’s not an angle of HCI I’ve examined explicitly, at least for very long If you're looking for additional reading then it's arguable that Reacts matches this viewpoint but any web framework from the past few years using signals (re-popularized by Solid) is explicitly this approach. Most frameworks don't opt for graphical node editors and I've never liked the approach but I've seen a number of those as well. More g…

No. Signals work with a weak map of references, not a graph. So in my Pizza example, when pizza changes, totalPrice would recalculate twice: once on a signal from pizza, once on a signal from tip. Explicitly constructing the graph dramatically reduces needless recalculation in bigger systems.

Re: Show HN: Octopus – a directed acyclic graph for app development

#29

Post by pcthrowaway »

bbsimonbb wrote: post #26
catapart wrote: post #10

Like others are saying: I think a lot of modern frameworks already fit this mold, or are so close that people can't quite tell the difference. But for a near 1-1 example, maybe look at XState? Especially given that XState has a visual, graph view which interactively indicates state in real time.

That looks interesting, and totally new to me. Thanks.

Yeah, I was thinking of xstate too. I think you do a better job than xstate does in describing how a DAG model is a better fit for organizing the frontend state than the current more common spaghetti paradigm. And xstate isn't solely for representing the frontend as a DAG, but my understanding is that it can do that too.

So while I think the description of your solution is better than I've seen in xstate's docs, I'd be inclined to go with the xstate's more mature software that gives me the ability to represent front-end state in a DAG, since it has a thriving ecosystem and (I assume) better tooling.

But I might give Octopus a spin anyway to see what the DX is like

Post reply on HN