The Orthogonal Bet: The Wonders of Graph Paper and Algorithmic Art

Danny Crichton:

Hey, it's Danny Crichton here. We take a break from our usual Riskgaming programming to bring you another episode from our ongoing mini-series, The Orthogonal Bet. Hosted by LUX scientist and resident Samuel Arbesman, the Orthogonal bet is an exploration of unconventional ideas and delightful patterns that shape our world. Take it away, Sam.

Samuel Arbesman:

Hello, and welcome to The Orthogonal Bet. I'm your host, Samuel Arbesman. In this episode, I speak with Alex Miller, a software developer and artist who works on, among other things, a project known as SPACEFILLER. This product is an example of what is known as generative art, where you use computer code to create art and imagery. SPACEFILLER itself is a kind of pixelated artwork that feels organic and biological, but is entirely created from the world of the algorithm. I wanted to speak with Alex to discuss more about SPACEFILLER, but also about generative art more broadly, and even the idea of coding as fun and playful. Alex and I had a chance to explore these topics, as well as computation as art versus computation as software engineering, the nature of algorithmic botany, and even the wonders of graph paper. Let's jump in.

Alex, it is great to chat with you, and welcome to The Orthogonal Bet. Thanks so much for taking the time. I really appreciate it.

Alex Miller:

Thanks for having me.

Samuel Arbesman:

Yeah. I think the best place to start, we can go in lots of different directions, might just be to talk about a project of yours, SPACEFILLER. Maybe if you can just share a little bit about what it is, how you came up with this, every aspect of it. We can take it from there.

Alex Miller:

Yeah. So SPACEFILLER is like a band, I think of it almost like a band of musicians, is my model for how it works, because it is a collaborative practice where there's people that come and go depending on the project, but I kind of am a little bit of the lead singer, I guess you could say. But it is a collaborative art practice. So me and my collaborators are really interested in using the tools of generative art, which I'm sure we'll get into later, to create experiences for viewers that are immersive, that are surprising in some way, that play with human perceptual experience. And I think at its core, the SPACEFILLER project is really about an awe of nature, whether that's more explicit in terms of generating simulations of plants or little organisms, or maybe a little bit more abstract in terms of... Computation itself is a big part of nature, and it's part of the fabric of the universe and stuff like that.

So yeah, that's a synopsis of SPACEFILLER. Practically speaking, we do a lot of interactive installations, so that takes the form of a projector, something being projected upon some sort of affordance for interacting with the installation. We also do visuals for music, and we do web-based works as well.

Samuel Arbesman:

What does it look like? I've seen it, it's hard to describe maybe, in words, for our listeners, but can you take a shot at trying to describe what this looks like, and then we can talk about, what are the different components of what makes SPACEFILLER look like SPACEFILLER?

Alex Miller:

There are a few different SPACEFILLER styles, I guess you could say, or threads that I pull on visually. One common aspect, which I think probably comes to your mind when you think of the SPACEFILLER piece, is that it's a little bit like lower fidelity. It's a little bit pixelated, it's a little bit minimalist in terms of its graphics. And one of the core principles, I think, behind all of the SPACEFILLER work is this emphasis on the algorithm as the first-class citizen of the work. So we're not trying to use a lot of special effects to make something look very realistic. We're trying to let the algorithm shine. And so, oftentimes when I'm playing around with what visual style to use, I'll land on this very minimalist, almost like it's a video game or something, like a retro video game, if that makes sense.

Samuel Arbesman:

And you mentioned being inspired by nature. There are these biological features to it, which I think, and maybe this would be a good time to describe a little bit what generative art is, and these strategically generated ideas, and how they play into inspiration from nature and things like that. Because when I look at SPACEFILLER stuff, it feels like I'm, I don't know, looking under a microscope at a droplet from a pond or something like that, but also pixelated and strange and different, and there's a lot of different things going on there.

Alex Miller:

Yeah. It's a lot of simulations of nature, so whether that's flocking birds, or little amoeba that divide, or plants that grow almost like you're looking, like you said, things that are under a microscope. I'm obsessed with microscopic imagery. I have an arena channel with a ton of images of microscopic imagery.

