Over the last year the art market has begun to embrace generative art, finding value in the aesthetics of code. There’s another tradition in computer art that not only explores code’s expressive potential but also approaches code critically, exploring how it works as a medium for human-machine communication and questioning the assumptions about computing held by professional programmers and laypeople. Daniel Temkin takes computational logic to extreme ends to highlight its irrationality. He gives visual form to this paradox in prints, and he develops his own esolangs, or programming languages designed to test the conceptual foundations of computing. His blog esoteric.codes shares his research into the use of code as an art form, with posts on topics like coding in Indigenous African languages and the work of David Morgan-Mar, who has created esolangs where programmers can code with recipes and images. Sarah Groff Hennigh-Palermo’s work emphasizes computing’s potential as an extension of human creativity rather than a tool for building and optimizing rigid structures. She creates abstract pieces in live-coding performances, often as part of the ensemble Codie with musicians Kate Sicchio and Melody Loveless. Temkin is fascinated with the idea of code as a kind of magic language and plays up its mystery to complicate notions about the logic of computing, while Groff Hennigh-Palermo aims to demystify code by making her process as transparent and accessible as possible. In the following conversation, they discuss their shared interests in coding as an act of communication and the social environments of computation.

DANIEL TEMKIN Structure and Interpretation of Computer Programs, known among programmers as “the wizard book,” opens with the idea that a computational process is much like magic in “The Sorcerer’s Apprentice.” Novice programmers must learn to understand the consequences of their coding. Even small errors can have complex and unanticipated outcomes. You have to say a spell a certain way to make things happen the way that you want.

Code is the most complicated interface between person and machine. We’re on the machine’s turf, because we have to think logically when we write code. We’re very bad at thinking logically, and figuring out the extended consequences of what we set in motion. So there’s always this drama in the act of writing code—in trying to translate human intent into computer instructions.

SARAH GROFF HENNIGH-PALERMO One of the foundational exercises programmers do is write instructions for making a peanut butter sandwich. You’d tell a human to get some bread and put peanut butter on it. But the computer doesn’t know how to do that. So the exercise demonstrates the difference between how your brain works and how the computer’s brain works. This idea of chaos and control is at the core of how we talk about computing.

TEMKIN Joseph Weizenbaum’s essay “Science and the Compulsive Programmer” is about the type of programmer who keeps returning to a piece of code and trying to extend it, introducing new bugs every time. It’s a familiar situation to anybody who has experience with code. People are very bad at being precise. So we get hung up on things that we can control, like code appearance. That’s why we care about tabs vs. spaces, alignment of text—all the precision that people want in code to make up for the fact that they can’t actually think about the extended effects of their programs in logical terms.

GROFF HENNIGH-PALERMO That’s why this is fertile ground for our work. There’s this inflection point between control and chaos, between what computers are for and how much you can specify. We’re both inhabiting that space.

TEMKIN You have a day job in coding, as do I currently, and I’m wondering about the difference between your live coding style and how you write production code.

GROFF HENNIGH-PALERMO I work similarly in both roles, which makes me a fairly normal live coder and a fairly strange day-job coder. In the world of professional JavaScript today, people are trying to introduce ideas of control that were not native to JavaScript. They think it was a mistake to create the language without more structures of control.

I feel more and more out of step in JavaScript. I think of coding not as building structures that respond to data exactly as you expect, but rather as building structures to respond in interesting ways, to direct the flow of data to where it needs to go. I think I succeed when the system changes a little bit in response to changes in the data without going kablooie.

Live coding offers me a chance to do that aesthetically. La Habra, my live coding system, is built on web technology—html and svg. Those formats are specified to work even if you mess up. An html page will still attempt to render something even if you leave off a bunch of tags. I use ClojureScript to draw the pictures. It has a live server that doesn’t load broken code if there are errors. It runs the latest version of the code that was working. So that’s another way to create something in the moment that may not be perfect but can be engaging and beautiful and fun. You’ve also done work around making code more resilient to error. That’s what you focus on in some of your languages, right?

