One problem I have with Befunge (not the one you're thinking of, ha) and other fungeoids is that you have a bunch of static information about a program visible in 2D on screen, but a key piece -- the stack -- is invisible. The question I keep returning to is how one might go about making the stack (or any other run-time state used by the program) visible without just bolting it on on the side. This time around, I got hooked on the following metaphor. Imagine a spaceship that contains some data, sets out on a voyage across an infinite 2D plane, and performs various operations depending on the objects it collides with.
Example 1: The space ship contains a row of boxes. Colliding with a number pushes a box on to the nose, colliding with an operator operates on the 1 or 2 front-most boxes in the front. This is a way to display a stack, but a stack in isolation doesn't seem to scale well to larger programs.
Example 2: The spaceship contains a number. Colliding with the BF-inspired primitives + and - causes the number to be incremented and decremented, respectively. Now build addition out of it. Zooming into a number n shows it to be a loop of n iterations. When the spaceship collides with n it loops through n times, and the number inside it has n added to it. At a high zoom, you see the spaceship loop n times before exiting the "solar system". At a low zoom you see the spaceship exit instantaneously with n added to its value. Now you can imagine a reduce operation as a series of solar systems that the spaceship visits one by one.
Example 3: The spaceship contains a binary heap to insert and delete elements from depending on objects it collides with. Zooming into any single collision reveals the tree structure to be the "space" that a smaller spaceship containing a single number bounces among.
Two properties that seem important from these examples:
A hierarchical nature where space and spaceship are duals, and zooming in and out causes them to turn into each other.
Rendering the state of a spaceship needs to be extensible (like in my old Pong demo). We need to leave Befunge's ASCII behind.
At the largest scale, state machines feel like a really powerful way to represent the state within a spaceship. I often find them to be the outermost architecture of a large program. But to actually find the state machine I have to flail around for a long time. If we could use some visual paradigm at the largest scales but zoom into text as needed, programs might be much more comprehensible.
Open it on a browser tab when you clone and start editing using driver.love. There are a few examples in the Readme to spark ideas. Works on any Windows and Unix.
Update on my live-editing environment. It's still extremely easy (1% for me, 10% for others?) to crash the driver, so I've been trying to track down thoses corner cases. Realization: my memory of such crashes and instinct for situations causing crashes is extremely unreliable. Possibly the app's error behavior is changing under me during seemingly unrelated changes. I've been spinning my wheels on this for a couple of weeks. Hopefully it'll clarify over time. I might need a more elaborate set of tests that involve configuring a client app just so.
Today I got a feature request from someone in the LÖVE community and created a fork of lines.love with 2 buttons:
* `clear` the buffer. I imagine this like clearing an Etch-a-sketch.
* `export` the buffer to html. I imagine it emerging out of the app like a Polaroid.
One consequence/challenge of working with lots of forks: you develop a heatmap of the areas of your code most likely to have merge conflicts. I feel a very tangible pain now any time I have to touch something within 3 lines of the place where I set the window title. Every fork has a different window title, and the idiosyncracies of text-based diff guarantee every fork will flag a spurious conflict.
Hmm, perhaps I should start surrounding such lines with 3 empty lines..
The layout is extremely jank, but it makes up for it somewhat using keyboard navigation. And you can click on any node to copy its URL.
LÖVE doesn't yet support https. The next version should, but I finally lost patience and temporarily put together a Lua+luasec crawler that invokes LÖVE.
Like my last few apps, this one can be edited live without restarting it.
Hmm, the second point in the alt-text for the second image requires a correction.
> The current implementation definitely has a bug relative to my intent..
The bug isn't in the implementation but in the algorithm itself. It violates the final constraint I'd set for it.
> cousins never overlap columns
Hmm, time to read the literature.
Ah, it only took a slight tweak. This looks much better.