Samuel Arbesman:

That's fantastic.

Alex Miller:

I love that idea. It's almost like you're peering into a science laboratory in another dimension where everything is made with algorithms, or something. It's like a video game science laboratory, or something like that.

Samuel Arbesman:

You and I have spoken about this, but I use this term of emergent microcosms, where it's using a relatively small set of algorithms or relatively small chunks of code, using these to create these microcosms, whether it's looking underneath a microscope or whatever it is, these entire worlds, through code. Because, and I think this is the idea of generative art, is that, and the feature of the computer, is that, does not get tired and it can do lots and lots of calculations, and so it can run these algorithms in ways that are emergent and surprising, and you can take inspiration from lots of different areas, whether it's amoebas or blocking or whatever.

Alex Miller:

Yeah, the idea of emergent behavior is super huge for a SPACEFILLER. And yeah, it's probably worth describing a little bit about what that means. So I have my own personal taxonomy of generative art in my head, and this is not... This very, very personal to me, this is just kind of how I see the world. When we're talking about generative art, we're talking about things that are created with code. So they're visual, maybe they're sound too, they're like these animations, but they are generated in real time using computer code.

And I divide up the world of generative art into two broad categories. There's pieces that I call "function of time" pieces, where all of the state that you're seeing, all of the graphics or the sound or whatever it may be, is all a function of time. So there's a single parameter, T, that moves forward in time, and then all of the pixels or whatever's going on in the piece, all depend on that single parameter. Creating generative art in that way has a lot of advantages, because you have a lot of control and it's a completely deterministic style of simulation. It's analogous to, in math, what would be an analytical solution to a problem where you have a function of T and you have a formula that's totally dependent on T.

Then there's another category in my head, again, this is my personal taxonomy that I think of as stateful pieces. So these are pieces where the next state of the system depends on the previous state. So that means that the history of the system is like a feedback loop into the future. And so rather than just a single parameter, you have many, many parameters. And these sorts of systems end up being really interesting because it's a trade-off. If everything was a function of time, you'd have really tight control visually over the art piece. So you lose that control, but you also gain this ability to have surprise. Because if you set up a system in this way where there's a feedback loop, things happen that you as the artist just don't expect.

I have hit this many, many times in my own work where it's like I'm designing a little algorithmic creature in some sort of little microcosm world, and I give it some simple rules and I press the play button on my simulation, and it does something totally different from what I expected, and maybe it's wrong, maybe it's buggy or something, but then I realize, "Oh, it's not a bug. This is actually more interesting than what I was trying to do."

So yeah, I think the stateful style of peace is what I'm really interested in, just because it has visual interest, and it is also surprising for me as the art maker to interact with a system like that.

Samuel Arbesman:

And related to the systems that are a function of time, presumably, the one that is more stateful could be eventually into this kind of function of time, but it's just a limitation of our minds or our ability. They should be convertible, and there should be some sort of transformation, but obviously, the way you build them is completely different. And I think, related to that, there is this surprise and emergence. Those are features that are almost built in to the more stateful version versus the time piece. Would that be a fair way to describe that or?

Alex Miller:

I'm not so sure about that, actually, because one property of pieces that are a function of time is that you can jump into the future. So if we're at time equals zero right now, and I want to know what my piece looks like at time equals 100, I can just jump to that point in the future. And because everything is totally dependent on the single variable, everything is determined by that. And so I can easily compute some frame of my animation in the future.

Samuel Arbesman:

Okay.

Alex Miller:

But if you have this more stateful piece where you have emergent behavior, there's no shortcut to get to the future, because every step depends on the previous step. And that's actually part of what makes it so interesting, is that no... You just have to press play and see your simulation play out. And you don't know what it's going to do, and you can't skip into the future, if that makes sense.

Samuel Arbesman:

And so SPACEFILLER is definitely this state-based approach, I would say.

Alex Miller:

Exactly, exactly.

Samuel Arbesman:

And it's predicated on creating the sense of surprise, or at least you create the sense of surprise for yourself, and then in turn use that as the fodder for delightful experiences, presumably.

Alex Miller:

Exactly. Yep, that's right.

Samuel Arbesman:

