3 ms·

I can see some advantages of this kind of editor for specific contexts, like if you’re building a shader, this UI forces you to be purely functional without exp

I can see some advantages of this kind of editor for specific contexts, like if you’re building a shader, this UI forces you to be purely functional without explicitly teaching purely functional concepts. But it seems like there’s also a general feeling that this is easier than learning how to code, and I guess my question is… is it? Is this really a better idea than a simple to use API with a DSL (or just a simple language like Go or Lua). Is it just less intimidating to beginners? You still have to learn the concepts and rules of the system, in addition to figuring out cable management. It seems to make documenting your “code” a lot harder. And now with AI assistants, you’re giving up even more by not working with text.

MrLeap 2y ago
I've got 2 decades of professional programming experience under my belt and I still think node graph editors are grand. I regularly use VFXGraph / Shadergraph / Custom nodegraph editors for various gamedev things (e.g. dialog trees, checkpoint graphs, all sorts of things) I'm very defensive of my "repl latency". By that I mean, how much effort/time does it take for me to see the results of my change in action? Every node editor that's found its way into my workflow brings that latency down to real time. They provide much more information so much faster about every change you're making as you're making it. It's like a causality scope. If the widget you're tuning/iterating on benefits from that, they're a joy.
- mistercow 2y ago
  Isn’t that, again, specifically a benefit of being purely functional?
  - MrLeap 2y ago
    To me, the way inputs and outputs are presented in nodegraph editors adds value on top of the benefits functional programming provides. You see the cascade of every change in real time. Change parameters and see every stage's new inputs and outputs as they're transformed. If I added Logger.Log calls to show as much info, my console would be a blur. I wouldn't be able to click on a parameter in my log and change its value and see what the consequences were. You can change values at a breakpoint, but that's a single moment in time. If your code's running at 60hz, breakpoints can feel like trying to solve a where's waldo through an electron microscope. I have not came across any workflow in my IDEs that is as flexible and informative for the situations where nodegraph editors shine. If something comes to mind for you, I'd love to know about it. There's no theoretical reason a text editor couldn't be made to show the same cross section of key information though. TempleOS is kind of like that lol.
baq 2y ago
It’s somewhere between excel and traditional source trees. It isn’t a bad idea, but the tooling isn’t there for general purpose work.
KennedyRichard 2y ago
Hello, creator and maintainer of Nodezator here. > seems like there’s also a general feeling that this is easier than learning how to code, and I guess my question is… is it? IMHO, node-based programming will never and should never replace text-based programming. Neither is in fact a replacement for the other. There are problems that benefit more from one approach and other problems that benefit more from the other one. There are also many problems that benefit from the cooperation between both approaches. There's even problems for which we should use neither, for instance, when a spreadsheet would suffice. Unfortunately, many node editor projects sell/promote their tools as silver bullets that will solve all people's problems and replace all their tooling. I think this attitude prevented a more wide adoption of node editors and harmed their reputation a lot. It also prevented a lot of experimentation with them that could have led to more established and efficient workflows. In the Nodezator project, it is quite the contrary. I only recommend the usage of a node editor, including my own, for specific problems for which node editors are better suited. Which kind of problems are that? Well, since node editors are still not used much as tools for general computing, we only know about specific domains, like media compositing, for instance. There's much to be researched and experimented still. I myself use Nodezator for generating position animation data for a 2D game as well as images that I use in video editing workflows in other apps. This year I've been very busy with development work so I didn't do much research, but since last year I've been experimenting with a lot of different tasks and documented my findings a bit. I'm only scratching the surface though. Experimented with SVG image generation and even parametric generation of 3D models. If you want to know more, you can check this thread on twitter/x: https://x.com/KennedyRichard/status/1747605744361300126 https://x.com/KennedyRichard/status/1747605744361300126 I'd also like to experiment more with workflows for non-programmers in the future (for instance, where someone designs a set of nodes and only teaches a non-programmer how to combine them for various tasks), although I already expect node editors to succeed in various domains regarding this (but as I said before, never replace text-based programming). The reason is that it already is used like that with success in other software. For instance, in Blender 3D, where non-programmers use their node editor for many different 3D-related workflows.
- WillAdams 2y ago
  If you wish to look into DXFs I worked up a technique for making them at: https://github.com/WillAdams/gcodepreview/blob/main/gcpdxf.py https://github.com/WillAdams/gcodepreview/blob/main/gcpdxf.p...
