The whole program is arranged on a 2D surface within a series of nested boxes. You can hit ‘run’, and it extracts the code from the surface and runs it and you get to play a game of Snake. (Only on a computer; even though the app runs on a phone, you can't play this particular game of Snake without arrow keys.) So it can be viewed as a sort of Literate Program, even though the representation I'm tangling from has a richer UI than is typical, a surface you can pan and zoom around with a mouse wheel or touchscreen. (It doesn't support editing yet. This is a purely reading experience for now.)
I wasn't trying to build yet another Literate Programming experience, though. What was on my mind was Christopher Alexander.
Christopher Alexander (CA) was an architect, and he indirectly inspired Design Patterns in the software world. His magnum opus was The Nature of Order, (NoO) a book I'm not sure I'll ever finish. Not because it's long (it's true that it's 4 volumes, but it has a lot of pictures) but because I often need to put it down to think about the chapter I just read for a day. And then the day turns into a week or a month or a year.
The first thing to know about The Nature of Order is it defeats attempts at summarization. With that out of the way, here's a summary of the fragments I've read:
- People build tools, and then the tools change people. In unanticipated ways, for better and for worse.
- Tools and buildings (remember, CA is an architect) that contribute to more functional societies have certain objective properties. The properties are hard to state or quantify, but have an objective reality analogous to the fundamental forces in Physics. In his earlier books, CA called this property "the quality without a name." In NoO, he calls this property "wholeness" or "life".
- The degree of life of an arrangement of matter is visible in its geometric form. Function matters, but CA rejects the cartesian separation between form and function. If something has good consequences, it's going to also look good.
- This sense of "looking good" is not subjective. People often have greater or lesser sensitivity to it, but we all inherently have the capacity to see that one arrangement has more life than another.
- The degree of life in an arrangement is a holistic property. You don't compute the life of all the parts and add them up. One poor property can destroy the life of the whole.
- As a best guess, life stems from approximately 15 properties. These properties establish a field of centers that integrate object with environment, foreground with background, inside with outside, form with function, matter with emptiness.
- Centers are made of centers, recursively, ad infinitum.
- Any attempt to create life by assembling homogeneous centers is doomed to fail. Instead, nature and the universe creates wholeness and life by starting with a seed and successively unfolding it, differentiating parts of it into centers, each step of the process intensifying existing centers, bringing new centers into being, and increasing the life of the whole.
I'm not sure I buy it to the hilt, but it feels actionable even so. I don't need to believe in the objective reality of the vector field of centers to consider the possibility that it might point us in the direction of better quality as perceived by a lot of people.
The image above is a very preliminary step at creating a more wholesome arrangement of the source code for the game of Snake, though CA would likely find it sophomoric.
I'm trying to use some well-known ideas in software design. There's a top-down decomposition here. The game of Snake consists of two screens, one where you play the game and one when the player dies.
The screen for the game itself (where the player spends the bulk of time) decomposes into 3 concepts: space, snake and food.
At this point, however, things get muddy from a classic CS perspective. These concepts are not completely separate. There are places in the program where they coil into each other. For example, I can't entirely explain how a snake grows without reference to food, and I can't explain food without reference to its purpose: growing the snake.
In response, I'm duplicating this code in multiple places on the surface, with slightly different emphasis:
To me this evokes CA's property of interlock/ambiguity. The centers of space, snake and food don't have clear boundaries here, the boundary is ambiguous and the centers kinda intertwine.
Another case of interlock/ambiguity: the screens for game and game over that I mentioned earlier are not completely separate. When the game ends, there's a great human need for some sort of conclusion to be derived from it, often in the form of a score. Did I do well or poorly? Set a personal best? Defeat my friend's score? Here the score takes into account the number of times the snake turned. You can imagine alternatives, but no matter how you calculate the score, it must make reference to the game that was just played. The two screens must share data. Here I am experimenting with indicating this permeable boundary by creating a gap in multiple levels of centers, close to uses of Nsteps, to show that the centers aren't crisply isolated from their surroundings.
I spent some time on other touches. Rather than arrange code in a vertical rectangle as we usually do, I chose to break it up horizontally to make the boundaries between definitions more easily apparent.
Viewed charitably, this might be seen as an example of what CA calls "alternating repetition", an attempt at a rhythm that resonates with the reader. Interspersing prose with code is another repetition, as are the columns. However, I tried to not make the columns or interspersed prose too monotonously regular. I tried to keep it "rough", and to hand-craft the spacing at each point rather than try to enforce some global policies for spacing and positioning.
If you'd like to read a little more about Christopher Alexander and The Nature of Order, here are a couple more summaries:
- Beautiful Software is perhaps the most comprehensive archive of CA lore. In particular, see this early article about the fifteen properties.
- Dorian Taylor's obituary.
- A worked out example of the fifteen properties.
Beware, you may get sucked into the full 4-volume opus.
This post is part of my Freewheeling Apps Devlog.
Comments gratefully appreciated. Please send them to me by any method of your choice and I'll include them here.