But it sounds like you're also combining lots of different algorithms and features of nature, or just other ideas that you're aware of together. How do you pick and choose? Is it simply artistic considerations, there's art plus surprise, do you have a certain vision going in that then you kind of guide the system towards? How do you think about what pieces need to be combined together?

Alex Miller:

I generally don't have much of a vision going in when I'm working on art, I usually have more of a bottom-up approach where there is some small detail of a simulation that I have an idea for. So for example, maybe I have the idea that I want a particle system where there are teams of particles, and one team of particles chases the other team of particles. Very basic, almost like a game of tag or something. And I'm just curious to see, if I build a simulation of that idea, what will it look like? So I don't have a grand vision of what the end result will be, I don't know if anything will come of it, but it's like this idea on a much smaller level. Then I write the computer code to implement that idea, and I see what happens.

And usually, nothing interesting happens at first. Usually, my idea is not actually that great, and it's pretty boring, but once you see it visually, you immediately have a new idea. Like for example, maybe if one team cases the other team, that's not that interesting, but what if we have three teams that all chase each other, and so there's a cyclic nature to the simulation? Let's see what that looks like. And then you press play on that simulation. And you make these steps through a space of all possible simulations, looking for pockets of interesting behavior.

So yeah, I would say, going into it, it's never worked for me to have a top-down vision, because it's really hard to create an emergent system that achieves a specific vision because of the thing that we were talking about in terms of surprise, you don't know what the system is going to do, so you don't know how to reach a specific point in that space of systems. You just have to follow the local gradient at every step, if that makes sense.

Samuel Arbesman:

Yeah, yeah. And this parallels nicely the work of Ken Stanley and Joel Lehman and their book, Why Greatness Cannot Be Planned, this idea that when you have some sort of high-dimensional search space, you don't necessarily want just a single objective function. You optimize for finding interesting things or searching for novelty, and then combining those little bits of novelty and interestingness that you've discovered in new novel ways, which can then yield new abilities and new things. And it sounds like that's kind of what you do, where there's a certain thing that you're curious about, begin doing that, combine it with some other things, go from there. And then slowly but surely and iteratively, you've created this really surprising and delightful thing.

Alex Miller:

The combination aspect that you mentioned there is also very important, because sometimes I'll start with a small idea, build it up into something interesting, and then I'll think, "Oh, could this interact with a previous experiment I've done?" Maybe I have these teams of particles that are using each other and, "Hey, I built this other system that was a particle based plant growing simulation. Can I have these two beings live in the same space? And then how do they interact?" So yeah, creating lots of systems and then combining them is definitely a core SPACEFILLER practice. And I would say that is something that differentiates SPACEFILLER from a lot of other generative art that I've seen, which, just to be clear, there are master generative artists who do incredible work that I'm so, so amazed by, but oftentimes, people will create one system and really focus on it, and I think some of that complexity and some of that richness that I get with SPACEFILLER pieces is that combining multiple systems into the same space.

Samuel Arbesman:

And so related to that, when I think of SPACEFILLER, I have certain images in my mind, which makes me think that SPACEFILLER is almost this canonical set of algorithms and images and visualizations. But it sounds like not quite that, you're constantly adding things, but maybe you're changing... Would it be fair to say that SPACEFILLER is almost like it's a piece of software that has different versions, and maybe there's forks and things like that. Is that the right way to think about it?

Alex Miller:

You don't want to see the code base. The code base is terrible. There are many, many forks. It actually is distressing to me. It is actively distressing how crazy the code is, because I'm a software engineer professionally, so when I'm at my day job, I'm very careful to make sure my code is very clean, and I follow best engineering practices and all that. But when I open up my laptop at night to hack on some SPACEFILLER art piece, I work in a totally different mode where I just throw out all of the programming best practices. And so I have multiple repositories of SPACEFILLER code. Each one has many different. So yeah, it's something that I'm constantly tweaking, copying and pasting the project, and then making a bunch of changes. There are a core set of interesting algorithms that I've landed on at some point, and I've just basically stuck with it because it's been so fruitful. But yeah, I'm constantly remixing what I've made before, adding something new, etc.

Samuel Arbesman:

