I think are a great many cases where it is much easier to express certain operations graphically, as opposed to in code or through a plain-text description. I think the recognition of this gap is one reason for the development of Wolfram SystemModeler (here's an article by Stephen Wolfram saying more about the variety of interfaces and how they fit together).  The interesting thing about SystemModeler is how it exploits the similarity between the fixed topologies expressed by graphical diagrams and the fixed relations of equations in engineering components.  What this says to me is that graphical interfaces might most readily be used to express invariant relations between mathematical structures, rather than more procedural processes, and that functions could take such diagrams of equations as inputs.  In this way, I imagine the current interplay between SystemModeler and Mathematica might be the prototype of the inteplay between graphical and functional processing to come.

George,

I like your thinking regarding a graphical shorthand, this and the existing code form would have its unique advantages . The ability to edit a fully native component diagram so that the textural code would automatically update and remain synchronized, and vice versa would be very useful .

In the cases where I need such a diagram, either because the complexity of the code warrants it and/or when I need to communicate the process flow to other non-programmers, I maintain a parallel diagram using Visio which can be clunky.

Have you seen “What’s the analogue of UML in Mathematica land?” at StackExchange?

1. See the paclet "UMLDiagramGeneration":

---

2. Alternatively, LLMs can be used together with the Wolfram Function Repository function MermaidInk.