1. 24
  1.  

  2. 5

    Visual Programming is pretty close to my heart.

    I like how the Author sets up the article, because their initial analogy is a good exposition of how they are thinking. The torch analogy was clear because it tells me what the Author is after: they feel that a single page view of source code limits them from the overview of the program as a whole they would like a better way to navigate while keeping the entire structure of the code “in their head”.

    This is an important problem to tackle. Modern IDE’s help with their project structure browsers and their go to definition functions, but in the end, the only way to internalize the structure of code is to repeatedly read different parts of it, following the function calls and the method imports until it is … internalized.

    A tool that would help with this would possibly look like what the Author has, possibly look like a souped up version of the code minimap that has become fashionable in code editors, combined with better factoring of the code into well named functions and modules.

    This is all important, but it is not Visual Programming. While one aspect of Visual Programming might be to reduce cognitive burden via the use of abstractions, a major aspect of Visual Programming is to completely abstract away things like detailed syntax into a (allegedly) more visual paradigm of wires and ports, where you wire up things because it is assumed we work more visually and

    Input ---> [Foo] ----> [Bar] ----> Output
    

    is allegedly more intuitive than

    output = bar(foo(input))
    

    Allegedly.

    What the Author has is not Visual Programming with Go, but rather a visualization of Go code structure. In my mind these are distinct.

    I know the Author is at pains to distance what they did from Call graphs and what they have here is a bit more like a Dependency Graph but this is not Visual Programming - you can not interact with the code in a way that allows you to separate yourself from syntax and replace it with a visual paradigm of dragging and dropping nodes and connections.

    1. 3

      in F# we have something like let output = input |> Foo |> Bar I was skeptical how it would help at first, but not having to consider whether something is going left to right or right to left is actually not bad.

      1. 3

        Visual peogramming pushes it further. You should be able to specify flows like

        A
         \
          C ---> D --> E
         /            /
        B -> B' >-----
        
        1. 3

          Mandatory shout out to: https://luna-lang.org, which tries to make it possible to write general-purpose code both visually or textually, and insta-translate it back and forth between visual and textual representation. While being fully open-source.

          1. 3

            I can think of two examples that get close to this using normal characters.

            1. Racket has 2D syntax for tables (https://docs.racket-lang.org/2d/index.html)
            2. Akka in Scala has an ASCII syntax for describing computational graph, which is the closest to your example but doesn’t handle the vertical connectors so some node entries must be repeated (https://doc.akka.io/docs/akka/current/stream/stream-composition.html?language=scala#composing-complex-systems)
            1. 1

              That’s really cool, now I want to make ascii-art with Rust macros

        2. 2

          This is a good observation I myself totally missed; the distinction between program (and system) visualzation and undertanding, and wiring wires and ports as you say. Also somewhat related, there was a fair bit of work leading up to y2k around program comprehension tools and extracting business rules from legacy code bases. That seems to have fallen out of favor not long after.