6 ms·

The fundamental problem in visual programming is that it limits you to geometry (practically to 2D euclidian space). Most non-trivial programming problems are s

The fundamental problem in visual programming is that it limits you to geometry (practically to 2D euclidian space). Most non-trivial programming problems are spaghetti by nature in such spaces.

vbezhenar 2y ago
But program code is 2D as well. And quite limited 2D, with 80 characters width max (or similar, but never unlimited).
- scialex 2y ago
  The fact you can give things names means that there is rarely a need to follow the edges so the visualization is much less cluttered
- mapcars 2y ago
  Nah, code is 1D with line breaks for visual comfort
- lukev 2y ago
  You could argue it's 1d, actually, since sequence is fundamental, not positioning on the x axis. At any rate it's (mostly+) categorically different from what visual programming attempts. Code must be read, comprehended, and a mental model built. Visual programming is designed to give a gestalt spatial intuition for code structure -- a different kind of comprehension. +Indent and spacing between functions/methods does count as a tiny bit of visual programming IMO
- SonOfLilit 2y ago
  Code is 1d with named links. Visual languages trade named links for global wiring, which is very cluttered for serious problem solving.
  - Nathanba 2y ago
    Code is not 1d, a single if() already creates another line that makes it 2d
    - mapcars 2y ago
      How is `if` related with creating a new line? And how does new line make something 2D? If code was 2D you could write code anywhere in your document without juggling around spaces and newlines
    - SonOfLilit 2y ago
      Mathematicians like to use parametrizations to measure "how |any dimensions" something has. If you need two indexes to traverse it (x and y), it's 2d, if a single index works best to describe it, it's 1d. Another way to think of it is "there is semantic meaning to 'the character to the right/left of this one', but is there to 'the character above/below this one'?" In most programming languages, there isn't at all.
  - whstl 2y ago
    > Visual languages trade named links for global wiring Existing visual programming langs can definitely do "named links". A lot support named function-like blocks which are another form of avoiding wires. > which is very cluttered for serious problem solving This clutter is also problematic in textual programming, and is the reason abstractions and programming structures are used. Perhaps the hint here is that we need better ways of representing abstraction in visual programming.
lukev 2y ago
I got the Apple Vision Pro with the hope to tinker with such things. Is one more dimension enough to "unlock" visual programming? I don't know, and unfortunately not many seem interested in exploring it.
- jampekka 2y ago
  I don't think extra dimensions help. Even simple functions have easily tens of interconnected references and representing these spatially is gonna be a mess even in higher dimensions.
- beefnugs 2y ago
  I personally wont ever be interested in VR until it has "generic computing" as a major feature. like automatically creating a 3d world showing pipes as your internet connections, some kind of switches and buttons and things as every single thing you can do with your computer including complicated ass command line and GUI windows. And all the tools necessary to reduce or increase the complexity of it as I see fit as a user
mapcars 2y ago
That is not a problem, and for sure not a fundamental one. The textual representation is very limited, it's actually 1D with a line breaks helping us read it. 2D gives a lot more possibilities of organising code similar to how we draw diagrams on a whiteboard.
- jampekka 2y ago
  Power of text or other symbols is that they aren't spatially bounded. That's why it works even in "1D". There are probably some possible usability gains from adding dimensions. E.g. node-type "programming" in Blender is quite nice. But for general purpose progamming it's hard to see how we'd get rid of symbolic representation.
  - andrewflnr 2y ago
    Specifically, textual programs use symbols to build a graph of references between computations, where the average visual language tries to use explicit lines between blocks. But the reference graphs of non-trivial programs are often decidedly non-planar, which only becomes a problem when you try to lay them out on a plane.
    - lolinder 2y ago
      Why does laying out code on a line not cause a problem with spatial reasoning but a plane would? Are we somehow incapable of applying spatial abstractions when we move up into a higher dimension than 1?
      - edflsafoiewq 2y ago
        Writing is based on speech, which is one-dimensional. Most programming is actually already highly two-dimensional thanks to its heavy line orientation. But most visual programming isn't trying to be a kind of "2D orthography" for language, it is trying to be a "picture" of a physical mechanism.
        2y ago