eternityforest 2y ago
One really nice thing about visual programming in general is that it can be done from a phone. Not so much with free nodes, but with more constrained block based interfaces it can be pretty easy. It's really nice for IoT controls, you can edit stuff without taking a laptop to the thing you're editing. It also doesn't require memorizing anything, although LLMs largely solve that in text. But before that one off tasks were annoying in text, every three months having to Google the exact same command syntax or dig up an old script as a reference just for one line of code.

MrLeap 2y ago

I've got 2 decades of professional programming experience under my belt and I still think node graph editors are grand. I regularly use VFXGraph / Shadergraph / Custom nodegraph editors for various gamedev things (e.g. dialog trees, checkpoint graphs, all sorts of things) I'm very defensive of my "repl latency". By that I mean, how much effort/time does it take for me to see the results of my change in action? Every node editor that's found its way into my workflow brings that latency down to real time. They provide much more information so much faster about every change you're making as you're making it. It's like a causality scope. If the widget you're tuning/iterating on benefits from that, they're a joy.

mistercow 2y ago
Isn’t that, again, specifically a benefit of being purely functional?
- MrLeap 2y ago
  To me, the way inputs and outputs are presented in nodegraph editors adds value on top of the benefits functional programming provides. You see the cascade of every change in real time. Change parameters and see every stage's new inputs and outputs as they're transformed. If I added Logger.Log calls to show as much info, my console would be a blur. I wouldn't be able to click on a parameter in my log and change its value and see what the consequences were. You can change values at a breakpoint, but that's a single moment in time. If your code's running at 60hz, breakpoints can feel like trying to solve a where's waldo through an electron microscope. I have not came across any workflow in my IDEs that is as flexible and informative for the situations where nodegraph editors shine. If something comes to mind for you, I'd love to know about it. There's no theoretical reason a text editor couldn't be made to show the same cross section of key information though. TempleOS is kind of like that lol.

baq 2y ago

It’s somewhere between excel and traditional source trees. It isn’t a bad idea, but the tooling isn’t there for general purpose work.

KennedyRichard 2y ago

Hello, creator and maintainer of Nodezator here. > seems like there’s also a general feeling that this is easier than learning how to code, and I guess my question is… is it? IMHO, node-based programming will never and should never replace text-based programming. Neither is in fact a replacement for the other. There are problems that benefit more from one approach and other problems that benefit more from the other one. There are also many problems that benefit from the cooperation between both approaches. There's even problems for which we should use neither, for instance, when a spreadsheet would suffice. Unfortunately, many node editor projects sell/promote their tools as silver bullets that will solve all people's problems and replace all their tooling. I think this attitude prevented a more wide adoption of node editors and harmed their reputation a lot. It also prevented a lot of experimentation with them that could have led to more established and efficient workflows. In the Nodezator project, it is quite the contrary. I only recommend the usage of a node editor, including my own, for specific problems for which node editors are better suited. Which kind of problems are that? Well, since node editors are still not used much as tools for general computing, we only know about specific domains, like media compositing, for instance. There's much to be researched and experimented still. I myself use Nodezator for generating position animation data for a 2D game as well as images that I use in video editing workflows in other apps. This year I've been very busy with development work so I didn't do much research, but since last year I've been experimenting with a lot of different tasks and documented my findings a bit. I'm only scratching the surface though. Experimented with SVG image generation and even parametric generation of 3D models. If you want to know more, you can check this thread on twitter/x: https://x.com/KennedyRichard/status/1747605744361300126 https://x.com/KennedyRichard/status/1747605744361300126 I'd also like to experiment more with workflows for non-programmers in the future (for instance, where someone designs a set of nodes and only teaches a non-programmer how to combine them for various tasks), although I already expect node editors to succeed in various domains regarding this (but as I said before, never replace text-based programming). The reason is that it already is used like that with success in other software. For instance, in Blender 3D, where non-programmers use their node editor for many different 3D-related workflows.

WillAdams 2y ago
If you wish to look into DXFs I worked up a technique for making them at: https://github.com/WillAdams/gcodepreview/blob/main/gcpdxf.py https://github.com/WillAdams/gcodepreview/blob/main/gcpdxf.p...

eternityforest 2y ago

One really nice thing about visual programming in general is that it can be done from a phone. Not so much with free nodes, but with more constrained block based interfaces it can be pretty easy. It's really nice for IoT controls, you can edit stuff without taking a laptop to the thing you're editing. It also doesn't require memorizing anything, although LLMs largely solve that in text. But before that one off tasks were annoying in text, every three months having to Google the exact same command syntax or dig up an old script as a reference just for one line of code.