SCADE provides textual and graphical views that are synchronized and it's widely used in industrial critical embedded software such as airplane in airbus.
Disclaimer: Huge personal hunch, might be down-voted to hell for writing this...
I think that languages like this don't go mainstream because people like/want to write code, and anything that does not help to actually write code is seen as an hindrance. The main feedback I've heard about this kind of tool is "it's clunky, it's a pain to write code with". Guess what ? It's a good thing IMO.
For this to go mainstream, the whole software industry would have to go through a major revolution by shifting its focus from "writing code" to "deliver a working product". We should acknowledge that "writing code" is one tool among others, and may be not even the primary one (I personally think that specification engineering is the most important one).
In the field of critical embedded software, this has happened that's why it took off.
Another clue of that is for instance the Event-B/Atelier B that is intensively used in the railway/metro world (Paris line 14 was made with it, 2 bugs found in 15 years). While doing B, you get a broad specification you refine along the way into smaller problems. Writing code is actually the last step you do, when you are sure that all pieces fit together.
Learning how to write code isn't a significant barrier. It's just pressing buttons on a keyboard. Logical thinking and problem solving are far more important. Switching to a visual language doesn't actually help you with that. Worse, if clicking virtual buttons with a mouse is slower than pressing physical buttons you will waste mental capacity that could have been used for problem solving and logical thinking.
Logical thinking and problem solving can greatly benefit from visual representations and feedback. I write code but I often wish the representation was much more visual than lines of dense monospaced text with a little bit of colour. Diagrams are often easier to parse and reason about. When trying to understand difficult code or figuring out a difficult problem before writing code I generally draw diagrams with pen and paper. These diagrams are much closer to my mental model than code, and I wish that a lot more of this translation could be automated.
"Visual language" doesn't have to mean low-bandwidth interactions.
It seems to me that when creating a visual programming language for a particular class of programs, you probably find that making this translator is the same hard mental work that would let you make a text-based programming language instead. Once you have a good mapping from thoughts to code, the visual part doesn't add much. I was talking to a non-programmer recently who had tried Scratch and gotten tired of the visual layer very quickly. It's rare to see a visual -> code mapping that retains value after you've used it the first time, i.e. value beyond teaching.
I like the general idea of going the other direction, from code to diagram. I'm not interested in editing the diagram, but it's great for reading the code and sanity checking. But it doesn't have to be the actual code. A great many projects would benefit from having a GraphViz generator instead of hundreds of printlns. I was talking today about adding a GraphViz .dot visualisation to the salsa-rs incremental computation database, because I was reading the documentation on garbage collection and just wanted to see it in action. I know the rustc folks have been doing this for ages.
I think in addition to generating graphviz, it would be cool to have a log viewer that can render it.
$ my-program
normal logs
viz:"digraph {\n0 -> 1..."
more normal logs
^C
$ my-program | logviz
normal logs
more normal logs
... and a window pops up that animates changes between each graph that appears in the logs. Or even better, a tool that takes regular printlns of edges, nodes, etc, interprets them as an append-only variant (with deletion, etc) of graphviz, and assembles them into a graphical representation that changes on the fly. So you don't need to have a graph implementation in every language you want to do it with.
> Once you have a good mapping from thoughts to code, the visual part doesn't add much.
Having the visual representation readily available is indeed "great for reading the code and sanity checking". Writing code (here meaning text or visual) involves reading code, both the code you're currently writing and anything that is connected to it. Thus the visual representation is also good for writing code.
I'm not advocating a low bandwidth interaction model. I can certainly see why some people might quickly grow tired of Scratch, but I'd argue that's a problem with the specific language/editor, not something that is universally applicable to anything that tries to go beyond "text". Structured editors can beat text editors in interaction speed.
Then I'm struggling to understand the value proposition. If I did want to stick to implementing it visually through sequence diagrams, can I implement all the examples through a sequence diagram and have it run on Ballerina? Really curious. If yes, I'd really like to try it. There are no instructions/examples on doing that.
EDIT: I found a link to using the graphical editor in the comments here.
