Hacker News Reader

Comment by ramboldio | Hacker News Reader

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).

View on HN

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.

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

[2]https://thegraybook.vvvv.org

[3]https://github.com/vvvv/MergeVLDocs

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.

Is the ability to show a non-text-based diff that related to how a source control system works under the hood though? Sure, a text-based diff tool may use some of the same underlying algorithms to determine what the differing lines are, but I wouldn't assume they have to, and usually have options to do things line ignore case/whitespace/line endings/ formatting or show mid-line (even per character) differences that go beyond how git itself calculates diffs. A top level diff-tool that can proxy out to file-format specific tools would seem to fit well enough into the git toolchain. It's having them integrated into something like bitbucket or github for PR reviews that would be truly powerful.

That's a good point. The issue may simply be one primarily of framing in that text-based diffing and merging tools were not natural, so to speak, but had to be built. And even now, they're not great. I'm constantly irritated by text-based diffing tools because they barely understand anything beyond lines of text. I'm interested to see more semantic diff and merge tools built out.

Regarding source-code control, I think it's a problem mainly of Git and not tools like Perforce or Plastic SCM which handle binary files that change over time better. It's also an issue for things like GitHub, which as far as I know, does not provide any hooks for custom diffs to be viewed in the browser.

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/

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.

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.

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.

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

Reply on news.ycombinator.com