I use such tools when I can, and am fascinated with the concept, since it evokes Herman Hesse's _Glass Bead Game_ (from his novel _Magister Ludi) which was a book I remember fondly from my youth.
Advantages are:
- discoverability --- it seems pretty easy to arrange all elements in a hierarchy and make them accessible via clicking/revealing
- no syntax errors --- if things fit together/connect, then it should be a syntactically valid program
The problem is, it relies on a couple of concepts we don't seem to have a good solution for:
- What does an algorithm look like?
- How to deal with an algorithm which is larger than the current screen/window size? (it's all-too easy to have the same sort of problem of a not-wrapped program with lines longer than the current window size and more lines than will fit in a window, and there doesn't seem to be a 2D graphical equivalent of turning on word-wrapping)
- If programs are broken down into discrete modules, then connected together, one is back to the wall-of-text description which presumably one was trying to escape from, just wrapped up in boxes and connectors
Looking at those, I feel like we are approaching the problem entirely wrong.
Even in text, you don't try and look at everything at once, zooming out for a "structure overview" seems useful, but that is not what is happening here, its just imperative code being shoehorned into a DAG and left wherever a user left it instead of organizing itself, which is the whole benefit to graphical programming.
This demo of "unit" at least seems to organize nodes and views of nodes better.
I agree, some facility for automatic re-organization and adjusting what is shown/readable in terms of hierarchy based on how much or little of the program is being shown would help a lot.
> - no syntax errors --- if things fit together/connect, then it should be a syntactically valid program
for consideration, one need not change the encoding medium to achieve this: JetBrains MPS <https://www.jetbrains.com/mps/#:~:text=Why%20MPS> (Apache 2 licensed: https://github.com/JetBrains/MPS ) is like a middle ground between "flashing cursor in a textarea" and "drag-and-drop programming" and they alleged to have written their bugtracker (YouTrack) using MPS but they have since removed the citation in the footer so I don't know if it was true or is true
But Hesse never actually describes the glass bead game. I thought that was the whole point of the book. He alludes to aspects of the alleged game, and let's the reader imagine perfection. Often similar elisions and allusions with the latest UI framework de jour.
Advantages are:
- discoverability --- it seems pretty easy to arrange all elements in a hierarchy and make them accessible via clicking/revealing
- no syntax errors --- if things fit together/connect, then it should be a syntactically valid program
The problem is, it relies on a couple of concepts we don't seem to have a good solution for:
- What does an algorithm look like?
- How to deal with an algorithm which is larger than the current screen/window size? (it's all-too easy to have the same sort of problem of a not-wrapped program with lines longer than the current window size and more lines than will fit in a window, and there doesn't seem to be a 2D graphical equivalent of turning on word-wrapping)
- If programs are broken down into discrete modules, then connected together, one is back to the wall-of-text description which presumably one was trying to escape from, just wrapped up in boxes and connectors
Two pages with cautionary images are:
https://blueprintsfromhell.tumblr.com/
and
https://scriptsofanotherdimension.tumblr.com/
I've been trying to use OpenSCAD Graph Editor: https://github.com/derkork/openscad-graph-editor in my own work:
https://github.com/WillAdams/gcodepreview
and the screen grab from there sums up the difficulties pretty well:
https://raw.githubusercontent.com/WillAdams/gcodepreview/mai...