A personal history of visual programming environments (2021)

I played around with Quartz Composer when I had my Macintosh. It was neat finding an obscure app deep in the directory structure that you could use to create interesting visuals. It was like my little secret.

I found out you could use it to create screen savers and iMovie effects. It provided a lot of opportunities to tinker.

The one thing that was annoying was that it didn’t offer a lot of control over the final visuals. I was used to Flash giving you frame by frame control, which you did not have in Quartz Composer.

You could create some cool effects, have some interactivity, but it seemed very limited and niche.

Quartz Composer was IMHO one of the coolest things to come out of Apple ~15 years ago in the early days of their Core Animation layer-based rendering framework. When I was first freelancing, I got a gig working on some displays for a large law firm and chose QC. Was able to do things like fancily display customer testimonials and the like, but have a Mac mini running things which had a shared folder that staff could just drop scans of letters in. It was the best of both worlds — amazing programmatic 3D rendering and Mac ease of use for the non-technical people.

I also used it briefly for some small about box effects in my apps, which allowed me to programmatically insert text or imagery based on the user’s registration or other variable data and just plug it into the inlets in the QC animation that was used.

It was basically a totally programmer-exposed motion graphics package. Too good.

I had a brief encounter with Natron, but could not really understand what is going on in it: https://natrongithub.github.io/#features

Oh cool. Some interesting stuff in there thanks for posting.

Do you mean something like Scratch/Snap!?

https://scratch.mit.edu/

https://snap.berkeley.edu/

Iris Explorer. I would probably still be blown away today. The examples that came with it made you think you were driving a supercomputer. It turned out to be rather hard for me to get it to do anything it wasn't already set up to do, but maybe I just missed the point.

IBM's open-sourced OpenDX is similar in scope and appears to run fine on Linux. I haven't used it in anger.

> as long as you restrict it to a particular domain

why?

Visual spaghetti gets real bad real quick, but I find the process of despaghettification to be incredibly gratifying. Well routed graphs make my brain produce happy chemicals.

I haven’t used LabView much myself but did work at a company whose product replaced it with .Net tooling. I got a sense that some common programming idioms become spaghetti. I want to say maybe that there wasn’t a proper loop in LabView?

Take this with two grains of salt. I’m not actually a LabView user and what I know comes from a company replacing it.

LabVIEW is a trap. If you are considering using LabVIEW for making product software, consider systems with better developer ergonomics, such as having your engineers write Python while being water boarded.

The problem is that LabVIEW, the language and IDE, comes with LabVIEW, the integration library for your NI sensors and test equipment and other doohickies. So slapping a program together to gather some data and display it is trivial. But over time, you're going to start to add business logic. And at first it might be bearable: You're code will end up spaghetti periodically, but you'll refactor a little bit and it'll be fine. But your codebase will expand and expand, well beyond the relatively trivial amount of machine interface code and eventually you'll just be developing software, but in LabVIEW.

And that's where LabVIEW's fundamental, inescapable flaws begin. A sample, in no particular order:

1. LabVIEW has a 1:1 correspondence between functions, files, and user interfaces. Every time you see a function (subVI in LabVIEW parlance), and want to know what it does, you'll end up opening 2 windows: the user interface, which for 90+% of vis is never actually shown to the user, or holds any relevant information whatsover, but has to be opened nonetheless), and the code, which may be trivial, or may be complex, but you had no way of knowing before you dove in. Because it takes up a whole window, you get far and beyond less information density than in a textual programming language, which pushes towards inlining a lot of repeated code, but because the actual experience of writing LabVIEW is so miserable, you'll want to implement a lot of stuff as subVIs. It's a lose-lose.

2. LabVIEW's pretty-path for software development is untestable. At some point, you'll say "Ah, I can make user interfaces actually work the way anybody wants them to using Events!". Events are lovely, except you cannot test them. Period. Despite LabVIEW being uniquely situated to allow for a system for inserting mocking code between all those user interfaces you've been making and your code, they refuse to do so, and since LabVIEW is proprietary garbage, you can't even fix this yourself.

3. Pixel art for subVI icons. Here, you get make a terrible choice: When looking at some LabVIEW code, do you want to A) have basically no way to distinguish between different functions without hovering over them (imagine if all your function names were func1() func2() etc, until you selected them), or B) spend an obnoxious amount of time designing little hieroglyphics for future programmers to decipher. The only silver lining is that you're fucked either way.

4. Laying out wires. Have you ever thought to yourself: "You know what I need? More freedom of choice when it comes to expressing myself through data flow"? Well good news! LabVIEW will give you an endless amount of personal freedom when it comes to expressing how data goes from the output of one function to the input of the next. Make sure to lay it out in a nice sane way, otherwise you will progressively go mad. If you get bored, you can always try and use the built in layout engine which, besides being written by an engineer who's idea of a tidying up is pushing all his crap against one wall and marveling at his newfound floor space, will also creatively route your wires all over the place. If you really enjoy formatting your code, LabVIEW might be a good choice.

5. On the topic of wires: You never really appreciate how much context gets encoded in variable names until you don't have any. Compared to other issues it's not THAT big a deal, but you'll miss it.

6. Version control: The diff tool works most but not all of the time, and the merge tool rarely can even load vis and when it can, it's utterly worthless anyway. Resolve all merge conflicts with "theirs" or "ours", or just abandon a branch based workflow altogether. Also, those binary blobs spontaneously change sometimes when opened.

7. No built-in support for Key-Value data structures. This leads to a lot of LabVIEW code falling back to either awkward structs (anonymous or otherwise), or using just a bunch of wires that should just always go everywhere together.

8. The interface is not resizeable. You cannot zoom in, you cannot zoom out, and if you deign to complain about it to NI you'll be told that you can avoid zooming out by making more, smaller vis, which besides making the issues of having too many Vis even worse, also completely fails to address the fact that I want to zoom in so that the tiny 5 pixel wires are a little more legible.

9. On the topic of things NI is aware of but is either too stubborn or dimwitted to fix: LABVIEW BREAKS ALT-TAB. Yes, that's right, the language where you need to regularly juggle having dozens of windows open breaks the most basic form of shortcut navigation. When you alt-tab to a Vi window, it brings every Vi window on top of whatever else you were doing. All several dozen of them. If you had the misfortune of having a VI running while you did that, that VI doesn't appear on the alt-Tab menu list at all. It's still there, buried somewhere, but you're going to have to drag every last window around to dig for it, like a Saint Bernard looking for an avalanche survivor. Again, don't bother complaining to NI about this, since they'll just spout some crap about how they can't fix it because it's just how Windows works. Nevermind the fact that this is the ONLY program I've ever seen that fucks up Alt-Tab like this.

In short, don't use LabVIEW for anything, unless it's some kind of S&M thing between you and your engineers.

Have a look at SideFX Houdini - the whole environment is node based. Building models can take some getting used to, but it's really powerful.

https://www.sidefx.com/products/houdini/