I believe that VPLs are better than TPLs. I include some observations that led me to that conclusion. meta: I choose to believe that this channel “thinking together” means that half-baked ideas are to be tossed out for brainstorming, pushback, discussion and revision. https://guitarvydas.github.io/2023/12/04/Code-Layout-for-Programming.html (discussion of 1D, 2D, 3D, 4D program syntax)

There are no pictures or diagrams!

Python has 2d layout. 'Visual' programming languages very rarely have spatial syntax - position/proximity is secondary notation ignored by the interpreter. So I don't think it makes that much sense to say they are 2D or 3D..

Sigh, you would think that a post about VPLs and DPLs would contain lots of pictures. As penance, I refer you to the following for some possible ideas (different agenda, but contains pictures if you scroll down): https://github.com/guitarvydas/0d @Jack Rusher

I'm working on a hierarchical approach with optional table-based code representations. I'd love to know what you think. https://github.com/Danskydan/Hilltop

fact: our quiver is full of text-processing tools, text parsing technologies fact: Ohm (OhmJS/PEG) raises the bar for writing parsers (PEG specifies Parsers, while CFGs specify Languages, PEG parses a construct that can’t be parsed with CFGs or stock REGEX (matched, recursive pairs of “???“)) revelation: some diagram editors save-out diagrams as XML (i.e. parseable text) revelation: “connection” and “containment” relationships go beyond traditional TPL (a long way) revelation: I thought that I would want “beside”, “above”, etc. relationships, but, I haven’t needed them yet. If I end up needing them, I would reach for PROLOG to infer such relationships (N.B. SWIPL can read/write JSON) revelation: backtracking makes parsing much easier (enter: PROLOG, OhmJS, PEG, (miniKanren?)) revelation: 0D adds a new dimension to think-ability fooling with: • using markdown as a programming language (parse things like “`<mark>...</mark>`” as if they were atomic characters) • parsing draw.io files (.drawio) (let someone else build the diagram editor, I build the transpiler) • examples/POCs on request (gladly, but, this reply is too long already) @Alex McLean

It rings false to me to say Blockly is fundamentally sequential. The units of code are hierarchical, with two kinds of children. And I use it to generate logical code, not imperative. But maybe you mean something else.

Maybe I have spent too much time in Lisp Land and Smalltalk Playgrounds, but I think of code as expressed in terms of data structures that can in principle have multiple visual representations, even if there seems to be a preference for something textual outside of Smalltalk.

Thanks for the deep dive, @guitarvydas. I have a lot more design to go. Ideally, I'd like to team up with someone who is much more capable than me to take on its implementation.

@Jason Morris I would be interested in seeing examples of how you use Blockly...

If you go to dev.blawx.com there is a demo video linked from the front page!

I agree with @Alex McLean that most VPLs don't use a "spatial syntax". So what are these VPLs visualizing then? They are visually representing the topological relationships between different parts of a program. Those relationships include containment, connection, adjacency, overlap, order, etc. Most node and wire VPLs make use of connection and possibly containment (e.g. a node can itself contain a set of nodes and wires). Scratch makes frequent use of adjacency, order, and containment. There is nothing inherently visual or spatial about these relationships, they are multi-modal and lossless to transform. A textual syntax that describes these relationships has tradeoffs when compared to a visual syntax, but I wouldn't say that either is inherently better. For example, connection in textual languages has to be a symbolic reference. There is no way to directly point to a function or variable besides referencing it's name. Symbolic references are genuinely helpful when it's easy to name the intent of a piece of memory or a set of instructions. The name becomes a bookmark that is easy to remember and others to learn. But naming can be overbearing at times, and describing connection/reference in a visually direct manner removes that need in until I have to repeatedly layout and organize these connections as a program grows. To Alex's point, spatial position in most VPLs doesn't have much importance to the computer executing the program, only of those authoring the program. I'm excited to see more spatial canvases like excalidraw and tldraw start capturing these topological relationships in there underlying data structures as well as image recognition being able to do the same. It means that the ability to transfer a notation through different modalities or even bridging the physical to digital world is becoming easier. It also brings up the questions of what a VPL looks like that requires spatiality? A language that depends on location and proximity and other geometric relationships that cant easily be represented in other modalities if at all. Much of my framing is based around David Harel's paper "On Visual Formalisms" for anyone interested! https://dl.acm.org/doi/pdf/10.1145/42411.42414

Scratches use of adjacency, order and containment seem wholly textual to me. There's no real visual difference between jigsaw-piecing something inside something else to specify containment and using parenthesis ()

If there was no real difference, making languages visual wouldn't do anything. They would be adopted at the same rate, by the same people, with the same amount of success. Evidence categorically shows otherwise. Visual language seem pointless only to people suffering the curse of expertise. They are not FOR people who have already struggled through learning how to use parenthesis for containment. They are for people for whom that struggle and others like it are not obviously worth going through. They are curb cuts to allow people in wheelchairs to cross roads, and people who can walk saying they are pointless is distasteful.

I'm not saying there's no difference between languages, I'm just pointing out that 'textual' programming languages have visual features, and vice-versa. My argument is essentially "why not both"? Also I do think almost no-one will have any problem understanding the use of parenthesis for containment (partly because it's really visual)

The entire discipline of graphic design, which PLT mostly ignores, is concerned with visual properties applicable to text. I only know of two papers that try to codify those aspects in a programming context: https://hal.inria.fr/hal-00737414 https://dl.acm.org/citation.cfm?id=2661138

Those look great thanks will read! Here's a PDF for the second (paywalled) one

Speaking of graphic design and programming, also see Human Factors and Typography for More Readable Programs by Backer and Marcus. (I first learned about it in this FoC thread.)