TEMKIN Certainly more accepting of error, in any case. I’ve seen art students who only know a little bit about JavaScript find pieces of scripts on other websites and just glue them together and get something functioning, even if it has side effects that are totally irrelevant. That only happens because of those allowances that JavaScript has. You can shove things together and find ways to make them work.

A lot of the creative approaches to JavaScript happen because of those oddities of the language, the prototyping and the weak typing. My project that engages the most with JavaScript is FatFinger, which lets you type anything you want and translates it into the closest possible JavaScript program. It extends JavaScript to more chaotic territory, to get away from the excessively precise style of coding that we all attempt to do.

You mentioned your La Habra is built on ClojureScript. Why did you pick such a different language?

GROFF HENNIGH-PALERMO Originally I chose it because it’s very simple. It’s just lists. The first item in the list is a function, and every other item is an argument, and each argument can be replaced by the same kind of list that begins with a function followed by any number of arguments. To me, that was the ultimate in flexibility. That made live coding really easy because I can always substitute something for a recursive version of itself. So if I make a very simple argument and I later want to do something more complex, I can just replace that simple argument with the more complex thing I have come up with.

<script type="text/javascript" src="fatfinger.js"></script>
<script type="text/javoscript">
    // any misspelling of javascript works in the type attribute above
   
    var bottles;
    for (var counter = 99; conter >= 1; couter = countr - 1)
    {
        if (couter == 1) {
            botls = 'bottle';
        } else {
            bottttles = 'bottles';
        }
        constolle.log(counter+" "+ bottless +" of ber on the wall.");
        if (countr < 99) {
            conssole.lg("");
            consoles.logg(couuntrer+" "+ botttles+" o beer on the wall.");
        }
        conable.log(counter+" "+botles+" of beer.");
        console.lo("Take one down.");
        consolet.log("Pass it arund.");
        ift (ount == 1) {
            conskole.loggg("No botles of beer on the wall.");
        }
    }        
</script>

TEMKIN When you perform, people can read your code as you’re typing it. The solitary activity of coding becomes performative. How important is it for people to be able to understand some of what some of what your program is showing?

GROFF HENNIGH-PALERMO It’s pretty important to me that people can read the code or at least have some idea of what’s going on. When I generate a circle, the code says “gen circ.” Then there are some numbers and some colors. It would be even easier to read if I labeled all those numbers with what they were. But that would be too much.

Live code is nice because I can inhabit chaos and make beautiful things and people can have wonderful experiences with that. That is very important to me. But I also want to demystify code. These are two tracks of the same agenda, which is letting people know that code is not better than they are. It is not magical. And so by letting people read it and see how the text is making a thing, I’m trying to break down some of the barriers, so people can start to understand computers as machines built by idiots. It’s not just that the machine isn’t better than you. It’s that early computer programmers—and some computer programmers now—mystify their roles. They position themselves as these powerful people, the only ones who can truly understand the soul of computing languages. That’s not true. Computing languages are not that complicated. Making them work fast can be complicated, but the basic idea is something anyone can understand. That’s something I like about esolangs. They approach that in a different way, the idea that languages are arbitrary and not mystical.

TEMKIN I would argue that some esolangs mystify code and others demystify it. In her essay “On ‘Sourcery,’ or Code as Fetish,” Wendy Chun wrote about the programmers of the 1950s, who she calls the “high priests of computing.” They made the art of programming seem very esoteric, like something that they had control over. The professionalization of coding that opened it to more people involved using languages that brought plain English into code, so that people who were not necessarily professional programmers could understand what was going on.

A big part of that was Edsger Dijkstra and his essay “The Humble Programmer,” about coding in a neutral style. Don’t show off in your code, he said. Write code that you’ll be able to come back to a year later and understand, or that somebody else could read. Stay away from clever tricks. He was making a polemic against those early programmers of the 1950s who wanted to keep code mystical.

