I have a question about experiments with flow-based (eg wires and boxes) programming. The main thing people complain about with them, with very good reason IMO, is how complex programs become unreadable spaghetti. By comparison, seeing code in an editor, in general, appears as a zoom-in on a few lines of code. This lets you ignore the complexity of the rest of the surrounding program - or at least temporarily avoid being bothered by it. To remedy this problem, I am guessing some people must have made auto-hide systems for flow-based programming. The equivalent of what code-in-editor has by default: you can't see the code above or below the cutoffs of the window. What are examples of systems doing this? @Jack Rusher

you can't see the code above or below the cutoffs of the window

I'm confused — don't most node-wire tools also do this? Can you give an example of what you mean by "auto-hide systems"?

@hamish todd I've never found a node-based programming environment that I like. @Ivan Reese is a much better person to ask about this, as he is very focused on that area. 🙂

One approach (perhaps equivalent to subroutines in textual code) is to be able to manually nest sub-graphs within a node. Useful when there are different levels of abstraction perhaps. I have seen this work quite effectively. It may be interesting to try to partition the graph in this way automatically (using graph theory) to place highly connected components into sub-graphs.

@Ivan Reese a simple example of what I mean by auto-hide: you have nodes A,B,C,D. The connections are A->B, B->C, C->D, A->D (last one is not a typo) You are zoomed in on B and C and cannot see their other connections. But the wire from A->D could be going over that, creating visual clutter. Auto hide might involve hiding that connection while you are zoomed in, only showing when you zoom out or pan over to D

Ah, okay! I haven't seen anything that does this exactly. I have seen some VPLs play with hiding wires in other ways: • fading out the middle parts of wires when they aren't selected, so you just see the beginning & end • making wires sort to the back, so at the very least they won't be covering other nodes • forcing nodes to be on a grid, forcing connected nodes to have some degree of adjacency, so that wires can't cross other unrelated nodes and tend to be short stubby things that might not even need to be rendered in the first place I don't really like any of these sorts of approaches, personally. My pet "solution" to the issue of the wiry mess in visual programming is that graph layout should be conceived as a first-class concern of the programmer, and the tools for working with wires should be fantastic, such that it's actually pleasing to have wires. The whole point of a visual programming system is to have wires (IMO), and the point of the wires is to convey uniquely valuable information to the programmer. So rather than hiding the wires, I'd like to see VP systems that let you wield the wires to great effect (which may, in fact, include hiding them sometimes — but that should be a thing you're fully in control of, akin to—say—code folding)

Graph homeomorphisms for the win! I'll second @Ivan Reese that serious layout support should be a focus. Is one factor simply that wire programs are more hacked together than carefully factored. I mean hacked together text code is a horror, and often can be perfectly cleanly formatted yet semantically tangled. One quality (a feature perhaps?) of functional programming is that a big ball of mud tends to look like one.