Interesting thread and discussion topic:

Most visual programming languages make limited use of the visual channel — the program structure is represented visually, but not much else. Usually the shapes and colors they use have an abstract (symbolic) meaning, not a concrete one. What are some different approaches?

https://twitter.com/dubroy/status/1495766614377058305

I don't see how the shapes and colors could have non-symbolic meaning unless you're specifically doing graphics. The very notion of non-symbolic meaning is slippery to say the least.

Given that text only has symbolic meaning (unless you're specifically doing, like, error messages? Generative fiction?) I think the shade thrown on symbolic representation is light on substance.

Yeah, I feel like Patrick had a good idea and expressed it badly. He's looking for examples where the visual interface looks like the thing it is modelling, and the spatial relationships model relationships in the modeled world. Programming using a map instead of a diagram. It's an issue I have with Blockly, that the two dimensional space is available, but not meaningful, and when it is meaningful the meaning is opaque, and we would be better off without it.

There are ways to represent things symbolically but in ways that make much better use of the visual channel. It's not an either/or, or a single dimension. My personal view is that symbolic representation is good, but we deserve amazing symbols used in powerful ways. No current visual programming system does a good job of this. Most of them don't even bother introducing their own symbolic meanings — they just put text in boxes, use color or shape to represent type information, and are exactly as static as textual languages. Shame.

@Ivan Reese I absolutely agree, especially about the “statism” of the contemporary visual paradigm. I’m actually working out a way to overcome this (might write about it soon, but it’s still a very immature idea).

I really like a paper by Daniel Moody - "The “Physics” of Notations: Toward a Scientific Basis for Constructing Visual Notations in Software Engineering". https://ieeexplore.ieee.org/document/5353439 It highlights and explains the problems of not using all the visual properties. It seems that not much has changed since.