Reposting ;) Periodic self-reminder. The main ideas behind Hest are: 1. Nobody’s made a good computer code out of things moving through space. 2. Moving through space is also about moving through time. Rewind is table stakes. 3. If moving through space is meaningful, then space itself is part of that meaning. Position, distance, velocity — they mean something. 4. You can do things with this meaningful space-time visual code that you simply can't do in a non-moving visual code.

Have you thought about how proximity as meaningful computation comes into play here?

Yep. One of my favourite references for proximity is the project by @Nikolas, which visualized message broadcasts as these rings that expand outward from an object. Receivers that are near the source will receive the message first. Also, there's eToys (IIRC… or maybe it was Morphic?) where you'd compose two graphical objects by sticking one onto the other — that's a more binary interpretation of "proximity", in that things that touch are composed, things that don't touch aren't. There are also some grid-based systems where cells can only talk to their neighbours. One approach I've tried in Hest visualizes functions as nodes, function composition as wires connecting the nodes, and function application as little points of data travelling along the wires. The speed that data travels is constant, so execution order depends on things like the lengths of wires between nodes.

Oh wow Zells is really cool!

Yes. And I've had a few ideas for how to resolve this tension, such as: • Other kinds of wire with different conveyance semantics (eg: wires that convey instantly, or that do a store-and-forward sort of thing) • Varying the speed of wires (which is what Factorio does) • Backing away from the idea that there are multiple pieces of data moving simultaneously, and instead only having a single moving datum (with others either queued up waiting for their turn, or perhaps requiring execution to be triggered by something separate from the data points) I haven't prototyped any of these yet, though. Also, this is an area where I'm not even sure why order my priorities are in, so while it's easy to imagine a wide variety of solutions, it's hard to have a sense of how these solutions will fit in to the overall design.

Do you have good examples of #4

Sure. One of my favourites is that, in Hest (node-wire, with data represented as points that travel along wires), you can just grab a data point with your mouse and pull it off of the wire, and stick it off to the side. Then later, you can drop that data point anywhere else in the program and it'll resume travelling toward the next function. It's sort of like REPLing into a running system and pausing a thread of execution and snapshotting the state, and extracting that state and putting it _somewhere_… and then being able to resume execution at any other point with that very same state. But you do it with the mouse, by dragging data around like its a ball bearing in a Rube Goldberg machine.

Is the ability to pick data points off a wire lead to non-deterministic behavior of the system?

Is the ability to pick data points off a wire lead to non-deterministic behavior of the system?

Yes. It's much the same as pausing with a breakpoint, changing the values in some variables, and then resuming. You're just also changing a little bit of process stuff at the same time. (Which, I imagine, would be a totally normal thing to do if you were debugging, say, Erlang + OTP. But I haven't done that, so I can only imagine).