Liunon was first documented in my Q4 2023 newsletter — an experiment in building a tool where seeing every step of the graphical thinking does not require additional effort, but is a part of how the tool works.
Outside of work, I've been noodling on a new creative coding environment, in which you generate images by querying the existing state, and asserting a new one, in a sort of transactional ↗ way, with the hope that each of these transactions will also have a meaningful representation, so seeing the intermediate steps requires no additional work, it is the work ↗.
Let's see how we could create something resembling the Space Colonization ↗ algorithm in the tool.
First, we assert that there's a page to draw on, place a bunch of attractors, and a single node in the middle:
Second, we give each of the nodes two "zones" — one which "growth" is directed by, and another, smaller one, where the attractors are "consumed". So far so good:
Third, we have to grow towards the attractors by creating new nodes, and consume them if they are in the consumption zones:
This big step does a lot, all at once, which doesn't really help much with understanding what's going on. There's iteration, there's a lot of state, and a lot of playing computer in your head.
To make it worse, we also loop this step 20 times, to let the structure grow out a bit (with a simple number picker out of the frame), and you can only see the last step of that process.
Finally, we can drop all the circles, leaving just the lines...
...which we can export, convert to G-code and plot on the DIY Pen Plotter, which was my plan all along:
Let's go back to the middle step — as you probably realize, it is the one that I'm pretty unhappy with. It feels as if I've been struggling with some version of this problem for a while now — representing and visualizing single values is not that hard, but as soon as collections come into play, the simple solutions fall apart.
We hit this earlier on in Inkbase ↗ where interacting with a single item was nicely visualized with inspector panes, but groups of objects were not. We tried to explicitly solve this in Crosscut ↗, but the solutions were far from ideal. I also hit this in my research at Glide ↗ where displaying lists of values is the main thing you do.
So far, I've seen two interesting approaches to solving this:
spread
operator in Apparatus ↗, which is well illustrated by the Bar Chart example ↗ — notice how the X
property spreads between 0
and 10
. It is a single property, but represents a collection, and each of the other operations "just work" (you can sin(X)
and get back a spread of values — I've heard that this is pretty much a "List Monad").map
behavior as part of the core interaction, with each step being visible and represented on the screen. Engraft is especially promising — an attempt at building an environment where various live, visual, domain-specific tools can coexist and communicate with each other.One more random thought — the idea of "rubbing a database ↗" on a creative coding library could be an interesting tangent to explore on its own. For example, imagine having computed facts that could be queried too, like intersections, nearness, etc. — which feels similar to how Realtalk works (a database-OS powering Dynamicland ↗).
Anders Hoff a.k.a. Inconvergent ↗ has also been exploring home-grown Datalog for making computer art ↗, which is worth checking out (both for the computing, and the art).
622 words published on 2023-12-03 — let me know what you think