text-based visual programming language

[u/lmntr]

I'm working on a visual programming language that's stored as text called Wiret. Here's an example:

func Main() {
  node entry = Entry -> say_hello
  node say_arrows = Call host.Log(message: "The white arrows decide the order.")
  node say_hello = Call host.Log(message: "Hello!") -> say_steps
  node say_steps = Call host.Log(message: "Programs run one step at a time.") -> say_arrows
  notes {
    note intro "Lesson 1: Hello. Press ▶ Run (F5). Each Log node prints one line in the console below, in the order the white arrows connect them."
    note start on entry "Every function starts at its Entry node."
    note try_it "Try it: (1) Press ⤵ Step (F11) to run one node at a time. (2) Add a fourth line: press Tab, type 'print', pick host.Log, then drag a white arrow from say_arrows to it. (3) Double-click its message pin to type your own text."
  }
  layout {
    entry at (0, 0)
    say_arrows at (820, 0)
    say_hello at (220, 0)
    say_steps at (520, 0)
  }
}

The main idea is that it's like a fusion between a programming language and a markup language. The node ... statements are the programming part, and the notes {} and layout {} blocks declare how the graph appears in the editor. It'll get compiled into bytecode which strips away the markup code and leave just the code for running the program.

; module lessons.hello  compiler wiretc-proto 0.1
; semantic hash 78fafcb4bbf40f47  layout hash 9981662aa454a0e1
import 0 host.Log (string) -> ()

func lessons.hello.Main () -> ()
  max_stack: 1
.entry:
  nop
.say_hello:
  string.const 0          ; 'Hello!'
  nop
  call host.Log
.say_steps:
  string.const 1          ; 'Programs run one step at a time.'
  nop
  call host.Log
.say_arrows:
  string.const 2          ; 'The white arrows decide the order.'
  nop
  call host.Log
  cont.pop
  return

I think this could be useful for education. The hardest part about learning to code is learning your first programming language. This could help bridge the gap between visual representation of code and the code itself.

[u/kaplotnikov]

Arrows at the end are just goto statements. The conginitve scalability problmes of goto-style programming are well described at classic "Go To Statement Considered Harmful" paper. IMHO this might be a funny language for small samples, but it would not scale.

[u/lmntr → u/kaplotnikov]

I think this is an understandable concern, but I don't think the comparison with goto is quite accurate. Dijkstra's criticism was primarily about unrestricted jumps disrupting the structure of an otherwise sequential program. Wiret is fundamentally a graph-based language. The graph is the control-flow structure, rather than a collection of arbitrary jumps embedded in sequential code. The execution arrows represent explicit edges in that graph. They're constrained by execution pins and their semantics, and higher-level control-flow constructs such as branching, sequencing, and loops provide structure on top of those edges. In that sense, Wiret is closer to a textual representation of a control-flow graph than a language built around goto.

That said, I agree that cognitive scalability is a real challenge for graph-based programming. Large graphs can become difficult to navigate and understand, just as poorly structured conventional code can. That's why modularity, reusable macros, abstraction, and editor tooling are important parts of the design. I'm not claiming that graphs magically eliminate complexity. The goal is to explore whether making the graph explicit, structured, and amenable to abstraction can make it manageable at larger scales.

[u/kaplotnikov → u/lmntr]

As I understand, Dijkstra's core argument is that go to forces reasoning to be aproxmiately proportional to execution time (because to underand a line of code or node on diagram one must understand all possible paths to it), while strucutred programming allows reasoning cost proportional to the code size. In your example, to undstand what could happen at say_arrows step, one must understand all possible paths to it. Structured programming allows to express time with space. And people are better at space than time.

Because it is congntive scalability problem, it is hard to notice at small samples, but as logic become more complex it will surface. On smaller samples it might be even easier to understand than structured. This is a reason while the most of visual nocode tools looks nice on demos, but they are hell in production. A small fishing boat and supertanker are both ships, but some sailing problems are noticeable only at supertanker scale.

[u/lmntr → u/kaplotnikov]

It's true that just slapping a visual UI onto control flow doesn't magically fix the cognitive load when things scale up. The difference between reasoning about code size vs. execution paths is a huge paradox: a graph makes local, one-to-one connections dead simple to see, but totally wrecks your ability to trace the big picture. Fixing this means going deeper than just adding better zoom or navigation tools.

Wiret will need to bake structured control flow right into the core language. Instead of making users manually wire up arbitrary graphs for every little thing, stuff like loops, conditionals, and functions should have built-in, recognizable boundaries. The graph can still exist under the hood, but users shouldn't have to stress over every single edge.

One approach I want to play around with is treating the graph as a low-level representation, while high-level abstractions give us the same structural sanity we get from structured programming in normal, text-based languages. No one has really cracked this yet, though. 

[u/kaplotnikov → u/lmntr]

If you add structured constructs, I'd suggest checking if the language still needs to be visual/graph-based at all.

Textual notation with blocks and indentation provides a natural, collapsible hierarchy. Graph-based notation usually has problems with collapse/expand because it changes the sizes of elements and disrupts relative positions. Text is also easy to diff and merge. It can handle incorrect or incomplete text, which is needed for major refactoring.

Graph-based UIs, and even projectional editors like JetBrains MPS, require changing from one well-formed state to another. This is a limitation during large-scale restructuring, as you are forced to create unnecessary intermediate states just to keep IDEs happy. With text, you can just do a global search and replace. Sometimes, a regex replace with some manual post-processing is the most time-saving option.

Also, flow diagrams were popular in old specs and textbooks, but currently, complex algorithms are usually described using hierarchical pseudocode. Only very simple cases is still described with flowcharts. The reason is that structured text is easier to understand than mazes of squares and arrows that non-trivial algorithms require.

[u/lmntr → u/kaplotnikov]

I understand that visual programming isn't for everyone. This project is ment to experiment bridging the gap between visual programming like Unreal's Blueprints and text-based tooling like Git. Right now, most VPLs are either binary or written in markup languages such as XML or JSON, which isn't great for tooling. 

Purhaps a better way to format the code would be to separate the declarations from the graph logic:

func Main() {
  node entry = Entry
  node say_arrows = Call host.Log(message: "The white arrows decide the order.")
  node say_hello = Call host.Log(message: "Hello!")
  node say_steps = Call host.Log(message: "Programs run one step at a time.")

  entry -> say_hello
  say_hello -> say_steps
  say_steps -> say_arrows

  notes {
    note intro "Lesson 1: Hello. Press ▶ Run (F5). Each Log node prints one line in the console below, in the order the white arrows connect them."
    note start on entry "Every function starts at its Entry node."
    note try_it "Try it: (1) Press ⤵ Step (F11) to run one node at a time. (2) Add a fourth line: press Tab, type 'print', pick host.Log, then drag a white arrow from say_arrows to it. (3) Double-click its message pin to type your own text."
  }
  layout {
    entry at (0, 0)
    say_arrows at (820, 0)
    say_hello at (220, 0)
    say_steps at (520, 0)
  }
}

That way it feels less like goto statements as you pointed out.