I'm curious how Ballerina avoids (or does it?) this problem mentioned in another comment:
>once a "program" gets complex it can get tangled fast. A node with 3000 edges starts to look messy.
>once a "program" gets complex it can get tangled fast. A node with 3000 edges starts to look messy.
Unfortunately, visual languages tend to be quite poor at abstraction. We've been developing and improving ways to make better abstractions in textual languages for the last 50 years, but somehow visual languages seem to be using the same abstraction tools we had with ALGOL, when not the same ones we had with Assembler.
For a mental framework on how to analyze and design visual languages for usability, see Cognitive Dimensions of Notations.[1][2]
[1] https://en.wikipedia.org/wiki/Cognitive_dimensions_of_notati... [2] https://www.uxbooth.com/articles/a-usable-guide-to-cognitive...
It's not as simple as that. Visual languages tend to be very good at portraying a fairly large subset of abstractions - loosely speaking, many and perhaps most abstractions that you'd want to model using category theory are almost inherently "visual" - and just not very helpful at portraying others. I think the answer is a tighter integration of textual and visual "modes" on the same codebase, rather than just using visual for everything no matter what.
The problem is, how to decide what parts of the program ti represent as text, which ones are better as graphs, and where to place program data values?
In a source based language, would it have 3000 arguments or connections to other parts of the program?
This seems to be an issue of complexity management which would be the same (or worse) in source form.
If anything with a visual language you would be able to have it only show some specific nodes of those 3000 (e.g. those of a certain type, or going to a certain receiver), jump to a higher level view, and so on. With text it's all a big dump.
A visual language UI is a superset of text (and can go down to a just-source representation and source editing if needed.
The reverse is not true -- a source editor is not a superset of visual editing.