You mentioned by day you're a software engineer, and then by night and on your own time, you're doing this. And the code itself almost has this very different aesthetic. You said it's a lot messier and somewhat distressing, in your own words. Is that because this kind of work, of this almost like, computation as art, should have a different feel when you're writing these programs? Is it almost supposed to be a little bit messier, or a little bit more fun, and as a result, you don't want to engage in some of these best practices? How do you think about that sort of dichotomy there?

Alex Miller:

That's really interesting. I actually haven't quite thought about why it is that, it just is. But if I were to analyze it, I think it has a little bit to do with this idea of experimentation and iterating and observing your local landscape of a branch and taking small steps. Because I don't know exactly where I'm going, I don't know what the end vision is. It's hard to have best programming practices in a way that you might at a software engineering job. This is true of software engineering as well. You move in small steps, you iterate, you don't necessarily know exactly where you're going. But I think with the art side of things, the steps are so tiny that you just want to let yourself flow.

One thing that I've realized is really important for my process is to focus on the visual output to the exclusion of everything else. So whenever I get wrapped up in trying to make my code look nice or trying to follow better practices in terms of programming style, I lose the visual thread. I lose the thing that I'm actually curious about. So it's better for me to be in this tight iteration loop and just throw everything else to the wind. The downside is that then when I go to pick up a project after a long time, I have an idea to combine two systems, so I'm like, "Oh, I'll go look that system up from six months ago. It's pretty raw to do that, but it's okay. I think that's just part of the process that I've accepted for myself.

Samuel Arbesman:

And maybe one way to put a spin on it is it's almost, in the same way that you're inspired by biology, there's this very evolutionary process with the code and the art, and maybe in the same way that the genotype, the actual DNA sequences can be messy and there's lots of things, but you're not optimizing for that, you're optimizing for the phenotype, what it actually looks like and how it is as art. I'm probably taking the evolutionary and biological analogy to the breaking point, but there might be something there in terms of how evolution works with what it has and rejiggers things and reinterprets.

Alex Miller:

You might be onto something there, because is it true, I don't know the first thing about DNA, but is it true that there are sections of your genome that are unused, or they look like noise a little bit?

Samuel Arbesman:

So historically, people thought that, we now think that more and more, it's really just humans don't understand what it does yet. I would say the vast majority of DNA, let's say within a human's health for example, is not coding for genes. It's not coding for proteins or enzymes and things like that, but it has a whole host of other functions that we haven't quite understood yet, especially in terms of regulating genes and doing things like that. That being said, there are things in biology that don't necessarily have a function over time, because they haven't been weeded out by the process of natural selection. So you end up with things that are, like our appendix is not particularly useful, and sometimes it's actively harmful, but it's still around because it's fit enough or whatever it is. But when it comes to the DNA level, it's not quite as wasteful as people initially thought with the junk DNA terminology.

Alex Miller:

Oh, there's a lot of junk code in my project, so analogy works in that case.

Samuel Arbesman:

There's something there. No, I definitely think when it comes to technology and computation and biology, the way in which code changes over time, I think there are definitely some interesting analogies there.

The other thing I wanted to ask you about, also related to doing this on your own time, is, how do you think about this, I wouldn't necessarily describe it as a hobby, because this is a very large practice and something you spend a lot of time on, but it's not your day job, at least. And I think there's a great deal of power of building generative art or playing with code in this way, outside of it being a profession like software engineering. This is a very different way of interacting with code. How do you think about this kind of activity, as play or as hobby or, I'm not sure what the right terminology is.

Alex Miller:

Yeah, really good question. I think art-making is fundamental to being human, and we all pursue it in our own ways. And sometimes it gets labeled as art, and sometimes it gets labeled as arts and crafts or whatever, there's all these weird tiers that we put onto it, which are totally meaningless. I think all humans express themselves through making things, and it's just part of how we understand the world and part of how we appreciate the world. So I think of generative art and coding-based art as just another form of that. We're using the tools that are available to us in our modern context to express things about the world that we find interesting, to explore and learn things about the world. Oftentimes when I'm creating these generative systems where I'm representing plants or when I'm representing these little amoebas, I'm thinking a lot about, how do plants actually work, and how do I get a branching structure that looks natural?

