5 ms·

For Architects, Designers and Musicians, flow-based programming is a big deal: Rhino/Grasshopper, Touchdesigner or Ableton Max for Live are all great examples.

For Architects, Designers and Musicians, flow-based programming is a big deal: Rhino/Grasshopper, Touchdesigner or Ableton Max for Live are all great examples. More people should pay attention. Even if you know how to code in a general-purpose language, you won't beat the speed of these tools (for small to medium-sized programs, anyway).

FormFollowsFunc 4y ago
It's growing in popularity in 3D software. Blender, Cinema 4D, Maya and Vectorworks have added nodes in the last few years. Houdini, SoftImage, Generative Components (Bentley) and Grasshopper were early adopters. nTopology and Modo take a stack approach to parametric modelling. It looks less complicated but you quickly run into their limitations. Nodes were popular in compositing software in the 90s - Nuke, Flame, Shake. Code is better when the programme gets bigger but they're less scary for non-programmers to get into.
- rcarmo 4y ago
  Sadly, Godot discontinued their visual scripting recently (which admittedly had a quite low level of abstraction and made some things cumbersome to create).
dagw 4y ago
Even if you know how to code in a general-purpose language, you won't beat the speed of these tools It isn't even an either or proposition in general. In grasshopper for example you can just drop in a Python on VB node anywhere in your flow and run arbitrary code before passing the output along. It is also really easy to write your own nodes in C# letting you wrap any arbitrary complex analysis and data transformation using any .Net library you want, into a simple node you (or anyone) can just drop into their own flow-based program.
klabb3 4y ago
I think the main issue for programmers is VCS, and the associated tooling like diffs. With git + code, you have an easy way to modularize, diff, collaborate and review. In these other professions, you mostly work alone or go through the painful process of working together on the same project. This shouldn't be impossible for flow-based tools, either by making them collab based (like figma) or by having multiple representations (declarative code and visual - possibly by having visual be read-only). Flow based programming already have a straightforward and imo excellent path for modularization (which is the only known way to deal with software complexity). I would love to see flow based programming combined with individual components written in conventional languages. Regular code is clearly superior for many tasks, so flow should be applied between components, and not be too granular. Another challenge is meta-programming. If you need to produce components at runtime, you would naively lose visualization and other benefits. So more research and idioms are needed to really present a coherent system that maintains a similar DX when that extra flexibility is needed. Still, I'm very bullish on medium-term applications of flow based programming within software design. At least for me, it has some absolute killer features; such as understanding existing systems, mapping to my mental model better and spotting bottlenecks and inconsistencies much earlier. I already use pencil-and-paper flow diagrams for software design, but resort to conventional code when implementing.
- bj-rn 4y ago
  Do you know vvvv gamma[1][2]? It's a visual programming environment for the .Net ecosystem. It's documents are saved in a XML format and they have build a visual merge / diff tool that works quite well. The strategies it applies are explained in detail in the readme of the repo[3]. [1]https://visualprogramming.net https://visualprogramming.net [2]https://thegraybook.vvvv.org https://thegraybook.vvvv.org [3]https://github.com/vvvv/MergeVLDocs https://github.com/vvvv/MergeVLDocs
  - bmitc 4y ago
    This highlights the crux of the issue. The problem is not that visual programs are inherently resistant or impossible to being compared and merged. In fact, because a lot of syntactic and semantic information is built into the representation, it often becomes more clear when doing comparisons. The actual problem is that existing tooling, like Git, are myopic in that they assume all programs should have text-based representations. The problem is that the status quo does not scale to visual programs and not the other way around. Thus, visual tooling for comparison is currently bespoke for particular environments, like that of vvvv or LabVIEW, and are usually hampered because of things like Git. There's a reason why game and art studios often use Perforce and Plastic SCM rather than Git, and it's because those studios have comparison needs that do not revolve around pure text.
    - ryukafalz 4y ago
      It feels like this should be solvable though. I’m reminded of this which was posted very recently: https://www.fast.ai/2022/08/25/jupyter-git/ https://www.fast.ai/2022/08/25/jupyter-git/
      - bmitc 4y ago
        Definitely solvable! People just got to work on it like they have text-based diffing tools. I'm trying to, but I am slow. For visual languages, the problem mainly lies in graph and constraint algorithms, something I'm trying to come up to speed on.