hackit2 2y ago
Mapping to a plane doesn't help you understand how state changes occur over time, or what is the over-all state of the state-machine is. The only time I've seen visual programming work is when the state is immutable. How-ever it requires a major paradigm shift how one design, develop and test their programs.
- RogerL 2y ago
  it's pretty basic topology - embedding versus immersion. you cannot embed anything but the simplest software in a 2d plane. you end up having to endlessly try to structure things to minimize line crossings, make multiple diagrams of the same code to capture different aspects of it, or otherwise perform perversions just so it fits on a page. And I live through this. most of my early career was DoD related in the early '90s, when things like functional analysis was all the rage. endless pages of circles and lines which were more confusing than helpful, and certainly didn't actually capture what the software had to do. Bever again.
  - hackit2 2y ago
    I agree with you how-ever the elephant in the room is a image or topology doesn't predicate anything (A predicate is seen as a property that a subject has or is characterized by). That is the main delineation between them, and why SPO (subject predicate object) is used universality by all modern languages - abet some have different svo ordering but I digress. The next major draw-back with visual programming is they don't explicitly convey time. You have to infer it via lines or sequence of diagram blocks. Were in a programming language you have sequential order of execution eg. left to right, top to down of of the program flow and stage change. If you attempt to achieve the same with a stateless event driven bus or message queue, you end up having to embed the sequential control flow into the event payload itself.
