https://twitter.com/spiralganglion/status/1134318733571137537 I laid out some of my "really wish we had this" ideas for node-based visual programming language UI design in this Twitter thread. What VPL UI ideas do you really wish we had?

everything you mention sounds great, one of the limitations is (I think) that most of the people here are stronger on compilers, language, semantics and software in general than design, so even when they believe in VPL it's hard to take into account what you mentioned in the last tweet (all the design considerations and their implementation)

That's a great point. There are things like Blocky, but I don't know of anything similar for node-and-wire languages. There's Unity (and Flash before it), but those tools still require a lot of expertise and a lot of effort to build a meaningful prototype.

something in between, higher level than a drawing library, but lowerlevel than "create an instance with some parameters"

Am a huge fan of the data-as-nodes, functions-as-edges paradigm introduced by PANE (Joshua Horowitz). Forces you to work with the data and maintain its visibility and clarity at all times

Off the top of my head: * Componentization: not allowing the developer to see the entire network, only a single level: the component in focus, and how it fits into its environment. * Free edge directions: input-left / output-right does a huge disservice to readability * Deterministic shapes: a component with given child components, connections and parameters should look the same. (visual hash) * Filtering that highlights relevant nodes by dependencies, function, etc * Slow motion, time machine * Forking and comparing changes: multiple variations of a change running concurrently (imagine 3 variants of a component laid out side-by-side) * Topography-based diffing for version control. * Test paths: selecting a path with test input (eg table) and output components (eg. chart), straightened out and annotated. * Edge bundles: connecting certain types of nodes may require multiple connections between them. These should be nameable and marked differently.

@Dan Stocker Fantastic ideas there. Topography-based diffing is something I have in mind, but for a different use case than version control — topographic find & replace. I wonder what other dev features you could make based on that sort of topographic awareness. Can you describe "Test paths" in more detail?

"lisp/llvm/pypy/bootstrap of VPLs" -- That's partly what I have in mind for the project I'm working on

@Ivan Reese: I agree there’s a lot of potential in basing features on recognizing / comparing topography. By “test paths” I mean something like a cross-breed between integration tests and documentation. Take a series of connected nodes, eg. A->B->C. In the context of a test “path”, you supply inputs, and match outputs to expectations. But beyond this, you can also attach explanations as to what is happening when data flows through this path. The way I picture this, when you activate a test path, the rest of the graph fades out, and the nodes involved rearrange into a vertical chain; revealing inputs, outputs, and comments / explanations.