And maybe that gives me an intuition about how real plants work, and it gives me an appreciation... Well, the appreciation of how real plants work is already there. I already find natural beauty to be really important. This is how I express that appreciation. I think that what you said is really interesting, about the difference between coding up these little simulations for a hobby versus larger scale professional software development. These really feel separate to me. They feel very, very different. I think there's lots of professional programmers that might not actually have much interest in the smaller-scale tinkering of these simulations and stuff.

And the flip side is true too. There are lots of people who don't have the interest or don't have the education, or for whatever reason, just can't do the large-scale software engineering, but still can find a lot of joy and beauty in creating these smaller-scale systems. Yeah, I'm not sure if that answers your question, but I think basically it's just a human need to want to make and tinker.

Samuel Arbesman:

No, I love this. And certainly, I mean, most of my programming experience definitely leans much more towards the tinkering, little experimental stuff rather than anything formal. The most coding I've done that's more professional has been in the realm of science, and you don't want to see the code written by scientists. It's always going to be a mess. But related to that though, I wonder, I mean, in the same way that people have developed tools or training and courses for making it easier for people to learn how to paint or to draw or all these different things, do you think there's a need for almost finding ways of democratizing this kind of coding creation, whether it's new types of software or new programming languages? It seems like there's this whole, and I wouldn't say untapped market, because I think there's actually a lot of people playing in this space already, but so how do you think about this space of people who are trying to democratize this, either through better tools or courses or training?

Alex Miller:

There's a very, very small group of people that are interested in this problem. It's crazy, it's just a handful of people that I feel like lead the market in terms of tools for this sort of tinkering. So for example, there's an open-source project called Processing, and a sister project called P5.js. These are these coding frameworks that you can use to create generative art, and they're used by millions of people. They're really useful for education. One of the big use cases in terms of having these sorts of tool sets available is just in teaching programming. Because if you have this visual feedback as you're learning to code, it's a lot more concrete. It's just a lot more fun, basically. It just makes programming more fun.

So I think yes, it is very, very important to democratize this sort of thing and make tools like this more available. And I think it is insane how vastly under invested in and underfunded the Processing Foundation is one of the only larger players in this space, and they're not very big. And of course there's other ones too, but I would totally agree that this is a really important thing for us to pursue, just in terms of enrichment of humanity.

Samuel Arbesman:

Well, and I also think, going back to what you're saying of how, in the process of doing this kind of thing, you learned a little bit more about nature and get you excited about understanding plants or whatever it was. Every now and then I go down the rabbit hole of, so coding train.

Alex Miller:

Love coding train.

Samuel Arbesman:

That's one of these resources, and it's amazing, and every now and then, I'll go down the rabbit hole and just watch a whole bunch of his videos. And well, one, you also just get to see how he thinks, which is amazing. But in addition, you also just learn about a lot of topics in the process of learning how these things are actually built step by step. And there's this amazing closed loop there of learning how to code, learning how to build these things, learning how to think about the world differently, and then that in turn can inform how you continue to think about coding. And yeah, there's something really powerful there about democratizing all these kinds of things.

Alex Miller:

Yeah. There's a famous quote that I think might be misattributed to the computer scientist, Donald Knuth. I'm not sure if he actually said this, but the quote goes something like, "Computer science is to computers science as astronomy is to telescopes." So the idea is that if you're an astronomer, you're certainly very interested in how a telescope works. And of course I'm sure there are telescope technicians who that is their job. But the point of the practice is not the telescope, the point is what you're seeing through the telescope and what you're learning using this tool. And I really like that quote because I feel the same way in terms of this tinkering generative art thing we're talking about where you are creating these pieces using code, and the point is maybe not even the code itself, it's just learning about computation as a general thing and getting a taste for it and playing with it.

As I said before, I think computation is a fundamental building block of the universe. This is just part of the fabric of the place in where we live. And so getting to tinker with this little "telescope" and see that foundational quality is really, I think it's important.

Samuel Arbesman:

