In this episode of the Arts Management and Technology Lab, Daniel Temkin and Luna Lu discussed the artistic possibilities of code, focusing on esoteric programming languages (esolangs) and how they can function as a medium for art and human expression. Temkin explained that his interest began with experimenting in existing esolangs (like Brainfuck) around 2007-2008, leading him to create his own and document them conceptually, moving away from overly technical documentation. The conversation highlighted how giving up on the idea that programming must be practical allows for artistic exploration, connecting esolangs to idea art, constraint-based work (such as the Oulipo Group), and performance art. Temkin detailed the structure of his book, which presents programming languages as idea-based art, containing both realized works and conceptual prompts inspired by artists like Yoko Ono, and described how his languages — such as Fat Finger, which inspired code poetry, and Folders, which manipulates file system hierarchy — explore themes of collaboration, human irrationality, and the extreme constraints of logical systems. Listeners were also encouraged to explore existing esolangs on the Esolang Wiki before trying to design their own.
Show Notes
Transcript
Daniel Temkin
So the basic sort of idea behind this book was exploring those extremes of how far can we go with this? If we give up on the idea that programming has to be practical, what are sort of the artistic possibilities within that space?
Dr. Brett Crawford
Welcome to another interview episode of Tech in the Arts, the podcast series of the Arts Management and Technology Lab at Carnegie Mellon University.
My name is Brett Crawford and I'm the executive director and publisher for the Arts Management and Technology Lab. And I'm pleased to welcome our technology manager and podcast engineer Luna Lu, who will be interviewing Daniel Temkin, an artist and the writer of Forty-Four Esolangs. Most recently, Daniel gave a talk at the Museum of the Moving Image in New York.
And his dither studies interactive installation is currently on view there as well. With that, I pass it on to Luna and I hope you enjoy the interview.
Luna Lu
Daniel, thank you so much for joining us today. I'm excited to talk with you about the collaborative possibilities of programming to show how code can be a medium for art, thoughts and human expressions.
So the best way to start is what really led you to esoteric language and begin interviewing other esolangers back in 2011.
Daniel Temkin
Yes, so I started making esoteric languages of my own around 2007, 2008. I really started by making programs in other esoteric languages and what I found about these languages online is that most of the documentation is very technical. And so I would read about a language and it would say, oh, this is a free tape Minsky machine, or, you know, or something like that, which doesn't give a lot of insight for people who, you know, don't understand those terms of what the experience is actually like of using the languages.
I started experimenting with esoteric languages in 2007 or 2008. Mostly writing code in existing esolangs, and I began creating esolangs of my own. But as I was experimenting with this, I found that most of the documentation online was very technical. So one of the best known slangs is a language called Brain Fuck.
Brain Fuck is written with eight punctuation signs. The amazing thing about Brain Fuck is that you can construct any algorithm in it that you could write in a language like c++, but it's really stripped down to the basics. Now, if you look up Brain Fuck on the esolang’s Wiki. It starts off the description with this is a machine that has 30,000 memory cells.
It has all these sort of technical details, but it doesn't really get across what the actual experience is of writing Brain Fuck, which is really that any algorithm that you write forces you to make all kinds of arbitrary decisions. There's no way in the language to write the number 72 directly because seven and two don't exist.
You have to move back and forth in memory in such a way that you can add to one memory cell 72 times to get to that number. And I found it's really fascinating that you had, you're forced to make these arbitrary decisions and it creates this space of personal expression within the language that normally isn't encouraged in mainstream code.
But I wanted to sort of capture more about the ideas behind these languages and get away from the technical descriptions, which I found sometimes hard to understand. For example, one of the more interesting languages was described as a three tape minsky machine. I didn't know what a Minsky machine was.
It doesn't really give me a place to sort of enter the thought process of that language. So as somebody who was new to esolanging, I began interviewing more experienced esolangers and really focusing the interviews on concept and influence of one language to another rather than the technical details, which tended to dominate the most esolang writing at the time.
Eventually this turned into the blog Esoteric codes. The interview started in 2011. I moved to that domain in 2014, and by that point I was sort of beginning to think of how to describe esolangs more generally. Classifying them more in terms of idea rather than the way that they're usually classified, which was in terms of the computational power of the language or other sort of more technical details and.
Then in 2014, I won the Arts Writers Grant, which brought a more of an academic and art audience to the blog. I continued to do interviews, but I expanded the blog to really become more of my own thoughts about these languages. The other thing about them is that most esolangers at the time didn't really think of their work in an art context, and it was important to me to think of them.
Not just esolangs, but how they're sort of in conversation with other things happening in computational art. So alongside pieces on esolangs themselves, I wrote pieces about other people who brought the expressiveness of natural language into code or other pieces where reading the text of code was important to understand the work.
So bringing in work by artists like Winnie Soon and Alison Parrish and others to create more conversation across these groups and really try to start building something more of a community of people who are interested in these ideas.
Luna Lu
Wow, that's amazing how your journey started purely with experimenting in other esoterical languages and then involved into creating your own.
And you mentioned that a lot of the early on documentation was really technical and hard to connect with. Do you think your background in photography and computational arts really helped you seeing this language differently in terms of their expressive possibilities compared to someone coming purely from a programming background?
Daniel Temkin
Yeah. Well, it's kinda interesting because I went to art school, having worked as a programmer for my day job for quite a while, and I really thought I would be working away from digital art during my MFA program. I mean, my program was in photography. And while I was doing this, I wasn't thinking of them yet in an art context because it felt like it was just sort of a different world.
But once I was in art school, I started to see connections to other idea art, and I started borrowing from techniques of how. People who did work around performance and writing scores for performance, presented their work. And so, you know, I had this moment where all of a sudden it was like, oh, these languages I've been making are actually art.
And they make sense in this context. There's this whole history of people making constraint based work and doing performance type work. I mean, it seems very obvious now, but at the time it was. I really thought of them as very separate domains. This book is really sort of a combination of the work I've been doing since 2009, which was when I completed my first language and presenting the work, more informed by how experimental writers like Oulipo Group presented their constraint based writing and also borrowing from conceptual art and some techniques from Fluxus, especially artists like Yoko Ono.
Who were sort of masters at creating these poetic prompts for work as the event scores. The key thing about code is that it's both a text and a performance. It's usually a performance carried out by a computer. That's how we usually think about it, but when we get into the esoteric category, we can look at it a little bit differently.
The programming language tells us what qualifies as code. It's the definition of the language that tells us what code should look like. Python code looks very different from C Code, so the language gives us what the text should be, but it also tells us what the performance of that code is. This is not tied directly to our computers.
When we write code in Python, we're not thinking about our specific machine. We don't need to know how many registers it has. We don't need to know those details because after all, if I'm writing code in Python, I want it to run on your computer as well as it runs on mine. So we're always speaking to an abstraction now with esoteric languages.
That abstraction moves a little bit away from our physical machine if we want it to, so we can rethink what is the executor of code, what is the computer, and what is the code itself. It could be music as language Zero is in my book. It could be a series of photographs. Or it could be something that has to be done live.
Like the final language in the book is code that you whistle to the computer. And so it moves entirely away from text as we ordinarily think of it. But then we can also think of the programming language as a set of constraints. There are some languages in this book where there's only one possible program to write within the language, so it really constraints what's possible to express within it.
And then we can think about performance itself. What can be performed in this language. And there are a few languages in here that are essentially impossible to code in. And then we can also think about things like intent. Normally we think of wanting to be very much in control of what happens when we write code, but there are a number of languages in this book that challenge, that intent, that force the programmer to give up some of that control.
Or there are several where they have no control over it at all, and the programming language becomes a way of recognizing a text not meant to be code that becomes code within that language. So the basic sort of idea behind this book was. Exploring those extremes of how far can we go with this? If we give up on the idea that programming has to be practical, what are sort of the artistic possibilities within that space?
Luna Lu
So your art school experience really did help you seeing the connections between code and performance, basically. Um, going back to your book, many of the esolang languages in your book are highly conceptual, you know, writing code as prayer to the Greek gods or typing tandem with another programmer. You talked about how esolangs are often collaborative.
Can you possibly explain how eso-programmers build on each other's work to create new discoveries? And I'm curious, was this your approach in designing these unique languages in your book?
Daniel Temkin
Yeah. So many esolangs are basically collaborative, right? If I create programming language, it's oftentimes meant for other people to use.
And this is different than writing code where it's the machine doing something that might be somewhat predictable because people are very unpredictable. And they bring their own ideas to the work. So one of my languages is called Fat Finger, and it's a dialect of JavaScript where you can spell things wrong and it'll find the closest thing in scope in terms of keystroke differences from what you wrote, whether that is a keyword in JavaScript or it's a variable that you've declared or something else.
So the way I pictured people using this is to. Write in a quick, sloppy way, and not using this to as a spell checker, but just leaving it sort of broken looking, but it'll still run and do basically what they want. You know, when I created this language, it was before ChatGPT, but I sort of like the idea that people could write JavaScript code in this and it'll to some extent poison these LLM systems by bringing in all kinds of sloppy JavaScript that won't work outside of fat finger.
But anyway, so it, for me, it was really about the compulsiveness of code and the way that we're always sort of checking ourselves and correcting ourselves and being like, okay, let, let's just write something quick and sloppy to see what happens. But what happened when I put this out in the world is that people found very different uses for it?
There is a computational poet, Jeremy Douglas, who teaches at UC Santa Barbara, and he found that instead of writing in this sloppy way, he would intentionally replace one word with another word. So instead of using the word navigator, he could use the word daughter. And it turns out that works because the number of keystrokes difference is closer to navigator than anything else.
And so he started writing code poems that would run as JavaScript but read as English, which I think is totally amazing and not something that I could have really have foreseen. Uh, he created a list of variations of JavaScript terms, which he called fat docs in response to fat finger to help people write their own code poetry within it.
And so that's what's really sort of exciting and rewarding about making some of these languages is when other people expand on it, find new uses for it, and discover the quirks of your language and its other potentials. This is something which reminds me of early net art when people would quickly post things online and people would post things in response kind of before the NFT times when nobody was making money on this stuff.
And it was a lot more sort of fun. It sort of brings me back to that era in some ways.
Luna Lu
That is so cool how even your work could possibly inspire new creations. And you mentioned how the culture of esoterical language has evolved over years. Especially as computational arts has gained recognition in galleries and museums, how would you describe what the culture looks like now?
What has changed in the way people think about these languages?
Daniel Temkin
That's an interesting question. So, you know, most people who make esolangs don't think of the work in an art context, and I think it's important to recognize that this is originally a hacker folk art, which was not written in response to anything the art world, but was really responding to the culture of programming.
The aesthetics of code, what I think of as the core aesthetic document for code is an essay by Dykstra written in the early seventies called the Humble Programmer, where before the era, like in the sixties, a lot of people would write sort of very small, clever programs. This was celebrated because computer cycles were expensive and any way you could make thigs a little bit more efficient was really valued.
But during that era, coding was really an esoteric art that belonged to a few people. And what happened is through the sixties and into the seventies, began to have more and more languages that were building on natural language. It did something to democratize code, uh, it made code available to more people.
It made it easier for more people to become involved. But what happened alongside that is democratizing always comes with it some de-skilling, right? Because it's making things easier. The sort of technical wizardry that was celebrated early on was last celebrated. And Dykstra’s document is really interesting because he's telling people it's no longer sort of appropriate to write code.
That is difficult to for other people to understand. You know, if you're coming back to this code a year later, you want to understand what it was you were trying to do. We have to sort of start thinking also in terms of larger projects. People become sort of more like corporate widget makers. So you know, I write some code and it needs to function with other people's code and so on, and becomes much more of a collaborative thing.
And so there was some pushback against that, but of course, people adopted early esoteric languages. Artificially create conditions that are like early coding. So I'm thinking here of languages like false brain, fuck on Lambda. These are very minimalist languages that have very tight constraints where you can't write clear code.
It's very difficult to write code that's readable in a language like on Lambda. It's a language that's described as write only, and it gives people a way to show off the technical wizardry that they're sort of not allowed to do in their day jobs anymore. And it's fun. It can be a little bit competitive. And so I think that sort of informs a lot of early aesthetics of esolangs. It's something that many of these esolangs build on. I'm not a technical wizard. I'm not somebody who was ever able to write code that way. That's not something that really interested me, but it's definitely part of that aesthetic.
But the other thing is that a programming language is a system, and programmers often turn systems in on themselves or finds unusual uses for them or find the extremes of how they can be used. So that's a big part of esolang aesthetics as well, and it's easy to see parallels between that. For example, I mentioned Oulipo, the writer, mathematicians based around Paris in the late fifties, who would create constraints for writing, like, write a novel without using the letter E is sort of the famous example by George Perk and other types of constrained writing.
Esolangs also explore constraints because many of the languages are built around these extreme constraints that create the conditions where you have to write code in these sort of very challenging environments. You get to some extremes. There is one of my favorite languages is a language called Unnecessary, where the only possible program that's valid in the language is a program that doesn't exist.
If you try to run it with any code, even with an empty file, that's considered not sufficiently unnecessary and it fails. But if you point it to a file that doesn't exist, then it prints those instructions of that code to the screen and it says, there are no instructions. That means it does nothing. It prints nothing.
So for me, that was a very inspiring language and I have many languages in this book that sort of build on those ideas. One of the languages in the book is called Captive. Captive is built directly on an idea that comes from Oulipo, which is called a prisoner's constraints. And in prisoner's constraint you're supposed to write text, avoiding any letters that have as senders of these senders that pass beyond the smallest letter, like an X.
So you can't use an L or a J or a Y. In Captive, those letters that half those descenders and descenders are the only ones that have any programmatic meaning. Everything else is ignored. But what happens with this language is that every text that is written in the Roman alphabet becomes code for this language, and it'll produce something as output.
So the vast majority of code written for Captive, of course, are programs that were not intended to be programs at all. And so the whole idea of having the intent of the programmer is completely lost. It sort of becomes this experiment of what'll be produced by different pieces of writing. Nearly everything that you can write with this characters is valid in the language. I made it so it's very hard to write something that actually has any kind of syntax error. Everything does something whether you want it to or not.
Luna Lu
And you've talked about how the esoterical involved over the years from challenging to read to easier and, um, the environment's better. So if our listener wanted to explore your work further or even try creating their own SL links, where should they start?
Daniel Temkin
Yeah, so. I've written about many languages for esoteric codes. I think that's a good place to start in terms of sort of learning a little bit of the history. But if you just wanna experiment, right? First of all, there's the Esolang Wiki, which is sort of the biggest collection of languages. It can be a little hard to find your way around it because there's just so much.
But what I would do first is try programming in an existing esoteric language. Learn that language a little bit, get some a, a good feeling of how it works, and then think about how you can expand on it or what you wanna make in reaction to it. I had a student who created a version of Brain Fuck that's sort of a hyper capitalist version where each of the symbols has a changing value with a market that's constantly shifting and you have to sort of create Brain Fuck within those market conditions, which is a way of taking the sort of basic idea of Brain Fuck and doing something new with it.
A lot of people make variations off that language of Brain Fuck because it's so simple to make. But I feel like, these days, pretty much everything is online. If you find an esoteric language that you're interested in, you're gonna probably find the source code for it. Of course, people can use AI now to generate simple interpreters for language ideas they might have as a starting place.
But I definitely encourage people to program an existing language first to get a feeling of what it's like before they try to design their own.
Luna Lu
I love that idea of learning by doing it first. Going back to your book now, 44 Ls. It really presents programming languages as idea-based art. Could you unpack that a little bit more for our listeners?
How does thinking about code this way change the experience of writing and interacting with the language?
Daniel Temkin
Sure, yeah. The basic idea is presenting programming languages in a way that's informed a bit more by people who have done performance art and idea art in the past. So, you know the two books I looked at the most when I was working on this is a book of Vito Acconci's work of his performances, which are a mix of sort of realized and unrealized works.
The whole second half of my book are the realizations of programming languages that I've actually created in some way. The first half of the book are prompts, and these are inspired by many artists, but in particular, I was thinking about Yoko Ono's, Grapefruit. Which is a collection of performance scores for performances that are unlikely for people to actually carry out or that are impossible to carry out, but are things that sort of run in our heads that we think about the performance and we might recognize some of these performances happening by accident or more likely sort of imagine them being carried out.
One of the ones that was most directly inspired by her is about watching the clouds pass on a clear day and sort of meditating on an algorithm, seeing how it's carried out by the clouds, and coming up with the rules for a language that makes that possible. Now, this is something that is a language that only exists for one person for one day, for that experience of a program that's only carried out a single time, and it's something that I don't really necessarily expect people to actually go out and stare at the stare the sky for a long time. It's more about sort of noticing the way that cause interact and thinking about it computationally and imagining a language that might exist around it. But I consider that as complete a language as some of the ones that I've created, like my whistling language, which you can actually go to the website right now and whistle code to the machine to write JavaScript for you without touching the computer at all. And that's something which you have a much more direct experience because it's something that you can actually like carry out with your computer.
Luna Lu
So are there any upcoming projects or experiments in your practice that you could possibly share with us at this moment? Something maybe you're excited for people to see or experience. At this moment? Oh
Daniel Temkin
Yeah. Well, I'm not quite sure when this is gonna come be coming out, but I have two shows up right now in New York. I have a solo show of vigil work that deals with many of the same ideas as the book. And work that's about the meaning of human irrationality and logical systems.
It is a series of straightened trees, which are photographs where I've straightened the tree and everything in the background. All the human made constructs become sort of warped to the perspective of the tree itself and a series called Dither Studies, which are patterns using the fundamental algorithm of photography dithering.
Which is a very simple, logical process, but that can often read irrationally to us because even this algorithm that's very easy to understand, the way that we can predict it, we're very bad at predicting how it actually is gonna play out visually. So Dither studies is up both in my solo shot, higher pictures, and also an interactive version at the Museum of the Moving Image right now in the lobby. Those are two things that where you can check out visual work of mine that's related to the ideas of the book. I mean, I'd say that if I had sort of one overall theme in terms of my own esolangs, it's about human irrationality and how it's exposed through thinking through these logical systems, especially when they come in confrontation with computers.
But then also about the excess of human expressiveness that we bring to code even when we don't intend to. I think that when we write code, we think we're communicating with the machine, but it's still a form of writing. And as human beings, we tend to think in terms of text, we tend to think in terms of words, and I think that we bring more human expressiveness into code than we're even fully aware of.
Luna Lu
Awesome. Could you possibly share another example from your book that really pushes the boundary? Maybe where code is almost invisible or where the intent of the programmer is completely disrupted. Like your folder's language.
Daniel Temkin
Sure. Yes. So earlier I mentioned Fat Finger. I have another language that's almost the opposite of Fat Finger.
It's called Entropy. In an Entropy, we write code that looks very ordinary, which is not sort of what we think of as esolangs. It reads as a mix of C and Pascal. It's very sort of bureaucratic looking. But the thing about entropy is that all data is constantly changing. Every time you access a piece of data, it changes very slightly.
And so the programmer has a window to get an idea across to the user of the program before it sort of drifts off into incomprehensibility. So if you write the 99 bottles of beer on the wall program, it starts off 99.0135 bottles perhaps, and as it counts down, it goes further and further away. Also the string bottles of beer starts to change it's “Bordos” of beer and “Bostos” of beer until it becomes just sort of what looks like textual vomit across the screen.
One thing I did with Entropy is I rewrote the classic chat bot Eliza to see what personality Eliza would have in sort of in tropic version. I ended up with drunk Eliza, who makes a lot of sense at the beginning, but she becomes less and less coherent and the more you talk to her. The more randomized her responses are.
And of course all the strings get all sort of messed up so it looks like it's full of typos. But what was interesting about drunk Eliza, is that people who used the program would reflect the way that she spoke. So they would start writing less and less coherent responses and they would write in a more sloppy way.
This was one of my very early languages and Fat Finger sort of grew as a response to that language. Another idea I play with a lot in the book is around the dematerializing of code and the extremes of how small a language can be and how invisible language can be. So there's a kind of a classic esolang called White Space, which I think is from 2003.
And White Space is a language that ignores text that usually matters in a language like C. So like if, if you're running code and C, you can use a space to have a return and they all have the same value. White Space is the inverse. So only tab space and return have any value and the actual text is all ignored.
And so you can write a C program where the space is between words is itself a white space program. So I thought about what is even more empty than an empty looking file, and my answer was an empty folder. So I created a programming language where it is entirely created with folders inside of folders.
And everything about the Folders, apart from the hierarchy that they create is completely ignored. All the files inside are ignored, and all of the names of the folders are ignored except for the order that they appear alphabetically. So theoretically, you could rearrange your C drive into a folders program, and it would be a working program.
The amazing thing about Folders, I originally wrote it for Windows, specifically because in Windows, the OS pretends that folders take up no space on disk. If you create a billion folders and you go to the top of the hierarchy and you get info on it, they'll say it takes up zero bytes on disk. So I basically, with folders as able to create a parallel file system where all your information is stored as folder.
So your programs, first of all, can be folders programs as they run, all the temp data is stored as text strings within the names of folders, and then all the data is output as names of folders as well. And so you have this parallel file system that seems to take up no space at all. Of course, this doesn't actually work.
If you did this, you will run out of drive space. It'll slowly make it appear that your drive is smaller and smaller as you go. So I have a lot of languages that sort of play with those extremes. I have a lot of languages that deal with the ambiguity of human speech. I have one language called Valence, which is written with eight ancient Greek symbols, and each one of them has many different readings.
So you know, I can say the sentence, Billy saw the group with the telescope, and it sort of has two different understandings. It could be that Billy's looking through the telescope and seeing the group. Or that Billy is walking by and they have a telescope and he sees them. This kind of semantic ambiguity is something that usually we avoid in code, but in valence, all of those eight signs that are available to write in in the language are hominems that have many different interpretations.
And so the code that you write also has many interpretations, and when you run the program, it runs every single possible reading of the program at once. Now you have ways of sort of locking down, meaning using brackets. But which gives you the possibility of writing what's called a polyglot program, which is a program that runs differently in two different languages.
Except here it's within a single language. And so the idea is to create programs that have multiple different, different understandings.
Luna Lu
That is amazing. I love how these languages almost have a life of their own when people use them, and thank you so much for being here and speaking with us. You can learn more about Daniel's work at danieltamkin.com and check out his book Fourty-Four Esolangs.
Please check out the links in the show notes for more information. Thank you for listening to Tech in the Arts. Be on the lookout for new episodes coming to you soon. If you found this episode informative, educational, or inspirational, be sure to send this to another art aficionado in your life. You can let us know what you thought by visiting our website, amt-lab.org.
Or you can email us at amtlabcmu@gmail.com. You can also follow us on Twitter and Instagram techinthearts, or on Facebook and LinkedIn at Arts Management and Technology Lab. We'll see you for the next episode.