What is text? This blog post reminds me of the time 10 years ago when I tried to do away with Linux's desktop environment because it seemed overly complex and hard to wrap my head around. I had a lot of trouble running wifi without the desktop environment, and it left me quite bitter. Linux had seemed like a hacker's OS when I first started out. But it was trying so hard to compete with Windows that it was starting to seem like Windows in all the wrong ways, it seemed. That experience contributed to me walking off into the wilderness to build Mu. I've gone back and forth between two tendencies in my life. On the one hand, I used to brag about a minimalist setup living in text mode, only running startx as needed, long after the world had moved to fully graphical desktop environments. On the other hand, I was frustrated early on with the limitation of pure text, creating a little bit of Vimscript to view and edit drawings inside a code fold inside code comments. (I don't remember what format I used for the drawings. Maybe Inkscape? I always liked its format and found it quite easy to hack manually.) And these poles have continued to attract me in turn. I wanted to build Mu with just text mode for a long time, and now in the past couple of years I seem to have tried to minimize my use of terminals, with all their ugly historical and path-dependent hacks, and to do more on a graphical canvas (of a game engine). Trying to look back dispassionately, I seem to operate by: Structured data. Not too much. Mostly text. But then, last year, I had a fascinating and also slightly frustrating conversation with a friend where we realized we had very different associations for the term "text". When I said I wanted to keep something as "just text" I meant "viewable with cat on a vt100." (But with Unicode.) When they said they wanted text they meant, "everything you could do in the tradition of book publishing before the advent of computers." (But maybe not images? Equations and line drawings, certainly. And video is right out.) Another dimension of our disagreement: I was thinking of text in terms of compatibility. What can you do regardless of what device you have on you right now. They were thinking in terms of "what's possible with an extremely low-power reader without regard to compatibility." Also, I imagined authoring text and reading it as happening on the same device. Perhaps they imagined authoring on high-powered devices and reading on low-powered ones. So, 30 years after I started programming, I still don't really understand what I want. I try to clear my mind of the cobwebs created by the hacky, historically path-dependent past. But I'm not there yet.

As I start teaching the kids programming, I’ve been thinking about how to motivate it to them. They do a lot of drawing, so that seemed like a potential hook to show how drawing on the computer may make some things easier (erasing, manipulating, repeating) and other things harder (e.g. drawing well). Demo of a little bare-bones fork of Lua Carousel for a computer with a large screen and a mouse. The large screen is divided up between a code editor and a drawing area. There are a few drawing tools. When you make a stroke the code for it is inserted above the cursor in the code editor. You can also edit the code directly and run it to make changes to the drawing area. There is no support for grabbing points or shapes in the drawing area. All you can do there is emit shapes with coordinates. Everything else you gotta program the old-fashioned way. Download (120KB). Inspired by Ronin and Sketch-n-Sketch.

An experiment involving scrollbars Keeping scrollbars easy to acquire even in large files. Demo of an idea for a scrollbar with a shadow or "penumbra" which makes it easier to acquire to drag around, even as the conventional and smaller central object continues to be visible to give an accurate sense of file size and our position in it. Thanks Artyom Bologov and Mary, though I ended up taking their suggestion in a different direction…

As an experiment, I've machine-translated the help docs in Lua Carousel into 7 languages: Spanish (Peninsular and Latin American) German French Japanese Chinese Portuguese Hopefully it is helpful for someone to no longer have to put up with English. I put each language in a separate download to reduce the amount of data you need to download. Other languages are machine-translated from the English version. I've had friends spot-check it for obvious issues, but there are likely to be problems I missed. Please report any issues you spot. If you want to manually translate pages to improve wording and tone for your culture, contributions would be most welcome. No support yet for right-to-left languages, or languages with combining characters. Lua Carousel still assumes every character on screen is atomic. For example, I can support Chinese and Japanese but not Korean, Arabic or Indian languages. I don't know what I'm doing when it comes to multilingual keyboard support. My rough sense is that that's something to configure for your device. But if there's something I can change in Lua Carousel to make your life easier, please let me know. I've included different fonts for Chinese and Japanese, which blow up the download size for these languages. The source code inside each zip file download is exactly the same, only the font files are different. The larger font files also seem to take up to 10 seconds to load.

I've been reading The Nature of Order by Christopher Alexander, and it's inspired me to experiment with this representation to communicate the global structure of the source code of the Game of Snake: 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.