Maybe this is actually a fun way to segue, related to the idea of democratization. You also teach a course about algorithmic botany, using algorithms to generate plant-like shapes, but also presumably to understand plant biology even better. Yeah, I'd love to hear a little bit more about that course and how you teach it.

Alex Miller:

So algorithmic botany is a very rich and sophisticated field, and this is something that people do their life's work in. So I got to be careful because I don't want to represent myself as an expert in any way. Teaching this course was really more about having something to focus on in terms of building these generative systems. So the course was designed for a wide range of folks with different types of programming experience. In other words, you could take this course without having coded at all. So we're not building super realistic simulations of plants to understand the fine details of biological mechanisms. Really, we're just using plants as a subject to do still-lifes on. This is the thing that we're trying to represent.

Samuel Arbesman:

Oh, interesting.

Alex Miller:

And botany lends itself very well to simulation because there are some very-well-known and relatively easy-to-understand algorithms for representing plants. There's one in particular called an L-system, and this is a very, very well-studied system, and it's great for beginner programmers because it gives them a taste of what computation is and how to code such a thing. But it's also really good for folks that have more experience because you can get really sophisticated with it, and there's no ceiling on the types of things you can build using an L-system.

So a big part of the class was basically just learning how to write one of these L-systems, and how to use it to generate these virtual trees. I will say I feel bad about the fact that I'm not an algorithmic botanist, and yet I taught a class on it, because I feel like a true algorithmic botanist would've a lot more to say on it.

Samuel Arbesman:

Well, going back to what we're talking about the democratization, I think there is a great deal of power in getting people to appreciate something within the intersection of computation and science and art that they didn't even understand. And so the target audience for the course, are these people who have programmed before, have they programmed a little bit but they're not familiar with this, and how do they receive these kinds of ideas?

Alex Miller:

Huge range of experience. Some folks came in having already programmed an L-system specifically. I gave a poll at the beginning of the class because I was curious. So a few people came in and they were like, they maybe could have taught the class. A few people came in and had never programmed before at all. And then there was everything in between. And I like to think that the class served everyone in different ways. It's hard to teach a class to such a range of experiences, but I think for the folks that were brand new to it, this was a good context in which to start playing around with code. Because I think a lot of times in a computer science class, that connection between programming code and nature is just, you don't even discuss that. Whereas I believe that they're so fundamentally interlinked, and that when you're coding something, you are interacting with a natural system, just very directly. And so I think being able to emphasize that for beginner programmers, it makes it more interesting than doing something like building a calculator, for example.

Samuel Arbesman:

I think there's also something there to show that computers and computation, they have applications to areas that feel on the surface very different from things that might feel very computer-like. So like you mentioned a calculator. Calculators feel very computery, because it's just arithmetic. But life and plants and biology, that sounds like a totally different realm. But showing that there are these ways to deeply connect them and provide insight, it can be one of those interesting aha moments for people.

Alex Miller:

Definitely. Definitely. Just a very short tangent that I wanted to mention that just came to mind is a connection to AI. And I promise I don't want to talk about AI too much, because everybody wants to talk about that these days, but modern AI systems that are based on neural networks, these neural network systems are exactly in the category of things we're talking about in terms of emergent systems. These are systems that are made up of lots of little parts that all do something on a local level that's pretty simple, but then when you scale them up to a big system, they do something really interesting and emergent.

And so I actually think that getting your hands on emergent systems like a simulation of birds flocking, or a cellular automaton, which we haven't talked about, but that's a grid-based simulation that has lots of interesting emergent properties, getting your hands on these things might allow you to build a little bit of an intuition for how neural networks work, which is the thing that now rules our culture and our society.

Samuel Arbesman:

I like that. And maybe that's a good segue into cellular automata and the idea of grids and graphs, because I know you wrote this wonderful essay. It was an interactive essay.

Alex Miller:

I called it "lightly interactive," the tagline I gave it.

Samuel Arbesman:

Yeah, you wrote this amazing lightly interactive essay around grids and graph paper, and then there's also this idea of the cellular automaton, which is this very simple computational substrate upon which you can do lots of different things. I don't know if you want to talk about all the different things you think about related to that.

Alex Miller:

