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

41–49 of 49 posts

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

#41

Post by bbsimonbb »

zem wrote: post #23
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.

I looked at and rejected state machines, because I didn't like/understand the need for the formalism of defining every possible state.

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

#42

Post by davidkpiano »

bbsimonbb wrote: post #41
zem wrote: post #23

Earlier quoted context omitted.

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

I looked at and rejected state machines, because I didn't like/understand the need for the formalism of defining every possible state.

You don't need to define every possible state. A state machine can serve as a higher-level structure of some of the states (statuses, modes) of parts of your app, for ease of structuring logic. But you can also create a single-state state machine and represent non-finite data as "external state".

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

#43

Post by bbsimonbb »

pcthrowaway wrote: post #29
bbsimonbb wrote: post #26

Earlier quoted context omitted.

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…

So xstate implements state machines. This is quite a different concept from DAGs, though there may be a DAG underneath. This isn't mentionned anywhere though. The concepts you work with are state machine concepts.

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

#44

Post by vidarh »

bbsimonbb wrote: post #37
vidarh wrote: post #35

Earlier quoted context omitted.

> React components form a tree that mirrors the DOM. A graph is a much better fit. Not all acyclic graphs are trees, but all trees are acyclic graphs. As such this part of your description is confusing. Your last paragraph does a much better job at explaining how it differs.

I put a concrete example in the sample app. "pizza" depends on "size" and "base". So a DAG, as you point out, is less constraining than a tree. When you shoehorn your state and orchestration into react components, not only do you have to fit them into a tree, it's fundamentally the wrong tree.

I'd suggest you emphasize that near the top of your README, maybe with a cleaned-up version of the generated graph and some annotation of the data flow. To put it a bit pointedly, "nobody" will care about the data structure until they see that it means they don't have to manually thread data down through the right branches of a tree. That's your big selling point.

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

#46

Post by bbsimonbb »

machiaweliczny wrote: post #45

How is that better than MobX?

I like and use MobX. I "come from" Vue, and I like mutability (though I concede its dangers). For my needs, the limitation was reactions. In mobx, reactions shouldn't update other observables. In Octopus, chaining is the whole point. Nodes can be stacked to n depth. There is no distinction between state and computed. Computed just generates more observable state.

Then, in Octopus you also get reporting nodes and visualisation, which, once tasted, no return.

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

#47

Post by bbsimonbb »

vidarh wrote: post #44
bbsimonbb wrote: post #37

Earlier quoted context omitted.

I put a concrete example in the sample app. "pizza" depends on "size" and "base". So a DAG, as you point out, is less constraining than a tree. When you shoehorn your state and orchestration into react components, not only do you have to fit them into a tree, it's fundamentally the wrong tree.

I'd suggest you emphasize that near the top of your README, maybe with a cleaned-up version of the generated graph and some annotation of the data flow. To put it a bit pointedly, "nobody" will care about the data structure until they see that it means they don't have to manually thread data down through the right branches of a tree. That's your big selling point.

Good suggestion.

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

#48

Post by pcthrowaway »

bbsimonbb wrote: post #43
pcthrowaway wrote: post #29

Earlier quoted context omitted.

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…

So xstate implements state machines. This is quite a different concept from DAGs, though there may be a DAG underneath. This isn't mentionned anywhere though. The concepts you work with are state machine concepts.

Yes but a state machine is reducible to a directed graph, and a DAG is a specialization of a directed graph, which xstate can be used for

edit: to be clear, I think the additional constraints on the directed graph model introduced by Octopus may be useful by requiring developers to derive state transitions from updates which can only occur upstream, because that state can't flow back in the other direction. Whereas the dependencies can have cycles with xstate.

So I'm positing you can do everything with xstate that you can with octopus (and more). I'm not necessarily arguing that the ability to do the "and more" part with xstate is not a footgun, just that xstate lets you work with state in a similar way while also having a mature ecosystem of tooling around it. Perhaps the constraints introduced by octopus would result in more robust software in practice; I'm definitely interested to try it for myself and find out

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

#49

Post by aleksiy123 »

bbsimonbb wrote: post #38
aleksiy123 wrote: post #36

Earlier quoted context omitted.

Producer graphs? Maybe just me but I find them completely unreadable and painful. I don't really think there anything inherently better about having the framework connect things through inputs and outputs or developer explicitly specifying the connections through function calls. In both cases the executor can decide how to execute the graph.

Are you talking about this? https://patents.google.com/patent/US7865872B2/en

No, unfortunately the framework itself is not public.
Post reply on HN