alt.hn

7/30/2026 at 10:32:41 AM

Gpiozero Flow

https://bennuttall.com/blog/2026/07/gpiozero-flow/

by benn_88

7/30/2026 at 12:00:37 PM

the problem is every visual programming tool eventually reaches the point where you need a 'code node' and then everyone just writes code

by luciana1u

7/30/2026 at 4:01:23 PM

It's a good onramp to building a programmatic intuition, but you're correct that it very quickly gets left behind once the 'magic' is understood. If you do a quick image search for , e.g. Rhino3D Grasshopper, Blender Geometry Nodes, Vectorworks Marionette, Autodesk Dynamo, ComfyUI, you'll quickly see the implementations of the real world procedures users are crafting become unwieldy rather fast.

I can't tell you why an 80 column wall of characters is easier to reason about than a visual graph, but I assume it has something to do with the reason Mitch Hedberg does not like arrows[0]; look, a function.. let's got that way.

[0] https://youtu.be/EI1DBRz3JLk?si=DCLNkbeCGWyw-Ceu

by seemaze

7/30/2026 at 3:39:57 PM

I don't think this is for people that would just write code. Maybe you need that pressure release to get some edge cases, but for the most part, if you're using a visual programming tool, you are trying to avoid the code part for some reason.

So, I don't see that limit as something that's all that bad.

by mbreese

7/30/2026 at 12:59:44 PM

Should we call this luciana1u's law?

If BizTalk has it, why shouldn't my visual programming tool have it?

by whynotmaybe

7/30/2026 at 2:29:01 PM

and then the evolution of the whole tool slows down as the answer for most limitations in native functions becomes "just use the 'code node' and write the function there" :)

by rickdeckard

7/30/2026 at 3:52:51 PM

as someone who writes code, examples 2/3 are non-intuitive

(maybe more context would help)

by m463

7/30/2026 at 1:01:28 PM

[dead]

by bbqbbqbbq

7/30/2026 at 1:43:28 PM

I had a similar thought while building a visual workout programming system for bodybuilding.

One thing I keep running into is that workout programs are essentially state machines progression rules, deloads, conditional branches, different exercise substitutions, autoregulation etc...

That made me wonder whether a visual programming model would make these systems more approachable. I'm still unconvinced, though. Unlike automation workflows where the graph itself reveals the logic, I'm not sure what the right visual abstraction is for training programs without making them even more overwhelming.

So far i've a workout programming language and bunch of sample programs and an app which can help you execute these workout plans, all free ofc: https://symbiote-studio.macrocodex.app/?builtin=gzclp

by faangguyindia

7/30/2026 at 1:51:25 PM

I often enjoy walks in the woods, far away from the systems for supporting tonemaxxers. It is good for my health but even but better for my mind.

by cwmoore

7/30/2026 at 2:00:15 PM

I wonder if apps like Boostcamp implement their plans in a language like this

by joebates

7/30/2026 at 10:59:58 AM

A key feature about data-flow programming that seems too often missed is that it is (or can be) hierarchical.

Define a subgraph of atomic nodes as itself a node with its ports formed from as-yet unconnected ports of its atomic constituents. Compose yet higher subgraphs of subgraphs and atomic nodes. Package all this in some way.

This is directly analogous to syntactic programming where functions aggregate other function calls and all that packaged into a library with an API.

by frumiousirc

7/30/2026 at 11:09:31 AM

This is amazing work. I've used GPIOZero in my RPi projects before. In the future, you can introduce conditional operators in the flow. It can become a complete coding platform.

See JSONLogic UI for similar implementation: https://github.com/GoPlasmatic/datalogic-rs Disclaimer: I am the maintainer of the datalogic-rs project

by codetiger

7/30/2026 at 12:13:04 PM

> It can become a complete coding platform.

... everything evolves until it can read mail^H^H^H becomes Turing complete?

by nottorp

7/30/2026 at 11:12:37 AM

FYI, the general paradigm here is named flow-based programming (FBP):

https://github.com/flux-doctrine/awesome-fbp

by arto

7/30/2026 at 11:33:52 AM

Technically, it seems to have three different paradigms that it exposes:

> Procedural/Event-based/Declarative - These three snippets achieve the same thing in different ways. One repeatedly asks the button if it is pressed; one tells the button to control the LED; and one tells the LED to follow the button's state.

Much of the article seems to focus on the latter "Declarative" way, which they created a Node-RED-like UI for, which is indeed flow-based. But other approaches seemingly can be used too :)

by embedding-shape