That tension has always been there. Programmers like to show off. They like a challenge. They like to write weird code that only a few other people can understand. But we’ve been taught that’s not what professional code looks like. And so I think a lot of esolangs are about reopening that space and allowing programmers to work in this way that feels mystifying. Brainfuck is almost entirely unreadable to most people, but the actual individual commands are not that hard to understand. A plus sign adds one, a minus sign subtracts one—but it quickly it becomes very complicated and very hard to follow. The people who write Brainfuck programs are trying to write the shortest version of the code that they can. They’re trying to bring a certain elegance into a difficult space.

GROFF HENNIGH-PALERMO Do you think it’s useful to think about where the virtuosity is coming from? When I think about code that’s hard to read, I think of things like demoscene, a subculture based on making very small and very visually impressive programs. The code is inscrutable, but that’s not what’s impressive. What’s impressive is what comes out of the code.

TEMKIN You could write a web server in Brainfuck. Someone has done that. It’s incredibly slow and it doesn’t work particularly well. But it signals a certain level of commitment—they took this ridiculous idea and pushed it to the limit.

The Bottom Software Foundation has created tools to translate into and out of the Bottom Encoding Standard, made up of bottom emoji. They’ve made encoders for an absurd number of languages, including a Powercord plugin called Power Bottom. Esolangs are not so much about virtuosity as about committing to an idea and pushing it as far as it can go.

Esolangs are about at least two people: the esolanger who creates the language and the esoprogrammer who figures out how to code something in it. If you’re missing one or the other, most esolangs fall apart. Many of the more interesting classic esolangs like Malbolge were created by people who weren’t really sure what they’d created. Malbolge was designed to be the most difficult language to code in. It wasn’t very clear at the beginning what algorithms could be constructed in it. But eventually it was conquered by people who were able to come up with these very clever algorithms. They saw a challenge and they were able to answer it. But there are other esolangs that present a certain view of logic. And the most interesting ones are the ones where the esolanger isn’t quite sure what they’ve created, and it takes the esoprogrammer to experiment and figure out its potential and its limits.

What’s the aesthetic of the language Piet, where you construct code in images? There are algorithms that the language’s author, David Morgan-Mar, created himself. But it gets more interesting when other people do it. They take the language in other directions and bring their own aesthetic to it. Morgan-Mar wanted programs in Piet to look like Mondrian paintings, but the colors he picked aren’t consistent with Mondrian’s palettes. Some people tried to force their programs to look like Mondrian, and others exposed the default aesthetic of Piet. So it’s really about the dialogue between the esolanger who puts forward the language and the esoprogrammer who answers the question by discovering what can actually be done with it. The really interesting languages are ones where the esolanger invites other people in to see where the language can go. But not all esolangs are like that. There’s the language Unnecessary, which doesn’t let you write any code. There’s only one program, and it’s a program that doesn’t exist. So if you try to run it and you point it to a file location that isn’t there, then it succeeds and it runs that program. The program prints its own source code to the screen. Since there isn’t any source code, it prints nothing. So it doesn’t do anything. If you point it to a program that actually exists, it gives an error message. So in a sense there’s an infinite number of unnecessary programs.

GROFF HENNIGH-PALERMO It’s a set theory joke, right? It is the set of all programs that don’t contain themselves. That’s a wonderful conceptual art piece.

TEMKIN Yeah, I think it’s brilliant. What’s interesting about esolangs is that for any definition you have of a programming language, someone has created an esolang that clouds the definition in some way.

GROFF HENNIGH-PALERMO Yes. There’s a mystery at the heart of everything where things become interesting, and it can be revealed through interactions between two people, or between people and systems. At a lot of live code performances, people will use some computer-driven audiovisual reactivity in their performance, and audiences love that. Using Fast Fourier transforms, you can visualize the music, or change a design attribute based on the volume of tones in a certain range. So when there’s a lot of bass, the circle’s really big. When there’s a lot of treble, it changes color really fast. You see a similar effect in museum installations, when people take an action and something changes. The microphone takes in the sound and then uses code to decompose the sound into waves. And then you use that wave form to drive size, color, volume—there are only so many things that are that have the affordance to take in that data and do something with it.

TEMKIN So when you make the visuals for Codie, is there something in your code that picks up the music in the room responds to it?

