The problem becomes if the form you're used to working with the code in is very different from the form you need to communicate about it in.
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.
The trick is that you don't round trip. You choose one immutable data structure that captures both the textual source of the program and the semantic information captured by the parser at the same time.
That doesn't solve anything. The problem isn't how to represent the AST, but defining both a visual and textual version that can unambiguously represent the same thing without either or both representational becoming unusable.
Right. I think it's already a solved problem though. HTML and the HTML DOM are a living solution to that exact problem. All that we have to do is take the patterns used to power general UI and develop a DOM for code.
Now consider I have a visual programming version representing that expression, and I want to ask someones opinion about it on Slack. Unless your visual programming environment has a solution for how I can post that to Slack, and have others respond with tweaked versions, it's a non-starter.
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.
Your assumption is that visual programming and textual programming are disjoint, but I have not observed this to be true (necessarily). Being able to edit a program in a semantic fashion does not preclude its having syntax. I don't see syntax as a boondoggle to be eliminated, but rather the highest-bandwidth way we know how to convey information!
I think you're right that the end game of any successful attempt at standardization is integration with all those tools like Outlook, Slack, Discord, Signal, Word, Docs, Notion... The list goes on and on. It's strange how the presence or absence of political momentum behind a standard could change that from being "basically impossible" to "basically inevitable"
I've assumed nothing of the sort, nor have I argued for syntax to be eliminated. Both wildly misrepresent what I've argued.
On the contrary you will find that throughout this thread my biggest issue with visual programming is the reverse:
That a textual syntax that maps cleanly to the visual representation is an absolute necessity.
The problem is no visual programming system has included such a system. They've either been only visual, or they've been visual representations of programs written in classical programming languages.
Nobody has come up with, e.g. a language designed specifically to facilitate new visual programming capabilities without losing the ability to cleanly roundtrip to text.
I tried and gave up. Maybe I'll revisit it again in retirement, but I really hope someone beats me to it and finds something that works.
But then you want to write about it and explain it to someone else, and you're back to needing a way to represent it that fits on a page or can be explained verbally.
ProtoFlux is largely explained through tutorial videos I think. And I'm not saying that is superior. But I can imagine a lot of quality of life features around explaining it through voice that could be added to make it potentially superior or at least competitive.
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.)
Requiring me to watch videos to follow along is an absolute non-starter to me. It's way too slow. If it was just learning an environment maybe I could tolerate that, but the showstoppers is communicating about code for projects. An AI bot doesn't solve this - if you can't relay the information textually, there's no reason the AI bot will be able to.
Sibling is right that video was the problem for me with that specific bit, but also: Text isn't necessarily a hard requirement, but the alternative is harder, in that then you need a tool chain that covers everything we do with code. That includes putting it in blog posts, emails, Slack in ways that are searchable, and can be decomposed into smaller bits, so images are insufficient.
It's possible for a visual programming system to work without it, but it will need to be accordingly a far bigger step up.
Consider searchability on e.g. Stack overflow for example. If people don't have a consistent, shared vocabulary, just lack of searchable exposure is likely to forever condemning it to a niche.
The context within which we build visual programming languages needs to change in order for it to stop being a niche. As you point out, the alternative is [much] harder [today]. But I think that VR, as an example, will be forced to solve a lot of difficult UX problems if VR is to progress beyond a niche. And once those problems have found satisfying solutions the context for building nice visual programming languages will likely also have improved significantly.
I don't see what VR has to do with this. You'd still need all the software you transfer this information via to support more complex data, and you'd still need a vocabulary to communicate about it. And if you have that, it doesn't need to be VR.
(EDIT: And specifically to the sentence you cut that out from: For it to appear in search results, and so be discoverable* it still needs to be in a form that search engines know how to index)
There's nothing technically preventing us from having all our software allowing the embedding of visual code elements that can be manipulated via components - the technology to do that is decades old.
The problem is a combination of social, inertia, and the chicken and egg problem of there not being any sufficiently compelling visual programming system creating a significant reason to push for this.
I don't want to discourage people from trying. By all means, try - I'd love to be proven wrong, and I think you might very well discover something useful or learn worthwhile lessons from trying to push the limits of this. There are just lots of pitfalls to address.
Better to round-trip to the AST, and have the textual representation be derivative of that (e.g. by a code formatted like Go).
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.
Why would you want to work with the text representation, except when debugging or in the backend? I mean I get why you'd want the text representation to exist--we have mountains of infrastructure around text-based representations of code. Git for version control and LLM code models would work out of the box, for example. But that can all be handled on the backend by transpiling the AST to text as needed. Why would the user need to interact with the textual representation?
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.
> Why would you want to work with the text representation, except when debugging or in the backend?
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.
I think that it is probably worth addressing what sort of textual visualization you have in mind. That way, you could disabuse people with naive notions like myself.
I've not used a visual programming language and unit is (currently) hugged to death. But, my experience with graphviz's dot syntax would suggest putting a comment on the (textual) line that represents the edge itself:
digraph whatever {
running [ shape = "triangle" label = "program running" ]; # comment on the node itself
stopped;
running -> stopped; # comment about the edge
stopped -> running;
}
I acknowledge, though, that I'm thinking of this as a dsp-style situation, where a node only connects at its boundaries, rather than in the center (say if a node contains code that would link to another as part of an if expression's body).
(Also, I'm disappointed that I need to resist the urge to talk about Bob Nystom's visual pdf diff, because it seems really cool but is not as credible as the edge directive above. https://journal.stuffwithstuff.com/2021/07/29/640-pages-in-1... , scroll to 3/4 where it says "Here is what all of the proofreading changes look like:")
> I acknowledge, though, that I'm thinking of this as a dsp-style situation, where a node only connects at its boundaries, rather than in the center (say if a node contains code that would link to another as part of an if expression's body).
I think that might well be one of those restricted situations where visual programming often works well enough that it seems some use. I'm absolutely not saying it can't ever work.
My problem with it is more when you try to do more general-purpose things with it, and you e.g. either end up with a node per method/function call (and maybe then even nodes for argument expressions) or large, complex nodes with internal logic.
I love dot for graphs, but the challenge to me with that approach is that I've not seen a convincing example where you'd then not end up with a mountain of text for even very simple things (and I've sinned badly there myself - one of my own early attempts serialised to XML...) when you decompose the text enough that you can augment it reliably.
E.g. consider a complex expression where that edge is not just a simple state transition, but a method call with arguments, where each argument itself might be a complex expression...
Every attempt I made myself ended up with a textual version that was too verbose to feel viable for communication about the code unless I stripped out so much that the visual tooling effectively became a tool to analyse the textual version, rather than allowing editing on equal footing.
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.