Is there a reason that visual programming languages haven’t taken off for professional programming?
I know of several for specific fields (Dark for backends, TouchDesigner for live graphics/multimedia), but none that are more generalised, open, or in wide use.
It feels like an underdeveloped area that’s ripe for exploration and experimentation.
As someone currently employed to port an absolutely gargantuan (~10,000 vi) LabVIEW project to C#, there are very good reasons to not use visual programming languages.
1. Writing it is a pain. This is a minor gripe, comparably, but if you already know what you want it is very, very hard to beat just typing out a word. Dragging and dropping through menus makes every little action take too long for comfort. You also miss out on the syntactic sugar that makes coding so much more bearable: little, everyday things, like indexing into an array, or incrementing a value, end up taking just as long as putting in any other function.
2. The information density is atrociously low. Intuitively, it seems like the opposite should be true, after all, in a real programming language you're missing out on pictures and icons and a whole dimension of space. But it turns out that the whole "function reads top-to-bottom" thing packs a lot of flow information.
3. Flow-based value passing robs you of variable naming. In a language like LabVIEW, you very rarely use typed out variable names. Most are replaced by unnamed wires. This subtle feature strips the program of a lot of contextual information, making it hard to read.
4. Linting. If you thought making consistent, presentable code is hard in 1D space, in 2D it's basically intractable. The amount of time I spend futzing with wire pathing is infuriating.
If there is any chance that a project will require software developers some day (if you're starting a business, or inventing something novel, it will) just bite the bullet and use a real programming language. Visual programming just attempts to make the easiest part of programming easier, and makes everything else more painful in the process.
I used LabVIEW quite extensively in a past job, and eventually switched to Visual Basic. The stuff I was doing didn't need the performance of LV.
I found graphical programming to be physically debilitating due to eyestrain and wrist fatigue. Granted, this affects each person differently, and I also don't use CAD for the same reason. I can type text with my eyes closed, or while I shift my visual focus away from the screen.
I think a reason why LV programs always seem so unreadable is that the sheer physical effort to clean them up gets the best of the people doing the programming.
A general issue with graphical programming is that you're responsible for the developer interface, and really sweating the details to make it tolerably ergonomic is phenomenally costly in time and effort -- think of how many programmers are employed by Apple or Microsoft.
In contrast, when experimenting with a new or improved text based language, you can piggyback off of existing IDE's or even basic text editors, and get a running head start on adoption by a user community. And the economics are such that languages and IDEs can be supported as open source projects.
There are text based dataflow programming langauges, and I think if LV adopted one of them as an option, folks would stop using the graphical environment after getting over the initial hump of learning to program.
I teach Scratch to kids professionally. I love it as a learning tool, but when I need to actually write Scratch code myself for whatever reason, I find the experience pretty aggravating. Finding the block I need from the big list and dragging it into place takes a lot more time than just typing the command.
Scratch programs also become messy quickly as the complexity increases. Normal code is more compact and easier to actually follow.
I work with a similar platform called NetsBlox which is based on Snap! (sort of Scratch + Scheme) and there's some text-based search/input functionality, to the point where you can write a decent amount of it without your mouse at all. Might be worth looking into, Snap! has a lot of more advanced CS concepts Scratch doesn't AFAIK without making the skill floor noticably higher. It also focuses on creating custom blocks, which makes organization a lot easier.
We tried it the other way. I worked for a decade at Logo Computer Systems, where the principal designer of Scratch used to work. Eventually schools tired of teaching kids text-based coding.
Normal code that's compact and easy to follow is usually that way because it was written by somebody with a lot of experience. I've seen plenty of shit-piles called "code".
There are better and worse programs in every language, including Scratch. However, Scratch blocks physically take up more pixels on screen, so you can't see as much information at once.
Also, in most languages, you don't have to worry about the two-dimensional layout of your code.
Probably it's just a hard problem. Max for Live is a bit more general purpose than TD but still has its limitations I'd imagine.
Enso lang is the best attempt I've seen for this: https://enso.org/
Do you know vvvv gamma?
It's a visual programming environment for .Net. Its language (called VL) combines dataflow programming with features known from object-oriented and functional programming.
It's a great question. TouchDesigner and similar programs have a limited number of data types even though touch designer does a great job at being a little more general than other programs. Also TouchDesigner and Houdini both have shader languages that allow someone to make nodes that do general purpose array transformations which ups their utility a lot.
One big aspect is handling state. Connecting nodes without side effects is great when each frame is a cycle and all you have to do is transform data into a final result. When actual state is involved it becomes hacky or impossible to do in with only transformations. Other similar hurdles are branching and IO.
The other is having general purpose programming underneath. Shader languages enable a lot, but using a real programming language like C++ somewhere not only opens the door to whatever you need, but allows you to integrate all the libraries already made as well as call out to OS IO APIs etc.
It is amazing though how nice it is to work with an integrated and fluid environment where iterations are updated in real time and errors are narrowed down for you, not to mention profiling broken down by node.
It has seen a lot usage embedded in different tools but just isn’t a good fit for a general purpose language. It actually becomes much more difficult to manage as programs get larger. I’ve tried many of these tools over the past two decades and some are fine for what they are but none left me with hope or interest in seeing it replace the dominant paradigm in general.
I sometimes wonder if they could be useful for an OS shell, striking a balance between the extensibility of a text-based shell and the discoverability of GUIs. I mean, combined with search/autocompletion, they're really just a slightly more rigid and structured version of text snippets.
Speed and scalability. Both problems are solvable, and I haven't seen anybody putting the investment to solve it in a grand scale on a popular, open source visual programming language.
For speed: it's really hard to beat the speed of data entry via keyboard. A well-designed set of keyboard accelerators would cover a lot of ground on making visual programming languages comparable to keyboard programming speed, but I haven't seen anybody pull it off yet.
For scalability, and in the sense I mean scalability of project complexity from a toy desktop project to a distributed system deployment or a low level embedded system: the vast bulk of tools that are available for supporting large projects are built around text and the fact that it's relatively easy to translate a tool working in one text-based language to another text-based language. Git doesn't care what language you're using; it's all text. Diffing tools don't care what language you're using; they diff lines of text. As tools like Copilot grow, they will start by disproportionately giving a power boost to text-based languages because they are built to work with text-based languages.
Anything that's going to work with a visual programming language in a way that is as robust as these tools do needs to treat the language as an abstract syntax tree, not a collection of lines separated by line breaks. And the tools to do that are going to have to be written almost from scratch; it's simply an underdeveloped ecosystem because there's so much fungibility between different text-based languages in terms of allowing tools that work on one to work on another.
A further issue is that if one uses modules/functions, one ends up w/ just a textual description of the algorithm trapped w/in a series of connected/nested blocks.
I prefer to work this way, but I've crashed-burned hard on installation/usage w/ more tools than I can recall off the top of my head (pyFlow, Ryven, GraphSCAD, clikscad, &c.) --- currently I'm just using BlockSCAD and pasting the code into OpenSCAD/RapCAD. I hope that Nodezator (node programming tool done w/ pygame) will work out, but I'm waiting for it to have branches and loops.
Darklang is getting there. Functionality is limited, but feels great to use. Speaking as someone with 15 years experience. Can't wait for it to mature.
> Is there a reason that visual programming languages haven’t taken off for professional programming?
Programming languages in common use are way too general to really benefit from a structural editing workflow as seen in Scratch. Meanwhile, other VPL's cannot naturally express the kinds of abstractions that turn out to be critical when programming "in the large", as often happens in professional settings.
I know of several for specific fields (Dark for backends, TouchDesigner for live graphics/multimedia), but none that are more generalised, open, or in wide use.
It feels like an underdeveloped area that’s ripe for exploration and experimentation.