Got another idea for a visual programming language. As is my style, this one has an extremely specific sense of the progression of execution over time. It's not node-wire strictly speaking. Code objects are arranged in space, and time progresses by scanning over the objects in a specific direction, like a scanline. You get data parallelism (looping across), and iteration (looping down). Data is reified (the scanline "carries" the data as it moves). I've got some sketches, which I might share in a day or two if they turn out nicely. More than viewing this as a fruitful direction to explore unto itself, it makes me think that any given approach to visual programming comes with tradeoffs. So rather than picking one direction and trying to stretch it to encompass all use cases, you should probably just make an environment where each subsystem can use whichever approach suits it. You'd use node-wire where that works best. You'd use block-based where that works best. You'd use some sort of tree editor where that works best. Makes me want to do a "visual programming jam" where people have to come up with totally new ways to visualize the structure of code and data, complete with visualized execution semantics. "We wanted to make a visual programming system that was especially good at visualizing data transformation, so you use these little.. waldo worms to dig into a structure (like json, say) and pull out the appropriate data. Each worm wants to eat a certain kind of food, which is the access pattern... and you can... see, here, on the side, there's a little stripe where it shows what this worm's food is" But I digress.

I like the idea of visually 'guiding' your program through different editing/coding styles! (and also a visual programming jam!)

Y'all know I've been trying to follow Glamorous Toolkit and create domain specific visualizations atop a "text" substrate. Ideally you rarely have to deal with the raw representation, but it still seems useful to provide access to the low level representation precisely as a way of creating new views/styles.

Hmm. The way I like to work is first imagining nothing but shapes and colors in motion, and then trying to figure out how those shapes and colors might be a programming. I worry that trying to build visual representations atop an existing programming (which I've considered many times with, say, Clojure) forces commitments or obligations that you'd otherwise be free from. Eg: You'll think, Clojure data structures are immutable, so the visuals ought to show functions that take and return immutable data, rather than, the data is a mountainous landscape, singular and rooted solidly in place, that the code ambiently traverses. Sure, you can force a mapping, but it feels more generative to me if you start with the programming part as blankly slated as possible.

Would you consider JSON fairly preconception-free?

Good point! I would consider "(like json, say)" to skirt the line between painting a mental image in the mind of the reader and not committing oneself to a specific substrate :)

A possible formalism for these Waldo worms (albeit using a textual representation): https://michaeldadams.org/papers/scrap_your_zippers

Sounds a little like a more useful Befunge