the problem is every visual programming tool eventually reaches the point where you need a 'code node' and then everyone just writes code
[dead]
Gpiozero Flow
21–30 of 40 posts
Re: Gpiozero Flow
#22Somehow 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.
Re: Gpiozero Flow
#23Somehow these visual programming tools never seem to get much traction. Are there any exceptions?
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.
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.
Re: Gpiozero Flow
#24Re: Gpiozero Flow
#25Somehow these visual programming tools never seem to get much traction. Are there any exceptions?
yeah Visual Basic 6, kind of a different thing but clicking on things to select the method etc is very similar
Re: Gpiozero Flow
#26Re: Gpiozero Flow
#27I 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
Re: Gpiozero Flow
#28Somehow these visual programming tools never seem to get much traction. Are there any exceptions?
scratch, thats super popular, but aimed at kids.
Re: Gpiozero Flow
#29I 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. Unlik…
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.
Re: Gpiozero Flow
#30I 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. Unlik…
I wonder if apps like Boostcamp implement their plans in a language like this