I've been trying to come up with an alternative diagram schema that would improve the ease of readability and writability for drakon diagrams for people who have never programmed before. I know these types of schemes are hated by people who are used to doing things the coding way, this isn't for them.
The main idea is to remove the freedom and flexibility of diagrams, so that diagram composition is done in mostly the same way, appears more uniform and consistent, between languages and no matter who authored the diagram.
Here is a prototype showing how some of the alternative schema would look. I'm a fan of using alternative shapes for different types of icons, but my mockup software didn't allow for it, so they are all just rectangles in the picture.
![Изображение](https://i.imgur.com/EjvSnCf.png)
Principles:
Diagram name definitions, variable name definitions, function calls, operators, and other special types are centered horizontally and divided by a black line.
Numbers, strings, and other data types are left aligned. Each element of this type must only exist by itself on a line, but you can place multiple data entries on new lines without a divider line separating them.
Each type will have its own icon (right aligned) which tells the user what that box contains - such as a diagram name (filled star), parameter (hollow circle), operator (filled circle), variable assignment (hollow triangle), variable definition (solid triangle), function call (hollow star), or nothing (End icon).
Booleans will have some graphical indicator for the yes/no branch, here, just Y or N triangles.
Lines will be arranged the same way as normal Drakon diagrams are, but there are only primitive diagrams, no silhouette diagrams.
To make up for the lack of silhouette diagrams, entire function call icons should be able to be opened like popup windows in the IDE, so you can jump around to different diagrams, see how they work or edit them, and close them to reveal the original diagram you were working in originally beneath. In this sense, every diagram in a file that calls another diagram becomes part of a silhouette without requiring it to be strung together horizontally with addresses.
In addition, individual icons should be capable of being folded and unfolded, like folding bracketed code in a text editor. This helps deal with the inevitably taller diagrams due to only doing one thing per line rather than long code blocks with syntax peppered in.
For example, in the mockup, when the variable name declaration icon is folded, it should read like this:
Код:
variable name = (5 + 5) * 2
, even if this requires the concatenated version to be wrapped to a new line to prevent the icon from being resized to a wider width. This helps readability, while maintaining the ease of editing/authoring one step at a time when unfolded.
While this may seem destructive at first, I believe it will lead to people writing smaller and more focused diagrams (functions) which don't take up as much space. This leads to better formulated programs made up of functions which truly do one thing only, and an IDE that encourages this practice is a good thing in my view.
On top of what is shown on the mockup, syntax highlighting may be used to further help distinguish the types - the icons should still be used as the definitive context clue though because they never change, while syntax highlighting can vary due to theme. Also, there is more possibility for unique shapes to distinguish more types than simple highlight colors.
Loose thoughts about iteration:
As convenient as for each type syntax is, I don't feel it is robust and consistent enough for new users. I am leaning toward the idea of removing for loop icons completely in favor of keeping arrow-loops only, with a new universal function called iterate() that works for each implemented language. For example, you would call iterate() on some variable containing a list, object, array, etc. If there was a next value in the iterable, it would return that value, if not, it would return false. Then you would use a boolean with an arrow loop to continue the iteration. All of this could be done in one continuous icon using the style shown in the mockup, and collapsed into a more succinct form as explained previously.