Where should visual programming go?

I've wanted the ability to embed diagrams in code for sooooo long. How is this basic and obviously useful feature still not possible??

I think this idea has promise but I wonder how it would work when many of the visualizations I create to help explain logic wouldn't fit neatly into a DSL/schema. For example, I might use red in some places to refer to data from a particular client, or underlines to indicate constants, or arrows to indicate things that are related from a business perspective but not data or logic flow. I guess this could be standardized, but that almost defeats the purpose of having the computer do the heavy lifting.

In other words, not only does understanding these diagrams assume a ton of knowledge in the problem domain, but the crude tools at hand for creating them (lines, words, symbols, shapes, colors) can be repurposed in so many ways by different people and different projects that I don't see how generic motion detection will be able to detect high level changes. Sure, detecting changed nodes and descriptions might be easy, and possibly useful, but I think there will never be a substitute for human comments like "removed XYZ because the boss said so" or "renamed foo to bar because of IRS regulation so-and-so."

Non-programmer here. I’ve long desired to program Arduino microcontrollers but haven’t had the ability and/or the patience to learn programming. I’m a very visual person and get confused if I have to keep more than a few lines of code in my head. Even if I understand how I want a signal to be processed into an action, when the flow chart in my head needs to be translated into text I get overwhelmed.

A solution arrived for me in the form of a number of visual arduino IDEs. Flprog, Outseal, and Open PLC. They all allow programming in ladder logic, and Flprog and Open PLC allows for function block programming. Ladder logic is useful for many tasks involving discrete I/O (Ex. A button latches a contact which turns on a relay which turns off a light and turns on a motor.) Function block programming has enabled me to perform more complicated functions like creating an HMI using a menu system displayed on an LCD connected via I2C. These are tasks that I wouldn’t have a chance of accomplishing without the complex arduino code being contained in graphical functions blocks which I can wire together and configure with a gui.

Prior to compilation, Flprog displays the raw arduino code in the arduino IDE, which gives me a chance to exam the actual code produced by my function block program. I find it to be very educational.

As a non-programmer, I have no idea if this embedded programming use case can be generalized to more complex programming tasks, but for my limited use case it’s been transformational.

It's interesting to see how different programming languages approach building software.

Languages like Lisp are all about planning out the whole program structure (the "Abstract Syntax Tree") upfront, kind of like a blueprint. But modern tools and visual programming often take a more piece-by-piece approach. You build smaller parts first and then connect them together, gradually building up the whole thing.

This bottom-up method feels more natural to how we solve problems in real life. Visual tools make it even easier because you can just drag and drop components instead of worrying about complex code structures.

I wonder if this kind of visual, incremental approach could make programming more accessible to everyone. It might help bridge the gap between our everyday thinking and the formal world of code.

The problem with Hypercard is that it used an extremely restricted subset of English constructions. Once you got used to the limitations, it was fine, but could be very frustrating for users learning what sorts of phrasing Hypercard expected.

Allowing too large a subset of English ends up allowing more ambiguous statements and more user surprise. Also, more complex grammar increases the chances of mistakes in implementation.

My current experience with LLM hallucination makes it clear that at present, we can't just throw an LLM at the parsing and semantic analysis side of programming language implementation.