Folk wisdom on visual programming

Speculation: visual programming is a bit more beginner friendly, and more compatible with the brains of people designing stuff in UE. I wish blueprint was around when I was 13, messing around in UT’s version of UE and having no idea what unreal script could do. Visual language can break out all possible components into UI menus, just like everything else in UE. Visual oriented people really click with tools like visual programming.

Personally I think it’s cynical / arbitrary to pin the decision to corporate power struggles. Sometimes people propose new things out of interest or as a side project and then it grows from there.

I sort of disagree with the intro to LabVIEW:

> There are a large number of visual programming tools that are roughly in the paradigm of ‘boxes with some arrows between them’, like the LabVIEW example above. I think the technical term for these is ‘node-based’, so that’s what I’ll call them.

There are NOT a "large number" of visual programming tools that are roughly in the paradigm [...] like LabVIEW. I am sure there are some but, really, how many active ones?

Also, "node-based" is not the main concept. The most essential concept of LabVIEW is known as "data-flow" (https://labviewwiki.org/wiki/Data_flow). Data generated by a node "flows" to the other nodes it is connected to and when any node has data on all it's inputs, it executes and produces data which flows to whatever nodes it's connected to. This happens asynchronously. You get concurrency "out of the box" with LabVIEW. That's extremely powerful and much easier to reason about, IMHO, than the concurrency constructs in virtually any mainstream computer language.

I think there's plenty of room for all kinds of languages (both text and visual) as DSL's. If they're well-designed and intuitive, they're like a hot-knife through butter for a domain expert. The nice thing about a really good DSL is that you use it more like a library, whereas with a general purpose language you would be reaching for a framework. It gives you a lot of creative latitude and it feels right. The problems start when people start using them as golden hammers, or use them for things which they're not good at.

I was never interested in or good at coding, but LabVIEW made sense to me. Now I'm using programming principles I learned in LabVIEW and re-implementing them in C++ and C#. It's been a journey.

I used LabVIEW extensively for a few months, and ended up with crippling wrist fatigue and eyestrain headaches from all of the fine mouse work and menu selections needed to write even small programs. This is an ergonomic problem with all graphical software, but is particularly acute with programming because of the amount of code that gets written.

Another problem is innovation. You can quickly spin up an experimental language and try it out because the infrastructure -- editor and command shell -- already exist. This is one reason why we enjoy such a proliferation of new language ideas. New ideas in graphical software require intensive effort to try out.

On the other hand, there does seem to be something about data flow programming (LabVIEW, Excel) that is attractive to beginners, that can't be overlooked. Excel is probably the number-one programming tool in use right now.

They list half a dozen or so. Most of the node based systems are also flow oriented, aka nodes are functional and stateless which allows them to be mapped across any amount of input.

It's a neat pattern but it's really not as uncommon as you think. The mainstream shader languages work this way, for example.