Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Gpiozero Flow

bennuttall.com

Post reply on HN
Print view View original

31–40 of 40 posts

Re: Gpiozero Flow

#31

Post by grufkork »

ViscountPenguin wrote: post #9
amelius wrote: post #7

Somehow these visual programming tools never seem to get much traction. Are there any exceptions?

Blender shaders maybe?

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

Re: Gpiozero Flow

#32

Post by rickdeckard »

luciana1u wrote: post #15

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

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" :)

Re: Gpiozero Flow

#34

Post by mbreese »

luciana1u wrote: post #15

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

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.

Re: Gpiozero Flow

#35

Post by m463 »

luciana1u wrote: post #15

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

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

(maybe more context would help)

Re: Gpiozero Flow

#36

Post by seemaze »

luciana1u wrote: post #15

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

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

Re: Gpiozero Flow

#37

Post by auxym »

bri3d wrote: post #22
amelius wrote: post #7

Somehow these visual programming tools never seem to get much traction. Are there any exceptions?

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

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.

Re: Gpiozero Flow

#38

Post by pseudosavant »

I think this looks like a great idea for the kind of automation people often use GPIOs for. I wonder what the complexity would be to make gpiozero that is compatible with Pi Pico 2 or ESP32 devices? A full Linux OS can be overkill for just controlling some GPIOs. That said, a Pi Zero 2 W is only marginally larger than a Pico 2.

Re: Gpiozero Flow

#39

Post by jcelerier »

seemaze wrote: post #36
luciana1u wrote: post #15

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

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…

> you'll quickly see the implementations of the real world procedures users are crafting become unwieldy rather fast.

maybe but for some users that's the only way they will ever work

Re: Gpiozero Flow

#40

Post by greatony »

i think there are two patterns of programming: control flow, and data flow. this visual programming tool is actually a data flow approach. the good part is, it will be easier to express simple logic. as a tradeoff, it will be awkward to express complex logics
Post reply on HN