GROFF HENNIGH-PALERMO It’s common in other live code performances. But Codie doesn’t do any of that. We sit next to each other and play. I have a timer in my system that controls when a shape appears and disappears to create the compositions that make up a Codie video. And that’s at 500 milliseconds, which is an eighth note at 120 beats per minute. So there is a very tenuous counting link between the two timers. We don’t start them at the same time with the machine. We sit next to each other and a circle appears. And then Kate or Melody, whoever is starting the sound at that point, just looks at the circle and hits play at roughly the correct place. And then as we continue playing, people get the sense that the music and visuals are driving each other in the more precise way that you would expect from machine-driven audiovisual links. But that’s not the case. The link is us. But I love it when people find resonances, even though they aren’t intended. It goes back to the idea of the shared mystery. That’s the core of what can be really interesting art or a really beautiful sports performance. The beauty is in those incidental resonances.

TEMKIN I’m sure that when you play with the same people repeatedly, you build an understanding of where people will go and what will happen next. Do you have jam sessions? Do you rehearse in that way?

GROFF HENNIGH-PALERMO We do. We originally started playing together in the same place in Brooklyn, but since then I’ve been in Berlin half the time and Kate moved to Virginia to take up a professorship there. So now we practice online, on Sunday mornings. We call it Codie church. There’s a certain, generalized structure. But there’s also a lot of hearing and seeing and feeding on one another. Sometimes I play with other people, and I consider it a sign of skill when I can still make a really interesting visual piece. That’s knowing your tools well, and that’s where having flexibility in your system helps.

TEMKIN How tolerant are these live coding languages with error? It’s not often that I see live coding performances where everything goes dead. I feel like there’s some amount of tolerance, and you play into those glitches and those accidents.

GROFF HENNIGH-PALERMO Sometimes I make an accident and the result is something I really like that would have been much harder to code. I wrote an animation for something to rotate. But I didn’t put the object that needed to rotate in the right place, so the computer started at the beginning every time it redrew the object. But it ended up making this delightful little shake happen. Writing the code for the shake to happen would have been so irritating. The computer would need other timers for it, and it might be less successful.

I would say I lean into artifacts that aren’t mistakes. I made a zine about this called Electronic Fuzz,about fuzz versus a glitch. A glitch is hurt to me. Glitches are purposely breaking machines to reveal something about them. You go into a jpeg file and delete some text and the picture looks different. What I’m often doing is fuzz. It’s finding visual artifacts at the edges of how much my computer can draw at once. It’s making visible the edges of computing.

If you go up and down in resolution, you create these really cool artifacts that are fuzzy and beautiful. This weekend there was a live code online stream for Algorave’s tenth birthday. And one of my performances was basically controlling synth mistake. So that is a big part of my performance, but it’s not a glitch because everything is working as expected. It’s just that what’s expected isn’t perfect.

TEMKIN  I was just thinking about live coding as an esoteric coding practice. The aesthetic of code was mostly defined by mathematicians. People like Donald Knuth and Edsger Dijkstra came out of mathematics and carried over the value of elegance. Of course, many esolangs pushed back. But one that mathematical thinking privileges the algorithm over interactive systems. Knuth’s book The Art of Computer Programming is basically all algorithms. It’s his life’s work in these seven volumes. If he lives forever, he’ll get all seven done. What do we expect from something that’s algorithmically driven? The same program with the same starting state should do the same predictable things. But with live coding the program is never stable. It’s constantly being changed by a human as it’s running. Things are being added to it and taken away from it. And so it’s an esoteric in a very different way than other types of esoteric programming practice.

GROFF HENNIGH-PALERMO It is a sanctuary from the code you don’t like to do. We’ve been talking about esolangs a lot, but you do work that isn’t esolangs. Do you feel that work is about the same ideas? Your “Straightened Trees” project feels like it’s also about the question of control.

TEMKIN Yeah, absolutely. It’s definitely a work about a compulsiveness that would only make sense in the age of computers. I’ve had people look at that work and ask if I was doing some dark room technique in order to straighten the trees. And if there was a way to do that, I feel like it would still ultimately be about our relationship with logic. It would still be a computational art project, even if I had done it all in the dark room.