Oh yeah. I love grids. I love talking about grids. So this essay that I wrote was inspired by a memory that I had. As a child, my dad would play this game with me where you would take me outside and we'd get a piece of graph paper and we would draw the backyard of our house, but we would pretend that it was an island, and we would pretend that it was this magical place where there were hidden treasures. And then we would label the different points of interest of our imaginary island on this map that we had drawn on graph paper, and very specifically, the way that we would label points of interest is that he showed me, if you put letters down the rows of the graph paper, A, B, C, D, E, F, G, you put numbers on the columns, 1, 2, 3, 4, 5, 6, then you can address specific points on your graph paper using a coordinate system. So you can say the secret treasure is buried at A3, and that corresponds to a cell on your graph paper.

I was totally enamored with this when I was a kid for some reason. It just felt so magical to me for a bunch of different reasons. And in this essay, I explore, why was that so interesting to me as a kid? And then I also explore other ways in which graph paper is important to our culture, to our technology to our way of thinking. So after playing this game with my dad and getting obsessed with graph paper, I started to just want to draw on graph paper all the time. I would draw these little mazes and stuff. Everybody thought, "Oh, Alex loves mazes for some reason." I didn't actually really care that much about mazes, I just liked drawing on graph paper.

It's soothing because the graph paper gives you this structure, like a lattice structure that you can kind of draw upon. And in the essay, I say this idea that it does some of the work for you. Also, using graph paper, I felt like I was being a grownup. And I think that graph paper is this ubiquitous foundational thing that you find in so many grown-up practices. Like for example, engineers use graph paper, and designers use graph paper, and weavers use graph paper. It's a technology that underpins so many technological and artistic practices of modern humans.

One experience that I had with graph paper that I wove into the story was going to see a notebook that was owned by the designer Susan Kare, who's a famous early Apple employee. She helped define the interface for the Macintosh, she designed all of the icons and fonts for the Macintosh, and this notebook has some of her original sketches for some of the iconography that was used for the Macintosh. You think about the early computers, they're very low resolution, you don't have a lot of pixels to work with in order to draw user interface elements. So she went and grabbed this graph paper notebook and just filled in the cells of the graph paper to sketch out, how would I draw a paintbrush to represent a painting tool on the Mac?

So this notebook was being displayed at the Museum of Modern Art in New York, and I went to see it, and had this moment with it where I remembered these games that I would play with my dad as a kid, and I thought a lot about all these other places that I'd seen graph paper used, and it was this validating experience where I was like, "Oh, my own interest with graph paper is not some sort of personal quirk. This is a universal thing." The moment is showing this because it is interesting to see behind the curtain of how this piece of technology was made. Graph papers are a peek behind the curtain. They're often used in the planning stages. What makes them so interesting is that they're part of the story of how things get made.

Samuel Arbesman:

I love that. I want to talk about cellular automata, before that, because you mentioned early Macintosh. In your piece, you also talk about one of the seminal early pieces of Macintosh software of HyperCard, which I think also, in your mind, is connected to graph paper, and from my perspective, and HyperCard was also an on-ramp for me to actually learn about programming and coding because it had, and we talked about high ceilings, it also had very low floors. It created this easy way of authoring and doing certain things, but under the hood, there were some powerful ways of making buttons and an entire language. What was your experience with HyperCard?

Alex Miller:

I also learned how to program using HyperCard for the first time. I was very young. I think I was maybe like six years old. So when I say learning to code-

Samuel Arbesman:

Oh, wow.

Alex Miller:

... I'm using that very loosely. I was not some sort of coding prodigy.

Samuel Arbesman:

That's so amazing that you were using HyperCard that young. That's awesome.

Alex Miller:

I remember asking my dad how to compare if one number was bigger than another, and he told me, "Oh, you would use the "greater than" sign." And then I remember I kept forgetting that I had to use the greater than sign, or I forgot how to type it on the computer, so I kept having to ask, "What was that thing that you said I can compare two number?". Anyway. So yeah, that was my very early exposure to programming. That's where I first understood that computers were programmable. That's a really interesting idea when you're a kid, you don't actually necessarily understand that at the beginning. They just are there in front of you and they work. You don't think about how the things get made that run on them.

