Folk wisdom on visual programming

The strength of visual programming is not in visualising code, but rather, visualising programs.

At a small scale, textual code can be very concise, expressive, compact, efficient and fast to write. But at a large scale, writing thousands of lines of code in text files in folders makes it very difficult to understand how the pieces of a program connect. To overcome this, we rely on file naming conventions, frameworks or writing documentation to understand how the various parts of text relate to each other.

Programming with nodes and wires is a way of visualising those relationships by creating a map of the program. Similar to maps of the real world, those maps may be complex and not easy to understand. But those maps show that there is complexity. what we can learn from maps of the real world? Well: zoom level matters. When we want to understand the world, we look at countries. When we want to get to the next city, we look at the road level.

In my opinion, visual programming environments are transparent and honest about the underlying complexity of a program. Contrast this with countless folders full of files filled with thousands of lines of code.

Such repositories of code can be very difficult to navigate and get around. Yes, frameworks and conventions can help to understand already learned organisational systems (example from the real world: “I learned to navigate American cities designed on a grid of streets, but I get lost in Europe“).

If we compare textual coding to visual programming, we should not only focus on the expression of low level logic and primitives, but also on the organisational aspect of programming. I think there is still a lot of potential for both textual coding and visual programming tools to create better wayfinding systems.

Maybe not. It wasn’t a well thought out aside and is maybe fraught with bias. Haha.

I don’t mind visual programming, but I don’t enjoy PC gaming at all. There have been times I’ve experienced fatigue in my mouse hand with consecutive heavy days of LabVIEW programming. I think there are definitely ways to improve it though.

Could we connect? I have some background in visual programming languages (grad school), and would love to discuss these ideas with you, esp. the "programming=text" assumption. Thanks!

“Better for data flow than control flow”

Here’s a fun use-case that barely made the post: commercial/install Audio DSP. I say barely because Max/MSP did make the list, but that’s not typically for install work (think stadium, convention center, airport, etc.)

The AV world is full of VPL examples. The audio DSP ones that come to mind are QSC’s Q-Sys Designer, Biamp’s Canvas, Symetrix’s Composer. There are many others, but they’re all built on the premise of an expensive hardware processor with free configuration software. Many of these processor/software pairings are configurators rather than VPLs. However, VPL is universal for more complex Audio DSP because audio schematics are very common, and essential processing algorithms are well defined with universally accepted names like “Compressor,” “Parametric EQ,” and “Mixer,” among many more.

Where it’s been getting interesting in the last 5-10 years is the growth of Audio DSP into more flexible control products. Q-Sys Designer is leading the push with nodes that allow Lua scripting, which now supports Blockly. There’s an awkward transition between the primary audio VPL and the Lua/Blockly VPL though. Lua/Blockly supports the event handling features within a predominantly data flow driven application. They also allow the Audio DSP environment to interface with APIs that aren’t supported by plug-ins or other canned modules in the software. Recently QSC has been selling Dell servers configured to run as central processors, highlighting the Linux backend as opposed to other proprietary real-time DSP OSes.

On some level, these VPLs have catered to keeping it simple for guys in vans with USB cables that need to service equipment on site. However, with more remote service possible, this has decoupled the van travel from the programming, allowing it to scale in complexity. It seems like the software could be licensed for use on just about any server if there was a financial incentive.

It all points to an interesting dynamic between visual and text programming as programming talent crystallizes as an off-site role. E.g., GUI buttons are instantiated through the node-based VPL then copied to a GUI canvas where they can be visually customized. This could easily be replaced by a web programming paradigm but will likely remain because the AV industry has a long legacy of guys in vans with USB cables.