7/30/2026 at 11:35:46 AM

Somehow these visual programming tools never seem to get much traction.

Are there any exceptions?

by amelius

7/30/2026 at 11:45:30 AM

Houdini (VFX/3D tool), virtually unchallenged in some of its domains, it's basically visual programming. Very basic what you'd do inside of Houdini when working with it (with screenshots): https://www.sidefx.com/docs/houdini/basics/intro.html

Unreal Engine also have "Blueprints" for game logic that remains fairly popular, maybe not always as the underlying systems, but at least as a control surface for game designers, like a "API" kind of.

If you're curious how out of control and wacky these sort of graphs can get, https://blueprintsfromhell.tumblr.com/ has a bunch of fun examples.

by embedding-shape

7/30/2026 at 1:03:15 PM

Simulink, Labview, Bosch ASCET are all pervasive in control systems engineering, especially in European automotive applications.

by bri3d

7/30/2026 at 5:40:05 PM

I get the feeling that labview was very big in the 00s but has been losing a lot of steam in the last 10 years or so, maybe because of failure to modernize. Labview today feels and looks like a 90s app, contrary to eg. modern Simulink.

FWIW I work in Simulink quite a bit, and "code blocks" (matlab function / matlab system) tend be used quite liberally in my models. Having the visual presentation of data flow is quite nice though for the kinds of things Simulink is used for, mostly physical modeling of electrical or mechanical systems.

by auxym

7/30/2026 at 1:17:12 PM

iirc Starship or Falcon 9 control is Labview.

by chasd00

7/30/2026 at 11:59:39 AM

I don't know, "node-based" interfaces as a concept seem to have made inroads into quite a number of (specialized) fields, e.g. image processing or movie postproduction.

My takeaway is that simply visualizing the AST of a procedural language doesn't do much in reducing the complexity and just makes it harder to read or edit long programs.

In contrast, visualizing data flow graphs can have real utility.

Also, the general question is who is the target audience: It seems pretty obvious to me that programmers who live and breathe code wouldn't be very enthusiastic about visual programming. But that might be different for other professions that don't have that kind of coding expertise.

Also, a lot of programming skill is about keeping the logical abstractions and runtime state in your head that your code will create - not so much reading what is on the screen. That's far easier if you have written the code yourself than if you have to get familiar with existing code.

Thanks to agents, the second case is becoming the dominating situation now, so clever visualizations that help you make sense of existing code and its runtime state might be in demand in the future.

by xg15

7/30/2026 at 11:59:45 AM

I think PLCs are programmed using a mix of text and visuals. Or at least that's what I remember from uni. I'm not entirely sure why that is. I suppose it makes it a lot more obvious to your coworkers and management when you make spaghetti code, which I suppose can create pressure to not make a total mess of things.

by tormeh

7/30/2026 at 1:05:00 PM

Before PLCs were popular, technicians built automation systems using various types of relays. The documentation was done using "ladder diagrams" and the procedure was known as "ladder logic." So the first PLCs tried to take advantage of this knowledge by being programmed the same way since it was already familiar.

Later systems added to this by being programmable with structured text.

The first time I came across a system that was programmed entirely with relays I was completely blown away by what was possible. And also by how heavy, noisy and power-hungry it was for a portable device.

by HeyLaughingBoy

7/30/2026 at 11:40:19 AM

Blender shaders maybe?

by ViscountPenguin

7/30/2026 at 2:06:58 PM

Touchdesigner, VVVV, (Notch?) too. The big benefit here (besides dataflow programming working better for more pipeline-like programs) is that it's always runtime. This is a pretty big selling point for design where quick iteration and tweaking is important

by grufkork

7/30/2026 at 1:40:02 PM

yeah Visual Basic 6, kind of a different thing but clicking on things to select the method etc is very similar

by bliteben

7/30/2026 at 11:37:41 AM

node-RED for PLC programming

by Garlef

7/30/2026 at 11:44:16 AM

Is that really used professionally?

by KeplerBoy

7/30/2026 at 12:14:10 PM

why would you put controller logic into a non-deterministic environment like node-red?

by omani

7/30/2026 at 1:43:29 PM

scratch, thats super popular, but aimed at kids.

by KaiserPro

7/30/2026 at 3:03:01 PM

GNU Radio?

by myself248

7/30/2026 at 12:56:06 PM

Good stuff, keeping it

by hn5nw0vcqg

7/30/2026 at 11:25:19 AM

Hi ben :)

by adds68

7/30/2026 at 11:56:04 AM

I am totally pressed. What now?

by effnorwood