4 ms·

Things like this have been done many times before. Houdini lets you create shaders with node graphs and plenty of other programs have done the same thing. It ha

Things like this have been done many times before. Houdini lets you create shaders with node graphs and plenty of other programs have done the same thing. It has a lot of advantages in that more constrained space. The problems are always the same but I think they aren't clear until someone has already gone down this road. 1. Building expressions out of nodes is much less information dense that just typing them out. What would be a single line of text can end up being a lot of nodes and taking up a lot of screen space. 2. Expression ordering isn't as clear, since it is a graph of dependencies and to figure out what runs when you have to keep tracing dependencies backwards. 3. Branching is tricky for the same reason. A graph of dependencies makes branching much less clear due to order and a scrambled graph of nodes. 4. Loops are more difficult because they also depend on the order of execution and graphs can make that difficult to decipher and difficult to illustrate. 5. State becomes difficult because you need ordering and it depends on external dependencies. A lot of graph problems can be seen in haskell too. You have something that works very well when what you are doing is all a series of transformations, but there are large chunks of programming that don't fit in to this model.

jayd16 3y ago
1) Agreed. I wish more of these systems had code nodes that you can just write expressions in. Sadly the big contenders are tuning for a subset of functionality so expression nodes are often an after thought or a mismatch because the graph system doesn't mix with the compiled language underneath. 2) I think this is both unsolvable but can be mitigated with more tooling. The advantage of the graph systems is exactly because they are non-linear. But code is easier to read and understand linearly. I hope one of these graph systems adds an "unrolled" debug view. It would be nice to read the execution of the past n nodes linearly in a transient visual log. The common "highlighted path" view is good but incomplete. 3) I disagree. We're all just used to doing the scoping passively when reading functions. I think the explicit scoping of the dependency graph is often much more clear. Buuut... the explicit graphs edges make branches tedious as you have duplicated dependencies drawn all through the branch. Perhaps a branch paradigm where the many deps enter the branch node and are then forwarded to the branches or even some kind of implicit scoping would make this better. 4) Yes, loops are a challenge because of the common UX used. The hot path highlighting falls apart when you loop over the same set of nodes. Again, an unrolled view might be useful. There's also the concept of dropping some loop types and focusing on for-each and batch/collection processing. I think passing lists or iterating over them solves some of the loop issues. ...buuuttt, many graph systems don't seamlessly handle both lists and single items. Maybe some Lisp influence would help. Graph systems could use something as simple and easy as mapcar. 5) I don't know...most graph systems I've played with had an easier grasp of state because dependencies were so clear. Still, many graphs I see resort to graph scope and global scope. Would be interesting to see state scoped to some group of nodes.

jayd16 3y ago

1) Agreed. I wish more of these systems had code nodes that you can just write expressions in. Sadly the big contenders are tuning for a subset of functionality so expression nodes are often an after thought or a mismatch because the graph system doesn't mix with the compiled language underneath. 2) I think this is both unsolvable but can be mitigated with more tooling. The advantage of the graph systems is exactly because they are non-linear. But code is easier to read and understand linearly. I hope one of these graph systems adds an "unrolled" debug view. It would be nice to read the execution of the past n nodes linearly in a transient visual log. The common "highlighted path" view is good but incomplete. 3) I disagree. We're all just used to doing the scoping passively when reading functions. I think the explicit scoping of the dependency graph is often much more clear. Buuut... the explicit graphs edges make branches tedious as you have duplicated dependencies drawn all through the branch. Perhaps a branch paradigm where the many deps enter the branch node and are then forwarded to the branches or even some kind of implicit scoping would make this better. 4) Yes, loops are a challenge because of the common UX used. The hot path highlighting falls apart when you loop over the same set of nodes. Again, an unrolled view might be useful. There's also the concept of dropping some loop types and focusing on for-each and batch/collection processing. I think passing lists or iterating over them solves some of the loop issues. ...buuuttt, many graph systems don't seamlessly handle both lists and single items. Maybe some Lisp influence would help. Graph systems could use something as simple and easy as mapcar. 5) I don't know...most graph systems I've played with had an easier grasp of state because dependencies were so clear. Still, many graphs I see resort to graph scope and global scope. Would be interesting to see state scoped to some group of nodes.