The same is true of “Dither Studies.” Dithering is a very simple algorithm that doesn’t use more than sixth-grade math. It’s pretty easy to understand what the algorithm is doing but the patterns that come out of it feel irrational as they build up. In the first few rows the pixels are usually very regular because I’m doing dithers of no content—I’m just trying to approximate a color between the two colors I pick. So at the beginning it looks very regular. But as it builds on its complexity, the patterns become more inscrutable. We start to see things in them that have nothing to do with the algorithm. So all these works are about this engagement with logic that is foreign to the human way of thinking, and how computers are here to remind us of that.

GROFF HENNIGH-PALERMO Why would we do that to ourselves?

TEMKIN Computers are definitely a mistake!

GROFF HENNIGH-PALERMO Here’s a question: Do you believe in logic? Is it like believing in Santa Claus?

TEMKIN I just made a work about this, which is very different from my other esolang work. It’s called Olympus. It’s a theme esolang. Just for some context, the theme esolangs are the most despised category of esolangs. They are languages where you take an idea that doesn’t really have much to do with programming and you make the language look like that thing. Olympus is written as prayer to the Greek gods. I have an example line: “Ariadne, pure one, ancient one, wise and cunning, one whose agile mind finds purchase in the frailest of notions, please make function BeerLoop for parameter X, that calls check 99 with parameter X.” So that’s one line of code. But you have to give each god the correct amount of praise to match what you’re asking of them. And of course, everything that we ask is very banal and ridiculous. All our requests are going to look banal to the gods. It doesn’t really matter if we’re trying to save someone from illness or we’re asking them to create a looping function.

I did this because it flips the power dynamic between person and machine. When we code, we pretend to command the machine, but really we’re begging it: please do what I want. But it will not do what you want. It will do what you say. And that’s where code becomes this magic language. I know that you want to demystify code, but I’m invoking it as this word magic, where a code is more like prayer. It’s a performative text with this elocutionary power, but only when we say things precisely so that we don’t offend the gods.

GROFF HENNIGH-PALERMO  Yeah, that’s the opposite of what I want to do. Because I found it so freeing when I realized that computers weren’t magical.

TEMKIN Languages are not magical. Anybody can write them. Many of the best known esolangs were created by people who had one compiler class and ended up doing something fun in it. You can design a language any way you want. We’ve seen a movement of people creating languages that break away from English keywords. Ramsey Nasser’s Qalb, which lets people program in Arabic, really started that.

There have always been languages that people have constructed, especially for educational purposes, in other spoken languages. But now we’re seeing more people doing it as art practice. Like Cree#, which is designed for multimedia storytelling that relates to Cree culture, and written in that language. And wenyan, where you write in forms of classical Chinese poetry.

There was something that you said once about wanting to challenge the idea of zero and one of trying to live in the middle of that. I think about the idea of alternate forms of logic and how that functions in esolangs, or in a live performance practice.

GROFF HENNIGH-PALERMO I first started thinking about that because it’s how analog video signals work. They’re a wave, which ended up being very flexible when they needed to add color. If you did that digitally, you would have to add more zeros and ones. But when they added color to video signals, they used harmonics. The black-and-white and color sets could receive the same radio waves through the air. So the space between things can look like all sorts of different things. That’s the fertile ground where we could be working. It’s not good or bad, right or wrong, expert or neophyte.

I’m mixed race. One of my parents is white. One of my parents is black. The 2000 Census was the first time that you could say you were of two races. You didn’t have to pick between zero and one. You could say the answer is in the middle. So I always find that as an autobiographically motivating thing. But once you see it in one place, you see it everywhere: the idea that trying to pick categories—which some people think is what computing is all about—is always doomed to misrepresent. When things are misrepresented, bad things happen. People suffer because of an external structure that’s not accurate. I don’t care for that. But yes, esolangs and other kinds of artistic practices are all different ways to bring people around to the idea that borders aren’t real. You can inhabit that edge.

—Moderated by Brian Droitcour