[throwaway632]

Another problem with visual programming is it forces your program to be planar, or at least nearly planar with some crossovers.

In my experience real code can't be represented legibly on a 2D plane. "Generate code map" features of IDEs usually produce incomprehensible graphs, when you try them on actual codebases.

I never tried CodeSee before it shut down, was it any better?

[k_g_b_]

What is code in a text editor if not a legible 2D planar representation of the "real code"? The real difference between text and a graph of definition-use edges and nodes is that the text representation does not have any intrinsic information on the real code's structure and does not display definition-use edges - at least by default. Most code editors provide some way (via LSP/etc) to display the edges however - usually as a list of the other end of the edge in a dialog/window/similar separate from the code. Given that some textual representation (e.g. variable names) of source and target is possible, a graph-displaying editor can just "abbreviate" an edge (or: make it implicit) by using the other end of the edge. If a graph editor makes all edges implicit by a certain strategy of using names/whitespace/parentheses/etc, the result would be a text representation a text editor displays. The main issue is not in difference of display, but in the mode of editing: a text editor allows much more partial input that violates the structure a graph is expected to have: malformed definitions of programming constructs that are neither a node nor an edge in the graph. A graph editor must either allow such partial input in some way (e.g. enter temporary textual representation, transform into group) or use a different input model that doesn't allow such unrepresentable input, e.g. using mostly mouse, or an editing keyboard language like Vim's objects & verbs. On the other hand a text editor requires you to agree on a formatting style with your colleagues and running autoformatters, looking past useless formatty diffs in code review, fixing syntax errors, dangling else,...

[zem]

i think the parent meant "planar" in the graph sense, that is, capable of being drawn in a plane with edges not crossing each other.

[LudwigNagasena]

And text forces you to be linear. It’s no coincidence that everything asynchronous is treated as a minefield of potential race conditions and ephemeral bugs.

“Real code” allows you to hide the mess behind imports (I think everyone had experience of dealing with accidentally circular imports at least once in their career) and abstractions. But once you put your code as a graph on a 2D plane, you realise what kind of horror you are dealing with. And sometimes even this trick doesn’t work: For example, it’s hard to abstract away the states and transitions of a finite state machine; so while they may look fine on a diagram, they often look like a mess of spaghetti as code.

[vmfunction]

Or if you do functional Scheme Bricks is perfect visual programming language for scheme/lisp

https://github.com/nebogeo/scheme-bricks