> But why do people keep coming back to visual programming? Because real programming languages are free. That's it. That's the main reason. Sure, there are ho

> But why do people keep coming back to visual programming? Because real programming languages are free. That's it. That's the main reason. Sure, there are hobby projects, yes, but almost every visual "programming language" in use in the industry, is a proprietary product, being licensed or sold. It's a way to make money, and a pretty smart one to be honest: Once people invest time, resources, training, and build actual stuff in my proprietary system, they either invest a lot more money to get rid of it, or keep using it. And inertia in businesses being what it is, they usually chose the latter. What better vendor lock-in than a programming language? --- IMHO, no, we don't need "visual programming". I have worked with several such systems in professional settings. There is one thing they all have in common: They suck. No exceptions. It doesn't matter what level they abstract at. They are all sold on the simplest of use cases, and to be fair: They can manage them very well. And some even look pretty and are a pleasure to work with. At the start, that is. Then the honeymoon is over, and you hit the first snag. The first thing the devs of it didn't anticipate, or anticipated but implemented badly. And you build around that. And then the next thing happens. And the next. And the next. And very soon, you keep running for the escape-hatch constantly, like calling into library code, or making HTTP requests to some server to do things that would have been a breeze in a real programming language. Congratulations, we are right back to "non-visual-programming", only now our real code is tangled up in this mess, having to waste precious clock cycles pandering to the ideosyncracies of a less capable system, for no better reason that to not get rid of said system. And god help you if you have more than one of these things and they have to talk to each other. Now you can write glue-code between two pseudo-programming systems! FUN! And, of course, these things are usually not accessible to any established tooling: There either is no version control at all or some vendors pet project idea of what a cool (read: bad) git alternative should look like. There usually is no way to unit- or integration-test anything. The only "IDE" that can deal with them, is the one the vendor provides. Also, `grep`, what's that? Never heard of it. To be fair, there are some legitimate use cases, for example a limited flow-engine within a larger system that never has to leave that systems confines. But quite often, even these systems would be easier to setup and administer, if the devs had just put in a LUA interpreter and called it a day. --- So, coming back to the question "But why do people keep coming back to visual programming?" allow me to ask an alternative question: Why do people stick with textual programming, despite decades spent on trying to make visual programming happen?