In practice every attempt I've looked at either become hard to communicate about the code in, or the visual aspect tends to end up just becoming a secondary visualisation of code that you still treat as textual first.
In the latter case, turning it into a better UI is an unsolved problem, because round tripping reliably between something readable as text and a meaningful visual representation is really hard.
As I said, I hope someone solves this, but most attempts aren't even pushing the boundaries into uncharted territory - a lot of attempts have been made over the years.
E.g this is a real line of code:
link = wf["links"].find{ _1["rel"] == "self" && _1["type"] == "application/activity+json" }
Once you've solved Slack - maybe with a plugin -, you need to solve all our e-mail clients, and you need to solve Google Docs and Word for when we write documentation, and a multitude of other tools.
You might be able to get part of the way there with a browser plugin, but you'll still have a wide variety of other tools and platforms to cover.
https://youtu.be/70PH5cQQEdQ?si=y4YmhnimzferVpCD
Since you develop inside vr you can also talk about and show the code in the same vr environment.
It's probably at this level we need to rethink stuff to make visual programming practical.
You could for example explain every node verbally and visually to an AI bot that can then explain it to the next person, or selectively retrieve parts of your explanations on demand. (OK, I realize that sounds unnecessary complex.)
This also makes it easier to verify that you have all the same capabilities in both representations, as the ways of manipulating the AST are enumerable.
I built a language and UI around that way back, and many others have. I ditched mine because there were way too many unsolved problems I felt made it useless.
The problem is that if your primary means of working with the code is visual, the textual representation of your code then tends to be foreign to you when you're trying to use it to communicate aspects of the code, and when you constrain yourself to something that can be represented in a readable manner in a textual form, it turns out to be really hard to get to a point where the visual form is easier to work with.
E.g. something as basic as how you comment code in ways that roundtrips nicely is an unsolved problem.
If I have code represented as a graph, I'd be inclined to want to label relationships and dataflows that would be hard to place textually in a way that is meaningful in a textual version and that would roundtrip back to labels in the right place in the visual version.
I've not seen any attempts at visual code that gets even that right.
I've not managed to get it right myself either. If you force users to use an editor built into this tool, and edit a textual representation where some information is hidden, you can do better, but then if people e.g. copy a textual representation of the code into another application and back in, you end up with a mess.
Again, I want to be proven wrong about this. Badly. I love the idea. I've just seen enough failed attempts (and made enough failed attempts) to be disillusioned about it.
Commenting needs to be solved at the language level, and there are many languages that have solved this exact problem. Python, newLISP, and Smalltalk IIRC all have methods for docstring commenting APIs such that the docstring is available as text to the running program / REPL. Use similar syntax to allow any statement to have comments attached, and use this instead of free-form /* */ comments.
How would I communicate about the project to others in e-mails, instant messenger, face to face, in blog posts, in articles, in books?
How would I review diffs of code changes effectively?
That is why.
Find me a representation I can talk about and write about efficiently without screenshots or videos or requiring special software of every recipient on every platform, and you'll have advanced the state of the art in this field immensely.
> that have solved this exact problem
None of the ones you described have solved the problem of mapping between a visual and textual representation of the program seamlessly. Just attaching the comments from a textual version to an AST of the textual version is trivial. That's not the challenge.
> Use similar syntax to allow any statement to have comments attached, and use this instead of free-form /* / comments.
That doesn't get close to solving the issue. When I have a diagram showing the data flow of a piece of code, and I attach a comment to the
edge* between the two nodes, in the textual representation where does that comment go? Does it go in the text version of the source node? In the destination node? What if I write a comment in the textual version right before a method call, and then switch to the visual version, does that stay in the source node? Does it become a label of the edge representing the method call? There are tons of edge cases there.The problem isn't finding a way to attach the comments in the right place, but finding a way that roundtrips perfectly without adding noise in either representation.