FormFollowsFunc 4y ago

It's growing in popularity in 3D software. Blender, Cinema 4D, Maya and Vectorworks have added nodes in the last few years. Houdini, SoftImage, Generative Components (Bentley) and Grasshopper were early adopters. nTopology and Modo take a stack approach to parametric modelling. It looks less complicated but you quickly run into their limitations. Nodes were popular in compositing software in the 90s - Nuke, Flame, Shake. Code is better when the programme gets bigger but they're less scary for non-programmers to get into.

rcarmo 4y ago
Sadly, Godot discontinued their visual scripting recently (which admittedly had a quite low level of abstraction and made some things cumbersome to create).

dagw 4y ago

Even if you know how to code in a general-purpose language, you won't beat the speed of these tools It isn't even an either or proposition in general. In grasshopper for example you can just drop in a Python on VB node anywhere in your flow and run arbitrary code before passing the output along. It is also really easy to write your own nodes in C# letting you wrap any arbitrary complex analysis and data transformation using any .Net library you want, into a simple node you (or anyone) can just drop into their own flow-based program.

klabb3 4y ago

I think the main issue for programmers is VCS, and the associated tooling like diffs. With git + code, you have an easy way to modularize, diff, collaborate and review. In these other professions, you mostly work alone or go through the painful process of working together on the same project. This shouldn't be impossible for flow-based tools, either by making them collab based (like figma) or by having multiple representations (declarative code and visual - possibly by having visual be read-only). Flow based programming already have a straightforward and imo excellent path for modularization (which is the only known way to deal with software complexity). I would love to see flow based programming combined with individual components written in conventional languages. Regular code is clearly superior for many tasks, so flow should be applied between components, and not be too granular. Another challenge is meta-programming. If you need to produce components at runtime, you would naively lose visualization and other benefits. So more research and idioms are needed to really present a coherent system that maintains a similar DX when that extra flexibility is needed. Still, I'm very bullish on medium-term applications of flow based programming within software design. At least for me, it has some absolute killer features; such as understanding existing systems, mapping to my mental model better and spotting bottlenecks and inconsistencies much earlier. I already use pencil-and-paper flow diagrams for software design, but resort to conventional code when implementing.

bj-rn 4y ago
Do you know vvvv gamma[1][2]? It's a visual programming environment for the .Net ecosystem. It's documents are saved in a XML format and they have build a visual merge / diff tool that works quite well. The strategies it applies are explained in detail in the readme of the repo[3]. [1]https://visualprogramming.net https://visualprogramming.net [2]https://thegraybook.vvvv.org https://thegraybook.vvvv.org [3]https://github.com/vvvv/MergeVLDocs https://github.com/vvvv/MergeVLDocs
- bmitc 4y ago
  This highlights the crux of the issue. The problem is not that visual programs are inherently resistant or impossible to being compared and merged. In fact, because a lot of syntactic and semantic information is built into the representation, it often becomes more clear when doing comparisons. The actual problem is that existing tooling, like Git, are myopic in that they assume all programs should have text-based representations. The problem is that the status quo does not scale to visual programs and not the other way around. Thus, visual tooling for comparison is currently bespoke for particular environments, like that of vvvv or LabVIEW, and are usually hampered because of things like Git. There's a reason why game and art studios often use Perforce and Plastic SCM rather than Git, and it's because those studios have comparison needs that do not revolve around pure text.
  - ryukafalz 4y ago
    It feels like this should be solvable though. I’m reminded of this which was posted very recently: https://www.fast.ai/2022/08/25/jupyter-git/ https://www.fast.ai/2022/08/25/jupyter-git/
    - bmitc 4y ago
      Definitely solvable! People just got to work on it like they have text-based diffing tools. I'm trying to, but I am slow. For visual languages, the problem mainly lies in graph and constraint algorithms, something I'm trying to come up to speed on.