mdaniel 2y ago
And yet IDA and Ghidra use that same 2d representation structure for basic blocks (e.g. https://byte.how/images/ghidra-overview/graph-edges.png https://byte.how/images/ghidra-overview/graph-edges.png ) showing code flow between the blocks I have had better-than-average success representing the high level sequence of computer-y actions using sequence diagrams, and suspect strongly my audience would not have the same comprehension if I used pseudocode or python or C++ Where I think the anti-visual programming audience and I can agree is the idea of a standard library, since a bunch of diagrams showing a "length" message being sent to a String object is for sure the wrong level of abstraction. In that way, I'd guess the DSL crowd would pipe up and say that is the same problem a DSL is trying to solve: express the code flow in terms of business nouns and verbs, and let the underlying framework deal with String.length nonsense I've seen a hybrid approach to this in a few testing frameworks, such as Robot Framework <https://robotframework.org/robotframework/latest/RobotFrameworkUserGuide.html#screenshots https://robotframework.org/robotframework/latest/RobotFramew...>
- Jtsummers 2y ago
  The reason it works out so well (contrary to many people's intuition) is that most programming is done in structured languages or in a structured-style these days. This significantly reduces the number of entry points (typically down to 1) for any block of code, though it can still have many exit points. Unless someone abuses something like Duff's device or uses goto's to jump into a block (and the language permits it), the flow diagrams like in the linked image end up being pretty tidy in practice.
jayd16 2y ago
By this logic its strictly better than a linear textual document, no? In a graph you can explicitly draw lines between connections.
pjmlp 2y ago
I would vouch a different take, visual programming makes it quite clear the mess of programs some people create when they don't follow modular programming. Complex flows can be packaged into functions and modules representations, instead of dummping everything into a single screen.
- frou_dh 2y ago
  Much like designing Integrated Circuit chips, vs. only doing basic breadboard-ing.
  - pjmlp 2y ago
    Yes, very much so.
  - jampekka 2y ago
    The spatial (usually largely 2D in IC) constraints are a huge limitation for circuit design. I'm quite sure chips (or breadboards) wouldn't be designed like this if the physical world wouldn't force the geometry.
    - frou_dh 2y ago
      I meant more that the very concept of an IC is a good idea, and like a good abstraction in programming. I think pjmlp was getting at is that when using visual programming, a lot of people seem to turn off (or not cultivate) the part of the thought process concerned with creating good abstractions, despite it at least being possible to do so.
      - pjmlp 2y ago
        Exactly, packaging transitors into IC Modules, so to speak.

The fundamental problem in visual programming is that it limits you to geometry (practically to 2D euclidian space). Most non-trivial programming problems are spaghetti by nature in such spaces.

vbezhenar 2y ago

But program code is 2D as well. And quite limited 2D, with 80 characters width max (or similar, but never unlimited).

scialex 2y ago
The fact you can give things names means that there is rarely a need to follow the edges so the visualization is much less cluttered
mapcars 2y ago
Nah, code is 1D with line breaks for visual comfort
lukev 2y ago
You could argue it's 1d, actually, since sequence is fundamental, not positioning on the x axis. At any rate it's (mostly+) categorically different from what visual programming attempts. Code must be read, comprehended, and a mental model built. Visual programming is designed to give a gestalt spatial intuition for code structure -- a different kind of comprehension. +Indent and spacing between functions/methods does count as a tiny bit of visual programming IMO
SonOfLilit 2y ago
Code is 1d with named links. Visual languages trade named links for global wiring, which is very cluttered for serious problem solving.
- Nathanba 2y ago
  Code is not 1d, a single if() already creates another line that makes it 2d
  - mapcars 2y ago
    How is `if` related with creating a new line? And how does new line make something 2D? If code was 2D you could write code anywhere in your document without juggling around spaces and newlines
  - SonOfLilit 2y ago
    Mathematicians like to use parametrizations to measure "how |any dimensions" something has. If you need two indexes to traverse it (x and y), it's 2d, if a single index works best to describe it, it's 1d. Another way to think of it is "there is semantic meaning to 'the character to the right/left of this one', but is there to 'the character above/below this one'?" In most programming languages, there isn't at all.
- whstl 2y ago
  > Visual languages trade named links for global wiring Existing visual programming langs can definitely do "named links". A lot support named function-like blocks which are another form of avoiding wires. > which is very cluttered for serious problem solving This clutter is also problematic in textual programming, and is the reason abstractions and programming structures are used. Perhaps the hint here is that we need better ways of representing abstraction in visual programming.

lukev 2y ago

I got the Apple Vision Pro with the hope to tinker with such things. Is one more dimension enough to "unlock" visual programming? I don't know, and unfortunately not many seem interested in exploring it.

jampekka 2y ago
I don't think extra dimensions help. Even simple functions have easily tens of interconnected references and representing these spatially is gonna be a mess even in higher dimensions.
beefnugs 2y ago
I personally wont ever be interested in VR until it has "generic computing" as a major feature. like automatically creating a 3d world showing pipes as your internet connections, some kind of switches and buttons and things as every single thing you can do with your computer including complicated ass command line and GUI windows. And all the tools necessary to reduce or increase the complexity of it as I see fit as a user

mapcars 2y ago

That is not a problem, and for sure not a fundamental one. The textual representation is very limited, it's actually 1D with a line breaks helping us read it. 2D gives a lot more possibilities of organising code similar to how we draw diagrams on a whiteboard.

jampekka 2y ago
Power of text or other symbols is that they aren't spatially bounded. That's why it works even in "1D". There are probably some possible usability gains from adding dimensions. E.g. node-type "programming" in Blender is quite nice. But for general purpose progamming it's hard to see how we'd get rid of symbolic representation.
- andrewflnr 2y ago
  Specifically, textual programs use symbols to build a graph of references between computations, where the average visual language tries to use explicit lines between blocks. But the reference graphs of non-trivial programs are often decidedly non-planar, which only becomes a problem when you try to lay them out on a plane.
  - lolinder 2y ago
    Why does laying out code on a line not cause a problem with spatial reasoning but a plane would? Are we somehow incapable of applying spatial abstractions when we move up into a higher dimension than 1?
    - edflsafoiewq 2y ago
      Writing is based on speech, which is one-dimensional. Most programming is actually already highly two-dimensional thanks to its heavy line orientation. But most visual programming isn't trying to be a kind of "2D orthography" for language, it is trying to be a "picture" of a physical mechanism.
      - 2y ago

hackit2 2y ago

Mapping to a plane doesn't help you understand how state changes occur over time, or what is the over-all state of the state-machine is. The only time I've seen visual programming work is when the state is immutable. How-ever it requires a major paradigm shift how one design, develop and test their programs.

RogerL 2y ago
it's pretty basic topology - embedding versus immersion. you cannot embed anything but the simplest software in a 2d plane. you end up having to endlessly try to structure things to minimize line crossings, make multiple diagrams of the same code to capture different aspects of it, or otherwise perform perversions just so it fits on a page. And I live through this. most of my early career was DoD related in the early '90s, when things like functional analysis was all the rage. endless pages of circles and lines which were more confusing than helpful, and certainly didn't actually capture what the software had to do. Bever again.
- hackit2 2y ago
  I agree with you how-ever the elephant in the room is a image or topology doesn't predicate anything (A predicate is seen as a property that a subject has or is characterized by). That is the main delineation between them, and why SPO (subject predicate object) is used universality by all modern languages - abet some have different svo ordering but I digress. The next major draw-back with visual programming is they don't explicitly convey time. You have to infer it via lines or sequence of diagram blocks. Were in a programming language you have sequential order of execution eg. left to right, top to down of of the program flow and stage change. If you attempt to achieve the same with a stateless event driven bus or message queue, you end up having to embed the sequential control flow into the event payload itself.

mdaniel 2y ago

And yet IDA and Ghidra use that same 2d representation structure for basic blocks (e.g. https://byte.how/images/ghidra-overview/graph-edges.png https://byte.how/images/ghidra-overview/graph-edges.png ) showing code flow between the blocks I have had better-than-average success representing the high level sequence of computer-y actions using sequence diagrams, and suspect strongly my audience would not have the same comprehension if I used pseudocode or python or C++ Where I think the anti-visual programming audience and I can agree is the idea of a standard library, since a bunch of diagrams showing a "length" message being sent to a String object is for sure the wrong level of abstraction. In that way, I'd guess the DSL crowd would pipe up and say that is the same problem a DSL is trying to solve: express the code flow in terms of business nouns and verbs, and let the underlying framework deal with String.length nonsense I've seen a hybrid approach to this in a few testing frameworks, such as Robot Framework <https://robotframework.org/robotframework/latest/RobotFrameworkUserGuide.html#screenshots https://robotframework.org/robotframework/latest/RobotFramew...>

Jtsummers 2y ago
The reason it works out so well (contrary to many people's intuition) is that most programming is done in structured languages or in a structured-style these days. This significantly reduces the number of entry points (typically down to 1) for any block of code, though it can still have many exit points. Unless someone abuses something like Duff's device or uses goto's to jump into a block (and the language permits it), the flow diagrams like in the linked image end up being pretty tidy in practice.

jayd16 2y ago

By this logic its strictly better than a linear textual document, no? In a graph you can explicitly draw lines between connections.

pjmlp 2y ago

I would vouch a different take, visual programming makes it quite clear the mess of programs some people create when they don't follow modular programming. Complex flows can be packaged into functions and modules representations, instead of dummping everything into a single screen.

frou_dh 2y ago
Much like designing Integrated Circuit chips, vs. only doing basic breadboard-ing.
- pjmlp 2y ago
  Yes, very much so.
- jampekka 2y ago
  The spatial (usually largely 2D in IC) constraints are a huge limitation for circuit design. I'm quite sure chips (or breadboards) wouldn't be designed like this if the physical world wouldn't force the geometry.
  - frou_dh 2y ago
    I meant more that the very concept of an IC is a good idea, and like a good abstraction in programming. I think pjmlp was getting at is that when using visual programming, a lot of people seem to turn off (or not cultivate) the part of the thought process concerned with creating good abstractions, despite it at least being possible to do so.
    - pjmlp 2y ago
      Exactly, packaging transitors into IC Modules, so to speak.