It would be nice to see a visual gallery similar to @Ivan Reese's codex (https://github.com/ivanreese/visual-programming-codex) that focuses specifically on comparing how concepts like looping are handled in each VPL.

Also, @J. Ryan Stinnett — Totally agreed on looping constructs being an especially interesting point of comparison. Would love to see someone (else, hah) do that analysis. Bonus round: I just went to add this to the codex and.. well, look who it is! Thanks.

some other variants that might be of interest:

Too bad you didn't choose that way @ibdknox, I really like it!

One of the big things we realized about most node/wire systems is that it’s actually pretty hard to separate the “main idea” from all the details. This vertical/horizontal split was our attempt at making that be inherent to the structure of the diagram you ended up with. The “what” flows top to bottom and the details flow left to right. This means if you read just the “spine” of the diagram, you’ve got a good idea of what’s going on.

Another thing was making sure that the locuses of action were clear and easily accessed rather than being effectively spread everywhere (which makes a keyboard-heavy flow difficult to imagine)

From my notes on it:

The “puzzle box” is a bit like a structure of spreadsheet cells, except rather than an infinite grid, only cells directly connected to an existing cell are available. We differentiate the flow of power and flow of values, by placing slots for the former on the vertical axis, while data slots go on the horizontal axis. By default, cells snap into each other like a block-based editor, but can be pulled apart, revealing a wire when more space is necessary or flow is better demonstrated. Cells usually contain textual “formulas,” which preserves the density of text and makes it easy to edit complex expressions with few actions. They can also have complex domain representations (e.g. the truth table above) that are plugged into and used directly. Using this feels more like excel than any of the previous editors mentioned. There are clear places for action - empty or existing cells - that you navigate to and start typing in. 

The puzzle box takes the best parts of text, nodes, and blocks, while offsetting the downsides of each:

• We leverage the density and familiarity of text in each cell • By using wires for branching and complex control, we can maintain the ability to easily understand the flow of the behavior (offsetting the 1D of text). Splitting control out vertically, allows you to quickly “read the spine” and get the main idea of what’s going to happen. • With the connected cells, we get the structure of block-based editors and can make it clear where actions can be performed. This also enables a primarily locate and act flow. • Rather than pure text, we can progressively disclose the internals of the cells, including showing slots only when they’re part of the flow

More on the fun/cool side, inspired by @Ivan Reese’s lunchbox sessions, we wanted to make it so that anything can be replaced with it’s representation, but retain its editing semantics. This means, for example, you could replace the wires with pipes and nodes with engine parts, but connecting them still meant semantically connecting them under the covers. 🙂 There’s a little bit of that in the images above where the picture of mario jumping is the representation of the jump node.

Like in your examples for if/then where there are several ways to represent it.

This is interesting to me, because a layout tree is a fundamentally different visual formalism from a nodes-and-wires graph. (I mean, I guess you could build a hierarchical layout with nodes-and-wires, but it wouldn't make many people happy.) But it looks like Noodl does a good job of fluidly integrating the nodes-and-wires formalism with a tree formalism. It reads well: • "Here is the part of the tree that triggers state changes when clicked!" • "Here are the parts of the tree that change appearance when the state changes!" Arguably, it would be even better if the "States" node could connect directly to the actual components in the live preview, rather than just the abstract representations thereof. This would give it a look kind of like that , where a node graph connects abstract nodes to concrete objects:

In summary: I'm excited about replacing noodles in node-graph systems with structured snapping, as @ibdknox's designs show, AND I'm excited about extending node-graph systems to include different visual formalisms, as I believe Noodl is doing!