Visual Programming – Why It’s a Bad Idea

https://www.mendix.com/ Seems to be cleaning up on the concept. I've seen two start-ups now using it and the turn-around times for features were definitely impressive. The problems with such solutions are always long term maintenance, scalability and lock-in.

Our company develops a software for alarm receiving centers. In our software our customers can use a visual code editor http://pfau.de/images/beispiel002.gif to program their own processes for alarm reactions. That is actually our main selling point. They can control the user interaction (what to do, who to call, etc) in reaction to an alarm, access all the data to change process outcomes in response to data or user interaction and automate a lot of processes (filling forms, mailing reports and even automated invoices). They can even call external programs (on other computers) and fill and read databases to interact with other systems. That generally works well as long as people use simple flows and standardise a lot. But as soon as people start to program complex flows you can really see who is a “programmer in disguise“ and who is “just a user thrown in way over his head”.

It's also a long-term maintenance challenge, especially when you have complex models.

Great for prototyping stuff fast, but hard to maintain in production. It was designed for people who aren't programmers to be rapidly productive especially when interfacing with hardware (in a lab environment). However, debugging complex topologies can be a real challenge.

We have Labview models that are being rewritten in conventional programming languages due to aforementioned challenges.

Visual programming languages will only take you so far, but often that is far enough. What the author misses is that we as professional programmers miss the success stories, because we only get called in when the boundaries have been reached.

In my career I’ve often been asked to rewrite Access DBs, InfoPath forms, or SharePoint sites developed by amateurs into something more usable. My early reactions where along the lines of “what insane person tried to do this in Access.” I realized at some point that was the wrong approach in my thinking. These systems are working software delivering value. I now say “wow, congrats on doing so much on your own. Let me help you take this further.”

A preface before you read this- it's just a long joke :)

I wonder if instead of new programming languages or VPLs aren't the problem, but lack of meta data structures (going beyond a class or interface) that tie together data with expected structure and their implicit validations (including relateable data) to code that performs business rules (booking airplane tickets) and code that draws a UI (ticketing screen).

I know about 10-15 years back this was called "4GL" (fourth generation languages) but instead of that taking off, a sludge of just new procedural programming languages took hold (rust go ts etc..). I think VPL tries to fill that same niche space where the goal is to think meta-like, not procedurally about each input box. If the system understands and records data in similar ways, we can eventually get to a place where data is ubiquitously stored in the structure the system defines, not the programmer defined way.

So while right now we may not have the correct primitives for 4GL or VPL, maybe one day and that's why these ideas won't die - because it is likely going to be the way that software is designed in the far (or near?) future. Especially in the wake of AI where we might have a chance to let the system write the UI/business logic.

In other words, instead of thinking of AI as writing code in C/C++/Rust, etc.. AI will be in charge of moving data - at first in human defined chunks (likely spec'd out in VPL or 4GL structures), but eventually for AI to define its own objects of related structures. Eventually getting to the point where us mere humans ask AI to build things that fit human process.

The last step is that humans would no longer define the process, and AI be able to incrementally add processes with the data it has, by defining the most optimal path for humanity whether it be tax rates or human production or smoothing out effects of electricity futures based on incoming solar mass ejection predictions. Eventually in the final stages of humanity, defining the work output each human needs to make during a day. By this point enough people will have opted out and the giant war between the owners of AI and the people will start. Killing off most people, but at the same time many of the oligarchs will have been assassinated by members of the public that were willing to rip out their tracking chips in the left eye.

Enough of the planetary population will be gone and totally untrusting of anyone, but we'll have finally visioned our AI future. Won't it be grand!

Oh sorry off topic again yeah we probably should stay away from Visual Programming.