So getting back to what you were talking about, about democratization, I think HyperCard was this incredible example of democratization of technology, because it was very accessible, very easy to use. Lots of people got their start using HyperCard, and then, like myself, went on to study programming in the future. And it does feel like we're missing HyperCard in the current moment. I don't know what the equivalent to HyperCard is. Websites have a lot of similarities to HyperCard because you can link pages together. In HyperCard, you could link cards together, that was the primary mechanism in HyperCard. But websites are really hard to build. So I don't know, it's an open question for me, what is the current-day HyperCard? Please, somebody should build it.

Samuel Arbesman:

And I believe people and companies are trying to do these kinds of things, at least coming at it from different angles. But I agree, HyperCard in its time really captured something special, and was really this on-ramp allowing people to do things. And I believe the creator of HyperCard, Bill Atkinson, later regretted not putting it on some sort of online equivalent. If there had been a internet version of HyperCard, that would've made things much easier for people to author websites and things like that, if I'm remembering this correctly.

But it's interesting when you're talking about that HyperCard allowed you to see that software was something that could be created. It wasn't just a thing, it's a given. And so for me, one of my early computing experiences in addition to HyperCard, but before that, was my family's first computer was the Commodore VIC-20, and so, in addition to buying software, you would also type basic programs in. And I remember, well before I knew how to code, I was sitting in my father's lap as he was entering code in from some magazine. That also made me understand the relationship between code and what happened on the screen. And sometimes there were crazy bugs, and that also made you realize, "Oh, it's this very interesting medium." And also related to HyperCard, and also seeing that software was this thing that was creatable, not just given to you. I imagine you also saw that, and you mentioned your father multiple times, but he was also very much in building software himself. So did you see that as well and have those kinds of experiences? I don't know if you want to talk about that.

Alex Miller:

Yeah. So my dad was one of the creators of the computer game Myst, which, I mentioned this in the essay. If you say that fact to somebody that is like 35 or younger, the chances that they will be excited diminish as you get younger and younger. So it definitely was very, very popular for a time. And some people that I mentioned this to freak out.

Samuel Arbesman:

For the readers who cannot see me, I have a giant smile on my face. I'm well aware of it. And actually, you and I have discussed how I played Myst, but for me, one of my more formative game experiences was another game that your father was involved in called Cosmic Osmo, which was sort of Myst, but earlier and geared towards little kids. And so it was this point-and-click sort of exploration of a very cartoony world. And it was amazing and mind-blowing. And I can remember playing Cosmic Osmo, sharing it with my father, with my brother. It was amazing.

Alex Miller:

I love that you played Cosmic Osmo, because that was also my favorite game when I was a kid. I think I was too young for Myst, so I just didn't really understand it. I mean, I knew that my dad had worked on this game, and I understood that it was popular, but it just went over my head. I didn't really care until I was a little bit older and could actually play it and enjoy it. Whereas Cosmic Osmo, I totally understood that because it was made for kids, and I played Cosmic Osmo all the time. I was obsessed with it. And I think that that connection with HyperCard and understanding that things are programmed, understanding where software comes from, was very linked with my experience of playing Cosmic Osmo that my dad had made. Because Cosmic Osmo was made using HyperCard, and so then when my dad showed me HyperCard, he told me, "This is how we made this game that you like. Here, you can make your own game with it." And that connection for me, I think was this really important connection to make when I was young.

Samuel Arbesman:

Oh, that's so powerful.

Alex Miller:

Similar to you seeing your dad typing in the code and forming this connection between code and something that you see on screen is really interesting.

Samuel Arbesman:

Oh, I love the forming that connection, but also the fact that you knew it wasn't just that, the HyperCard wasn't just this thing for little kids as an on-ramp to coding. You could actually build real things. The fact that your father was involved in building a real piece of software that my family had, that is very legit. And so thinking about the need for greater democratization, being able to peek under the hood, see all these relationships to art and code, and allowing people to do this more easily, that might be a perfect place to end. It feels very satisfying. So thank you so much for taking the time to chat, Alex. I really, really appreciate it.

Alex Miller:

Yeah, thank you so much, Sam. I enjoyed it.

‍