Daniel Temkin and the Beauty of Esoteric Languages  ## Metadata - Author: [[Hanselminutes with Scott Hanselman]] - Full Title: Daniel Temkin and the Beauty of Esoteric Languages - Category: #podcasts - URL: https://share.snipd.com/episode/07bef8c5-0919-4f29-b62d-615f4483dea8 ## Document Notes ## Highlights - **Esoteric Languages As Art Bridge** - Esoteric languages can bridge programming and art audiences by using art-focused language and references. - Daniel Temkin designed the book to introduce artists to esolangs and frame them as artistic practice. Transcript: Daniel Temkin Yes. So this is a book that is aimed both at programmers and folks in the art world who I'd like to introduce to the idea of SLGs. So a lot of the language that I use in the book is aimed more at the art crowd. I feel in general that programmers, if they come across terms that they're not familiar with, they'll look them up or they won't worry about them too much. But some of the technical terminology can be a little bit scary to the art crowd. So I have a lot of stuff in here, a lot of references to conceptual artists who they're familiar with and using words like monograph to make it clear that this is an art book ultimately. ([Time 0:01:35](https://share.snipd.com/snip/8e3eaf9b-ff87-4277-b22a-c74183954a51)) - **Esolangs Offer Deep Design Exploration** - Many esolangs do more than joke or puzzle; they enable rich aesthetic exploration and personal style within constraints. - Temkin emphasizes moving beyond listicle presentations to explore deeper design intent and influence. Transcript: Daniel Temkin Think the main thing I want to do with this book for both audiences is to show them that there's more happening in esalangs than simple puzzle languages for programmers and joke languages With kind of silly vocabulary. I feel like esalangs have, in terms of how they're presented in public, they often fall back at a kind of listical thinking where it's like, oh, here's a wacky programming language. Here's another wacky one. But one of them might be writing code in the style of Arnold Schwarzenegger, which doesn't really give a lot of room for exploration. And another one might be creating code in the form of images, like the language Pete. That language allows for individual programmers to bring their own visual style to code and to really sort of stretch the aesthetics of the Pete language and find their own style within It. And it's much richer in terms of the exploration that it does. ([Time 0:02:34](https://share.snipd.com/snip/9af7dd44-6bf9-410d-944b-3e824b6699ea)) - **Brainfuck's Minimalism Sparks Complexity** - Brainfuck uses only eight commands and a 30,000-cell tape, creating surprising complexity from tiny primitives. - Temkin started Esoteric Codes to interview creators and shift focus from dry technical docs to idea-driven conversations. Transcript: Daniel Temkin Because there are only eight commands, you have to translate your algorithm into these very simple steps, which create this great complexity of meaning almost immediately when you Jump into the language. And that people have done some sort of amazing things in this language. Someone built a web server that runs in this. It's very slow, but all this stuff is very impressive. So I started Esoteric Codes to talk to other Esselangers in terms of the ideas behind their languages, what languages influenced them, what concepts were they trying to explore, and Trying to keep them away from the highly technical language, which can be confounding to some people and sort of lock some people out of that space because they don't understand. ([Time 0:05:26](https://share.snipd.com/snip/31f77fa5-41ba-455f-95f8-be76b6e94aa5)) - **Specify Creative Decisions Before Using AI** - Don't leave creative decisions to AI when you want originality; be explicit about creative choices. - Use AI for building or generation, but specify all creative constraints to avoid bland outputs. Transcript: Daniel Temkin It's really strange how much the book feels in parts like it's about AI, that it's comments on AI and sort of a reaction to it. Because it really was written before Vibe coding was really a thing, and certainly before I was doing any code generation with AI. And the prompts, you know, if you feed these prompts to an AI system, you're going to get the most boring answer possible, right? Scott Hanselman Yes. It's the most mediocre answer that they can give you. Daniel Temkin And this is something I've actually tried with students. One of the things that I really try to get across them is don't leave any creative decisions to AI. Use AI to build, to generate code, but you have to be specific about what you want if you're letting it make any sort of creative decision. ([Time 0:12:03](https://share.snipd.com/snip/262c970a-884e-4af0-8d0e-2873f3397fdc)) - **Programming With Empty Folders** - 'Folders' is a usable esolang where folder names and alphabetical order encode commands and data. - Temkin implemented a Windows C# compiler and used folder names as strings and storage in a parallel filesystem. Transcript: Daniel Temkin I'll tell you about the inspiration for that. So for 12 folders is a Turing Complete language. Is it? Not all the languages in here are, but that one is so the idea of folders is that um it the inspiration for it was the sling white space where we use tab space and return uh as as the only meaningful Characters and it decided well those are still characters there's still a file uh what's what's more empty than an empty looking file and to me that was really the empty folder or the Folder that just has other folders in it because it always just looks like trash. So the way that folders works, the names of the folders don't matter except for how they're read alphabetically. And the top level folders are commands and then the first folder alphabetically in each one, the number of folders in that tells you what kind of command it is. And then a second folder will be an expression that's passed to it, depending on the type of command. So this is usable. This is workable. One of the things about folders is that I originally wrote it with a C Sharp compiler. And this was probably around 10 years ago. ([Time 0:15:42](https://share.snipd.com/snip/d1d81d37-e384-4171-bc91-2e07fc30d678)) - **Languages Define Code, Not Just Machines** - A programming language defines what code is and abstracts the machine; unmooring that lets designers explore new conceptual spaces. - Temkin treats programs as performance scores and leverages conceptual art precedents for language design. Transcript: Daniel Temkin So one way to think about a program is as a performance score, right? It's a score for the computer to perform. There's a long history of performance scores in conceptual art and in Fluxus and other visual art, such that we can consider things like performances that only are imagined, that can Only run in our head. And there are several languages like that in the book. Ones that will only make sense to one person at a time and won't be meaningful to other people. But I guess another way to look at this is, you know, a programming language tells us what code is, right? A programming language defines the lexicon and grammar of code. Like that seems sort of obvious, but it also presents an abstract version of the machine. And that's where the logic of the language is defined. So it's really the programming language that defines everything else. And what would happen if we sort of unmoor that from not just practicality, but from our physical machines? And we sort of lift the whole thing out into space, and we just think about the programming language alone. And what can we do with this? How can we push it at the edges of what we consider code, of what we consider a machine, of what's performable? ([Time 0:19:01](https://share.snipd.com/snip/38dbcc13-1542-4a88-9798-1286fd159fc2)) - **Making Code Unrunnable With Past Tense** - 'Past Tense' converts runnable code text into past-tense words, making programs intentionally non-runnable. - Temkin created the language to render code unreadable to machines while preserving a conceptual integrity about 'never run again.' Transcript: Daniel Temkin So for instance, I have a language in the book called past tense. And past tense is just literally, we take a program that runs in another language, and we convert any text in it that can be verbed into a verb, and then we convert that verb in the past tense. And now it is no longer a running program because can no longer run in its original language. So we might start with public static string hello world, and we'll end up with public static strung, for one thing, classed, namespaced, helloed world. Scott Hanselman Oh, I see. Okay. Public static voided main. Exactly. Yeah. Daniel Temkin So now we have our text. This is a valid program in past tense, but there's no runnability in past tense because the whole idea of past tense is that that program is now in the past tense and should never be run Again. So if you were to actually write a compiler for past tense C, then those programs would no longer be valid as past tense because now they are runnable. ([Time 0:20:26](https://share.snipd.com/snip/21f79dc0-3f0d-499d-9a49-0cef4bb39abe)) - **Code That Runs Only In Real Streets** - 'Stroll' is a site-specific language that uses three pedestrians' routes and local, unphotographable details as program input. - The blue stroller provides unique, in-person interpretations so the program only makes sense when executed on-site. Transcript: Daniel Temkin So the red stroller and the green stroller, they each have their own way of moving through the space. The red stroller is going from intersection to intersection, and the green stroller from block to block. And the green stroller is pointing to a space in memory that's represented by that block. And based on what the red stroller and the blue stroller do, data can be written to that block or read from it. The red stroller is in charge of all the constants, and those are really defined by the street names at each intersection. But the most critical stroller is the blue one. The blue one is that the way that their code is read is unique to that person, and they can define it themselves in a way that might be totally different than another Stroll program. The only critical thing about it is that it has to be something that you can only learn by being there in person. If it's something that you can easily find out by looking at photos and looking at Google Maps, then it shouldn't be used for this. And so it requires a human being to sort of make decisions and sort of interpret what the other, the previous blue stroller has set out. It could be things like the species of various trees along blocks. It can be about the incline of the street. Sometimes it can be something like the number of windows, but you have to be careful with that, of course, because all this stuff is online now. And so part of what makes it a stroll program is that if you lift the whole thing, if you start the whole thing from the wrong intersection or in another town, it'll have a completely different Result. ([Time 0:22:25](https://share.snipd.com/snip/02b5e81f-e287-4d40-a371-7b6a61bb8fe6)) - **Non-English Code Reveals Tooling Bias** - Non-English languages challenge English dominance in code and expose tooling and cultural biases in tech. - Examples like Ramsey Nasser's Arabic Lisp and Yorlang show both educational value and political statements. Transcript: Daniel Temkin Yes, yes. So there are a few reasons that people make programming languages that are in languages other than English. The most common are that they build as an educational language for a community that perhaps, especially for children who might not yet be comfortable with English, or to sort of encourage Communication in another language. But then there are languages that are made to specifically challenge English as the dominant language of coding. And some of those really fall more in the esoteric category because they're not for the practical use as much as to make a statement. The most well-known of these is a language called Alb or Kalb by Ramsey Nasser. And that was a Lisp language made in Arabic, which had started out to be a tool. And then what he found was that he was prevented from going as far as he wanted to with the language because a lot of the underlying technology had these biases that became very obvious When he was trying to work with a right-to language. And also it raised questions like, what's the Arabic translation of proxy bean or these other sort of technical terms? And how do you even deal with that in another language? Now, that language became pretty well known and it inspired a whole bunch of languages in response. There's a language called Yorlang, Y-O which is in Yoruba, which was made by a Nigerian programmer who spent all day speaking English for his day job. And after hours, he didn't want to think about English at all. So he wants to code in his native tongue. ([Time 0:25:31](https://share.snipd.com/snip/5aa9fee2-af84-49b0-b944-1b4605b26eb4)) - **Intercal: The Originating Parody Language** - Intercal (1972) is widely considered the first esoteric programming language and parodies language conventions with features like a 'please' operator. - Temkin used Intercal to inspire 'Olympus,' a language where Greek gods accept or ignore code based on praise. Transcript: Daniel Temkin First language that's generally considered an Esselang now, and whose authors consider it an Esselang, would be Intercal from 1972. Intercal is an interesting language because it's a parody of languages of its time, but it still holds a lot of power in how it sort of comments on the experience of coding. It certainly makes coding difficult. So one of the famous features of InterCal is the please operator. If you don't say please enough, it finds you rude and ignores your entire program. But if you say please too much, then it finds you simpering and it also just ignores the entire program. And in the original version, it was not documented how much please you have to use. And so InterCal, I interviewed Don Wood for Esoteric Codes. And actually Don just recently found the long lost code for the original InterCal compiler, which we were very happy to put online earlier this year. Scott Hanselman It's so funny. I just wanted to call out that InterCal, which is pronounced and abbreviated InterCal, the full name for the compiler is Compiler Language with No Pronounceable Acronym. Yeah, I'd forgotten that. Of course, you called that InterCal. Daniel Temkin I'm sorry, you were saying. Yeah, so language one in the book which is actually the second language, is called Olympus. ([Time 0:31:14](https://share.snipd.com/snip/6a8dfd60-0221-43a2-b2bc-94a6b6e59745))