Advent of Computing - Dan Temkin - Forty-Four Esolangs

Episode Date: March 9, 2026

Dan Temkin has been a long time friend of the show. I finally got the chance to sit down and talk with him about one of his latest projects. Forty-Four Esolangs is a "The first artist's monograph of programming languages". During this interview we keep circling around one very crucial question: what really is a programming language? Get the book and learn more about esolangs here: https://danieltemkin.com/Esolangs

Welcome back to advent of computing. I'm your host, Sean Hass, and this is an interview. A few days ago, I had the great opportunity to sit down and talk with Dan Timken about his new book, 44 ESO Langs. In this conversation, we brush on just about everything having to do with a programming language, from, of course, esoterica to how a language is structured, even down to the question of what makes a programming language a programming language. I had a fantastic time talking with Dan, and I think you'll enjoy the outcome. Anyway, I'll be back in two weeks' time with a normal, more, more expected episode. Until then, enjoy. Hey, Dan. Welcome to Admin of Computing. Hi, thank you so much. Very excited to be here. I'm really excited to have you. So I, we were talking a little bit off mic before about this is the first time we've ever met, even though we've known each other for years. at this point in kind of a weird twist of fate.

So why don't we start off? Can you just give an introduction to the audience of who you are and the new book you have coming out, 44 S-O-Langs? Sure, yes. Well, the book is out. You can get it now. It came out at the very end of 2025. And it is a book of esoteric languages

that I've been designing since around 2000. or so. I think the first completed piece is from 2009, which is a programming language where you write code as music, as a MIDI file, where the interval between notes are commands. And it gives programmers

space to design a program that does what they want programmatically, but that also sounds good to that programmer, or perhaps actually expresses something about how it performs as code, if you want to get really sophisticated with it. So that's the very first language of the book.

and from there it goes into more and more different explorations of what sort of possible to do in a programming language. And the book is meant to push back against certain received ideas about what a programming language is, what code is for, what we can express in the text of code. And there is almost certainly at least one language in the book that you, as a reader, will consider not really a programming language. But hopefully, if you read the book the right way, it'll make you rethink a little bit about what falls within the scope of what a programming language is to you. And perhaps this will expand that definition for you a little bit. I love that. I really like what you were saying about pushing back against the definition of what is a programming language. Because on the podcast,

I talk a lot about really early programming languages. And you get to this point where you kind of have to squint and be like, well, that's not turning complete, but does that really matter in like 1945, right? So there's, I don't know, I always kind of fall on the side of, there's things that just kind of feel like languages, even if they're not the strict most textual definition of a language. Yeah, I think that the actual, you know, textual definition is a little squishy. If you look at it from the right angle, because there's automata theory, right? There's something that tells you, okay, this is pushed down automaton, or this is a turn-in-complete system, or whatever, and that tells you something about it. But does that really tell you whether

something is a programming language? Because after all, you know, I start off the book with one of the papers that really inspired me to get into this area, and that was a paper about how Minesweeper is Turing complete. So if you had an infinitely large Minesweeper field, you could encode computation into it. And to me that was... That's interesting. Yeah, I found that really fascinating. And of course, now there's a big list of various

unintentionally turn complete systems, some made by people, some that have... Some that are not created but exist in nature and which were just sort of discovered by people. But the idea is for many people, they would not consider infinitely large mind sweeper board, as a programming language. But that gets into questions of why that would fall outside the definition for you.

Is it about practicality? Because there are many programming languages that are not very practical, including many non-esthetoric languages that have just sort of, you know, I mean, DSLs are languages that are useful in a very specified way and are not really meant for general computing. And then there's a ton of languages that are made as experiments that are meant to try out different ideas, but are never meant to actually be used in a practical way.

And all that falls outside of the esoteric class of languages. Well, there's even languages like IPL, right, where it's not necessarily super domain-specific, but it's just so early and so not designed for any kind of developer experience, that it looks not like a language at first. APL, you said? IPL.

IPL. Tell me about IPL. IPL was one of the predecessors to LISP, like kind of spiritual predecessors, that's a list processing language, but it's written in the format of an assembly language, and it's all numeric. So you don't have named variables. You have like push to this number, pop from this number, and you can build up structures like LISP. LISP's actually developed partly as a response to IPL being impossible to work.

with because it's just so uptoos. Nice. Yeah. No, that's that's a great example. And one thing about, I mean, when we look at the early languages, a lot of them were tied to specific machines at the beginning, right? And a lot of the early languages were more low level. What happens when you start to get into higher level languages is that we create new abstractions for the machine. And usually they're meant to be very general purpose in a way that sort of erases the machine, but in a way that provides a general sort of toolbox of things that would be useful to the programmer in a general sense.

So if I'm writing it in Python, I don't have to care what kind of processor it's running on and so on. But the thing is computers are great simulation devices. Computers are great at pretending to be other computers. and because of that, we can really build abstractions that get much further away from the hardware. And then you can get to the point where you might ask, does this really need to be simulated on any computer?

Does it matter if the language that design is not something that is really sort of computable on conventional machines? So there's a series of languages by David Medore, who's the creator of on Lambda, that he created not as esoteric languages, but as part of his PL theory research, which were the hyper-arthmatic languages,

which can do things like solve the halting problem and count to infinity. That's really cool, because that's not something that's computable, like explicitly. That's right. And the thing is that he proves that the language can solve these problems. The only problem with the language is that it has to run on an infinitely large computer that we can't build in this universe.

Not entirely practical or what's the buzzword. Very, very poor scalability, right? Yeah. That's fascinating, though, because that is a complete redefinition of what is a programming language. Yeah, and that's something that comes from outside of SLX. That really comes from computer science research. This is the kind of thing that, I guess, computer science, PhDs sit around and talk about.

But yeah, it's all very cool. So now that we've mentioned it a couple of times, we should actually explain what an esoteric programming language is. So I know I have my definition, which there's layers, right? I usually say, oh, it's a joke programming language if I'm just trying to quickly explain it to someone. But I'm sure you have a much better definition. Yeah, I think that many,

the many SLAGs in the early days were created as jokes. Especially the languages that came from around 2001, 2005, there's sort of these classic languages like Shakespeare, which and these like law code and those types of languages. But what sort of happened is, I guess people usually think of them either as puzzle languages, which are the languages like false and B-Fung and BF, or the joke languages.

But I think a lot of these languages do much more than that. So the language Pete, which people often mispronounce as Pia. I'm guilty of that. That's how I pronounce it. That's how I started out pronouncing it. I think most people who are not Dutch start off pronouncing it that way. But then my Dutch friends laughed at me and said, no, that's not right at all. Pete.

Anyway, so it's a language that's name for Pete Mondrian. And it's one of the languages that really inspired me to get started with Acelang's. In fact, the language that I mentioned, Vallado came from me thinking about how do I make a Pete-type language but for music instead of as images. Gotcha. Yeah. But because Pete's the one where you have to draw an image and that's what your code is, right? That's correct.

So what happens is you can kind of think of Pete as a successor to BFunge. So we have this language BFunge, which has single character commands for the most part. And you end up with a grid of code, and the code can flow left to right at the beginning, and then turn and move up, and then move to the left, and then go off the left, and appear back on the right, and then go down. So Pete does most of these things also, but it's moving through colors in an image, rather than as text. And it's actually the change in either hue or brightness

between pixels, but they're called codals, because they can be drawn as larger pixels. Sorry, if you want to draw out bigger. So that's how the commands are encoded. But some of the commands are about changing the instruction pointer to move in a different direction. So you can move through the. space of the image. And Pete really, I think it began as, I don't know if strictly speaking,

it was meant as a joke, but it's definitely not something that David Morgan Moore expected many people to create images for. It was sort of just like, oh, here's this strange idea for language. Let's see if I can actually make it. And then he did. And what happened with Pete is Pete is a very good multi-coding language, which means that, first of all, it multicodes because you see the code is both a code and image simultaneously. But what makes it multicoding is that those two things impact each other. The way that you draw it affects how it runs its code,

and the way that you want it to run as code affects how you're going to draw this thing. And what makes it really sort of exciting, and it's a multi-coding language, is that you can draw things, that say something about what the intent of the program is. And so it becomes this really interesting place-based for programmers. And since that time, there have been many languages that have been intentionally designed as multi-coding languages. It's a whole genre of esolangs.

But it was not sort of created intentionally. It was sort of like, here's just this idea. And then the next person looking at Pete and saying, how can I push this a little bit further? and then someone looking at that and going a little bit further with that. So I think that S-Langs have sort of moved out of the category of just being puzzles and jokes and being really sort of a full-on hacker art form where people use it to experiment with what's possible to express in the text of code to push back against certain norms of computing that maybe they don't agree with.

like, for example, the fact that almost all programming languages are written in English keywords. There are plenty of SELangs that use other natural languages to show that that's possible and what that would look like and sort of explore other ideas. That's fascinating. But with Pete, especially, the ability to explain or express your intent in different aspects, that's what you want to do. with any good program, right? You want to have some way to preserve the theory that you've built while developing that program.

So the idea of doing that visually, that does sound outlandish, but that makes so much sense if you just strip away like all the classical thinking we have about what a program should be, right? Yeah, absolutely. I mean, some of the early examples

are things like, let's print the word Pete to the screen and make it look like a very mongering. looking image, right? That's sort of a more obvious way of connecting the two things. But then there's a piece by Richard Mitten where it is a drawing of a red circle and next to it is a line, which is the size of the radius of that circle. And it actually... It's cool. It's very cool. The thing about it is that since it uses the image of a circle to actually represent the circle in code, it means that the larger you draw this program

and the less pixelated it becomes the more accurate it'll calculate pot. Oh, wow. That is, that's fascinating. Yeah, that really blew me away when I saw it. And I think that, like, it's something that's only possible to do in Pete. And it speaks so directly to what Pete is as a language that I think it's just really a beautiful piece. And that's one of the things that's really exciting about making asselangs as an artist is that you're not, telling the computer to do something, you're developing a system that other human beings are

going to interpret and they're going to take in their own direction and they're going to bring their own aesthetic to it and their own ideas to it. And they might discover things about it that you would not have seen for yourself if you were just the only programmer for that language. So like the circle example for Pete, but like one example for one of my languages, I create a language called Fat Finger, which is actually a dialect of JavaScript where you can type everything wrong, and it guesses at what you meant to write by the keystroke differences with things that it actually recognizes. I feel like JavaScript kind of does that already, but very dangerously.

Oh, yeah. I'd say like, I have like three or four SLags that are really just about like how wild can we get with JavaScript, you know, because I think JavaScript is such a beautiful language, you know. it's so inherently chaotic. It wants to do these things. You just have to let it loose. But like, okay, so that was my vision of what Fat Finger was about. But what ended up happening was a code poet named Jeremy Douglas,

who teaches at UC Santa Barbara, he was playing with Fat Finger, and he realized that instead of writing sloppy code full of typos and leaving that as your code, which is what I was picturing and how I wanted people to write this. He was intentionally replacing one word with another, so he would introduce a variable who, WHO, WHO, and then he would refer to it as why and when and whom, and all those things would work because it's the closest thing in scope.

And this way he was able to write poetry that would read in English and run as JavaScript using Fat Fingers a way to make it runable. So that's the kind of thing that, you know, certainly was not how I saw this language. And yet once he showed it to me, I was like, oh, wow, this is like a really interesting use of it. And it really expands how this language can be used. And then things happened again with Fat Finger more recently because there was this report from Anthropic that it takes a relatively small number of bad examples of code to poison the model. against certain languages. And, you know, I realized that we could write just a ton of fat finger code

because it all reads as JavaScript and it's all runable. And this is a way that we could, you know, poison it against JavaScript. In fact, we could make acetarch dialects of a whole bunch of languages and, you know, kind of ruin it for everybody. I love that. That kind of speaks to how flexible programming is. art, right? Because I don't know, I'm on the spectrum of looking at programming as like an art versus science. I tend to fall on the art side, right, because it's so largely flexible. It can be

very expressive. And if you give two programmers the same task, they're going to give you something radically different, depending on things like their lived experience or what they're thinking about at the time, maybe even if they've slept enough the night before. And just the, the idea that you can repurpose these S-O-Lanks for something totally different is, I don't know, that feels like it speaks to something really deep about the flexibility of art. Yeah, I think that's exactly right. I think that, you know, code, we think of code generally more in terms of logic. Programming language is as a system of logic, but it's also a system of language.

And the thing about us as human beings, at least if we follow certain trains of continental thought, is that we always express more in language than we mean to. And I think that that's true in code just as much as natural language. Like you were saying, you know, we recognize code. When we see code that was written by certain coworkers, we can be like, oh, I know who wrote this. and like, oh, I know, you know, not just from how the comments are, but also the way the whole thing is organized, you know, and certain little tricks that people tend to use again and again.

And I think that that's sort of something that people are interested in right now because AI pushes against that, right? It's like if we're all using agents to generate our code, we lose that. And so it sort of becomes a question of like how important is that to us. And so that's one way in which, I think that SLAG sort of pushed back against AI. You know, I think a lot of major programming languages in general are moving more in the direction of becoming more and more similar to each other with the same kind of features kind of bolted on often without a lot of thought of how they fit into the underlying philosophy of the language. And so like it's like, okay, the year is whatever it is.

It's, I don't know, what was it, 2008 when all of a sudden they put async on everything? Or was it later than that? Yeah, I can't remember because I dropped out of using JavaScript for a couple of years right around when A-Sync became a thing. So I came back and I'm like, this is a different language now. I have no idea what's going on. Yeah, it's like, oh, we like this thing from language A, let's stick it in language B and C. And then it's like, oh, we like this thing from language B, let's stick it on A and C.

And then all of them become very sort of flabby. It's almost like an unplanned drive towards a general purpose. programming language, kind of like the whole drive towards creating Algold, but without the committee. I keep telling my coworkers, a lot of the people I work with, right, TypeScript. And like, oh, yeah, it's just trying to be Ada. And they're like, what do you even mean by that, Sean? What's Ada? It's like, no, look at the generic system. It uses the same syntax and semantics as Ada. It's just trying to be that. It's trying to be a better design language. Yeah, I have to do typescript sometimes for day job stuff.

I have to use a nice word. That's a powerful phrase to use there. To me, it really runs against the philosophy of JavaScript in general. But I guess the bigger point, I guess for me is just that as these languages are becoming so similar to each other, I think that ascelang has created a space to explore other models of computation. Because the thing is that you can make a language of your own, and you don't have to worry about it being perfect or creating optimizations for it or all the real work of creating sort of a professional sort of level compiler.

It's like, I'll just take this weird idea. I'll just see how far I can run with this, you know? And it doesn't have to be necessarily esoteric, But making it esoteric means that you're able to go much weirder with it than you would if you're trying to make something practical. And I think that as long as they're going to become more and more important as a way to sort of counter the genericization of mainstream programming languages and the genericization of code generated by these AI agents. So we should, let's switch for topic for a little bit. We should explain why we know each other because I don't think everyone understands our odd history. Do you want to kick that off or do you want me to kick the story off?

Why don't you start? All right, so years and years ago on the podcast, I did an episode on Intercal, the first esoteric programming language. And I found your interview with Don Woods. And that was one of my main sources because Don just doesn't interview a lot of people or he doesn't sit for a lot of interviews. So that was a fantastic source to have any information direct from Don. And a few months after I did that episode, I was thinking more about InterCal. And I was wondering specifically how the mingle operator was implemented. because, you know, it's a weird language.

Don and, I can't remember the other author's name. Jim Lions. Don, yeah, Don and Jim got really, really weird with it. So I just wanted some specific answers, and I couldn't find Don's email address, so I reached out to you, hoping that you could help me get in touch. And then it kind of spiral from there for a couple years.

Yeah, so I'm a pretty good nagger. So I think that my main role here besides connecting you and Dawn was to check back with Don every six months. Like what's up with this? So like if you haven't if you haven't bothered him in a while, then I would bother him with the idea of can you uncover the original the code for the original Intercal compiler, which was simply. in a box, I think, in his garage or somewhere. It was in his attic, I think.

But yeah, he couldn't find it because he was working. He's like, get back to me after I retire. But we eventually did get the source code, which that was, I don't know, for me, that's like one of my favorite projects because that was just so surprising that we ever got that email where he's like, here you go, happy hacking. Good luck. It was amazing to actually see the original code and to go through the spitball code

and then you went much further with it because you got it up and running. Running enough to emit errors and emit code. I think like forget and some of the more complicated instructions don't work completely. But yeah, it was a really neat project. Had you ever seen Spitball before because I hadn't?

No, I mean, I'd seen Snowball, but I wasn't really that familiar with it, and I'd never heard of Spitball. So that was really interesting. But the thing about it, like, most people's experience with the language was based on the 1990 version by ESR, which was significantly different. And like, we knew about the differences before we saw the the code. But it's kind of interesting because there's two different projects that ESR and Dunwoods both

worked on, right? There's Colossal Cave Adventure and InterCal. And in both cases, it's like ESR kind of wants to lock things down and have a sort of a nice, really clean version that makes everything work the way it's supposed to, you know? And Donwood's approach is much looser and to me sort of makes more sense. So, like, if you look at Colossal Cave Adventure, part of it is that there were so many different versions of it, because everyone sort of expanded it and added their own sort of additional caves and all sorts of other areas to explore and all sorts of other characters. And ESR is like, okay, well, there has to be sort of a definitive version. And also, the map has to make sense.

So you don't have things going over each other in a way that's physically impossible. And, like, you know, there has to be standardized in terms of the writing style. You can't have crazy theater of the mind. It has to be Euclide. Exactly. And so that's the version that he, you know, put out as sort of the canonized version. And it's sort of a little similar with InterCal because the original version, you know, the documentation is not very, it's not designed to make it very clear how to use the language. The documentation is half of the joke because the language and the manual are both funny jokes on their own.

Yeah, totally. But there's things like you don't know how much pleased to use, you know, in the original version. But ESR tells you in his version. He wants you to know. And he added Come From, which I think is one of the most famous parts of InterCal. And it's a very funny piece. But it's an anachronism. It's an anachronism.

So for people who don't know, come from is a reverse go-to. So you start at the line that you're supposed to end up. and you say come from line 97, and then you have to work backwards and find line 97, see what that flow is. But the thing has come from is, the fact that I can explain it here, and this will make sense to most people,

it makes it not very intercal to me. Because the actual way to do flow control in the original intercal is like a mix of using next, do a next together. But then you also have to use, resume, I think, to get back. And then you have to use, sometimes forget, I think because you don't, you don't want to run it twice.

So if you're not going, it's incomprehensible. It's meant to be incomprehensible. And that's the feeling, that's the feeling of intercal. And I feel like that is more, it's more the innercal way, you know. So a funny story related to that. I was putting together a slide deck for VCF SoCal a few weeks ago on our Intracal project. because I tend to do talks on software projects that I do. And I'm like, well, I need to explain some of the operators.

So I put together a slide explaining Mingle, which for those who aren't intercal heads, I know there are many among us, it combines two 16-bit binary numbers to make a 32-bit one by alternating binary digits from each input number. It's not something that's completely useless, right? Like I've never thought, I would love to mingle two numbers that I have a use case for that. And so I put together a slide, and that's easy to explain graphically. Like that makes sense. And then like, oh, select, I should do select too.

And then I started trying to remember how it worked. And I was looking at the implementation for it because we have the source code now. And I'm like, no, I can't explain this. And I don't understand it well enough to talk about it. So I just have a slide saying, I'm not talking. about select and then go to the next slide. Because it is, the language is kind of meant to be

incomprehensible as a commentary on how challenging a lot of contemporary languages were to understand. Oh yeah, absolutely. And I think that there is, I love the vocabulary, just the word mingle, and the way

that they renamed all like the common operators. I, I I forget. It's like the... Spot, splat, double spot. Splat spot.

Worm. Big money. Oh, yeah. You went through this in the InterCal episode, right? But all you said, yeah, the names are so great. I just had to refresh myself, too. It's, it is really funny. And the fact that it starts off with Don and Jim just joking about bad names for text punctuation and that turning into a whole compiler.

That's just classic programmer humor, right? Where you're just like, oh, ha ha, that's funny. But what if we wrote something that did that? That would be even funnier. And then you just don't stop until it's over. Totally. And I think that InterCal, you know, it's such a great parody language. It really captures the frustration of trying to write code

with these systems with the graduate student and, you know, it's, it's one that that I've certainly borrowed from.

So the second language in my book is called Olympus, and you write code as pleas to the Greek gods. And so essentially, so intercal,

right, the whole thing with please, you don't say it enough, it ignores the whole program because it finds you rude. You say please too much, it ignores the whole, program because it finds you simpering.

You got to ride the line. And you don't know what that line is. You don't know what that line is. Yeah. So one of the things I was thinking about with Olympus, there were two things that really sort of kicked off this language for me. The first one was that the idea of I'm the program where I sit down at my computer and I tell the machine what to do, I was like, this isn't really what it feels like most

of the time when I'm writing code. It does feel more like a kind of prayer. I kind of plea to please do the thing that I'm asking you to do. That's, yeah, that definitely fits my experience. At my day job, when we do releases, if there's a big release, we'll theme the release. So like one time we had, everyone has to wear bathrobes. And that release had all kinds of issues. So one of my coworkers is like, all right, no more wearing bathrobes at releases.

This is now a corporate rule. That didn't work. We have to change our ritual. And releases went better when we did funny hat releases. So no robes involved now. Imagine being like the new programmer on your team. I know. Like, oh, no, I wore my bathroom to work.

This is a disaster, you know? Why does the manual have a stamp that says no bath robes on Wednesdays? What does this mean? So, yeah. So the way you write code in Olympus is it's sort of like writing to the Intercal interpreter, but instead there's six of them and they're all Greek gods and any one of them might be offended and then we'll ignore your entire program. But the other gods will still listen.

So like a sample line of code from this is Father Zeus, defender of cities, defender of homes, defender of the traveler and of those far from home. please create a loop counting from 99 to 1 called Beer Loop. And if I wrote that correctly, I've given Zeus enough praise with Defender of Homes and so on at the beginning, which are called the epithets or the adoration clause. I've given him sufficient adoration that he won't be insulted by the whole list of things that these petty things that I'm asking him to do.

Because, you know, anything we ask of the gods is going to seem petty to them. But these are even more so when you have to be so exacting. So as we do when we write code. So the other thing is you have to ask the right God for the right thing. So like Zeus is great with structure. But if you want to declare a variable, you have to speak to Namasani, the mistress of memory. And if you want to do an if statement, you would call out to Ariadne, the mistress of the labyrinth.

And of course, if you want to close a block of code, you call in Hades to collect the salts of any variables that remain. That's fascinating because, like, we were joking about, you know, the experience of programming is kind of like pleading with a machine. But in, I think in a lot of cases that is really true because computers are so complex and so inscrutable at a certain point that you are just kind of hoping that you did the exact right rituals.

You wore the bathrobe on the right day and had the right adoration clause for a loop to actually compile. It's very ritualistic. Oh, it definitely is. Like even the... I feel that way about semicolon sometimes, right? How it's, especially nowadays,

with TypeScript and Python don't use semicolons. and some languages do. So it's just kind of arbitrary. Oh, a statement ends with a semicolon because that's how it's always been since 1969, and we have to uphold that tradition or else it won't compile. Or you just use JavaScript, and then you can just forget to use them once in a while.

It doesn't really matter. Yeah, but forget to use them most of the time. But even there, that's why would you use semicolons in JavaScript? because you're trying to follow traditional convention. And it won't make it not compile, but it might mean that an older programmer could reject your pull request. That's true. That's a good point, yeah.

Yeah, I mean, a lot of it is a code that looks right. And I think that's the thing that AI agents are really pretty good at is making code that looks right. Yeah, yeah. Oh, yeah. Even if it isn't right. You know, like, I mean... Oh, my God. I can't agree with you more. So it often feels like it's like they're trying to trick you to bring in something terrible.

And, you know, it's like everything looks like it's well organized. It's usually a lot more code than you actually need, but it still looks like it has some form to it. And there's way more explanation than you can possibly read. So it's sort of like, you know, is this really adding to my understanding of this by reading all this commentary that it's giving me? Well, it filled in the adoration clause for you, and then it generated code that appeared correct, so you have to go run it. It said, very good idea. Thank you so much. Yeah, you know, that's another place where, you know, AI agents are, on the one hand, it's very easy to model most SLangs because they're pretty small languages. So you think it would be very easy to have an AI agent to do really well with generating code for SLS.

But there's a lot of SLAGs that they're really bad at, not just because there's not enough code, but because there's something about the nature of the language that runs so counter to the way that it works with code generally. And so, like, going back to BFung, the idea of code that turns directions and then moves and moves upwards and then to the left and so on, Like that's something that these, you know, it feels like an anti-AI move, although obviously it was made, you know, long before these agents existed. But there are many ASELangs that will always be resistant to these systems as long as they expect code to look in this sort of conventional way. Yeah, it's maybe that does go back to the whole art versus science thing, right? because of these AI agents, they're not going to make art. Like, classically, they're not artistic.

They're by the book replicating patterns that they've seen. It's a very scientific approach to programming, but programming isn't scientific. It is very deeply artistic and expressive, and that's something that I think is purely humanistic. Yeah, I think that's exactly right. I mean, we see what the kind of visual work is that comes from these AI agents, and it looks like a kind of

very standard sort of illustrative style that isn't particularly interesting. And it is very similar with what it will do with code. There's something, you know, the book starts with 44 prompts. And I chose the word prompt before coding with

before the whole AI thing, right? You were thinking ahead. You were seeing the future. But using them as prompts for people, it was obviously what I intended. But of course, there's sort of something tempting about, okay, well, I'll just put this in and like Claude and see what comes out. But you know what's going to come.

It's going to be the most boring interpretation possible of the prop. So if I have something about, like, one of the prompts is for a sculptural language that takes away from an algorithm. and it only describes what it doesn't do, right? It's something like that. So there's a lot of different ways you might interpret this. Maybe someone will be inspired to make an SLA that does something like this. Or maybe someone will make one anyway without seeing the book that falls along similar lines, you know?

But if you gave this to, I mean, you can kind of expect what would happen if you gave this to an AI agent. I don't even want to try to describe it. It could be a very boring answer. And so, you know, as much as people like these tools to help them be able to code things. And, you know, it does sort of democratize code to some extent for people who have never made a programming language before and maybe want to use it to create their first S-Ling as part of the as one tool. You know, you can't leave any creative decisions to it or you'll end up with a very boring language. and so that's something that just became very sort of clear thinking about the book in those terms

mostly because of this this prompts language that's in the book. Yeah, that's fascinating. And that is funny that you use that word before the current state developed. That's prescient, perhaps. So I had one more question for you, but I think we've already kind of

talked about this whole interview. That's, so whenever someone asked me what an S-O-Lang is and I explain it, their next question is almost always, well, that sounds very silly. Why would you be interested? Why would you devote so much time to that?

Yeah, I mean, I think that like calling something art creates space to be able to take it more seriously, but still playfully, without it being like, you know, okay, well, let's think about this from a different angle. How many great open source projects have you seen that are ultimately sort of pointless,

but still really amazing? Like, I feel like this is counted numbers. I've created some of those. This is what programmers do with their spare time. Like, a lot of what we make is very silly. Like, why would somebody create a, like, I can't remember who made this, but there was a project from years ago that would scan

large amounts of text on the internet to find accidental limericks. Like where is, where can you find where somebody had accidentally, like just in regular sentences, accidentally had the right rhyming scheme and the syllable count to work as a limerick, basically? And it turns out there's a lot of them.

You know, and if you read them in the right, voice. It sounds that way. I mean, that's really fun. But it was probably a programmer just trying to see if that's possible or to develop skills in a certain area of a certain type of textual search that they had never done before. And that introduces some interesting programming challenges because detecting if words rhyme, detecting meter is really difficult for text analysis. So that is like, that's fun. That sounds like. That sounds like. a really good time.

Like immediately, right? Yeah. I mean, to me, it's like, you know, there's something sort of addictive about making these languages. Like, part of it is sort of like, okay, I'm going to get into this because maybe I'm somebody who programming language design had always seemed maybe a little bit mysterious to me, right? So I'll sit down and be like, okay, well, I'm just going to write an interpreter

and just so I can learn how this thing works. And I'm going to make a language that's really fun because, you know, it's an easier place to start and it makes it more interesting for me. And so now I've made a language. It's like, oh, I really enjoyed that. This is sort of exploring certain ideas that I'm interested in. I want to go deeper into those ideas.

So I'll make another language. And I mean, that's really where it came from for me. You know, I started with Vilato, the language that you write with music. And actually the very last language in the book is a recent version of a lot of this very different where instead of carefully composing music using MIDI you actually just whistle directly to the computer

and so it's a hands-free programming language. You just start it and you just whistle your algorithm and it immediately transpiles it into JavaScript. So if you want to write JavaScript without touching your machine, you can whistle it And maybe you can harmonize with the person next to you who's writing another program. And these are very different languages because the first one, Velado language zero in the book, there's recently a piece by a Spanish composer that they performed with an orchestra of a Vallado piece,

which is some kind of, he called the Volodic Cohen, like a cone, like K-O-A-N. But I haven't translated. I haven't translated. I'd have to look at the transcription and turn it into a bitty file somehow to actually find what it says. He's keeping it a little secret. But it's a beautiful piece. It's very carefully composed. And then the whistling one, obviously not. You don't carefully compose anything in that.

You're just like how can I whistle and stay in tune enough that the computer will understand what I'm trying to say? But then it's like each language in the book answers a certain question or explorers a certain question I'm interested in at the time. And then it usually leads to another question that I'll explore in another language. So I had, one thing a language does is it splits texts into the text that belong to the language and those that don't. Right. So it's a very simple thing. It's, the Dragon Book actually calls us the recognizer, you know, which I don't think is actually a thing that people build usually. But it's not like a byproduct of parsing most often.

It's byproduct of parsing, yeah. Depending on how you look at it, if you, if someone writes code in your language, it has a syntax error, it doesn't strictly conform to the language, so it's sort of outside the language. But of course it isn't. It's just, you know, anyway. So, but what if we played with that idea? How far can we push that?

Like, does a language need any runable program? and what would it look like if it didn't have any programs that could successfully run? So I made a language called past tense, and I think you can see where this is going. So past tense is I made a converter that'll take your code in whatever language you have. As long as it uses English keywords, it'll work, and it'll convert your JavaScript program or your Rust program or your C-Shart program into past tense,

and you end up with something that is no longer runnable on C-sharp. It's no longer actually a C-sharp program. It is a past tense language, a past-sense program rather, but it doesn't run in past tense because nothing runs in past tense. So it

marks the program as something never to be run again. So if I have a program that reads, you know, I'm looking at one right now, it says, it starts namespace, helloed world, public class programs public static voided mains

strong args and so it you know it doesn't know that string is not a verb it can be verb so verbs it verb set and past tense

it's strong and so everything anything that can be a verb it will do that too and even stuff that's in strings it doesn't matter

you know you're never going to run this thing again you know so you have this nice little tax that tells you what this program used to do

and so the as a byproduct of this, if someone were to actually write an interpreter or compiler that would work for past tense C-sharp, it would actually invalidate all the past tense C-sharp programs as past tense. Because now they'd be runnable. Because now they'd be runable. Yeah, you'd have to have something even further in the past to escape.

So it's, because the thing about a programming language is it's really a set of rules for how to understand a text. and you can be very creative with what qualifies as a text like with Philotto or Pete and in terms of what is actually sort of runnable that there's no strict rules about that I mean past tense is not a language that

it's obviously not turning complete it's nothing that's runable in the language at all I don't know that there is any classification for that in automata theory but it's like a rock, you know, it's just a non-functioning object of some kind. But just as you can abstract the machine in any way you want in terms of behaviors for Nesseling, you can also sort of play with what belongs to the language and what doesn't. And you can get creative with that, and that can lead you in interesting directions.

So like this was in some ways a follow up to you. a language of mine called folders, which is written in the pattern of folders within folders. And it ignores text entirely, except for the alphabetical reading of where the folder structure. And folders was inspired really by the classic language white space. Thinking about what is more empty than an empty looking file that was just tab space or return, it's like, oh, the empty folder,

which is it's just junk that you would delete if there's nothing in it. but well, what if we made that the whole program? And the nice thing about that in Windows at least is that Windows will tell you that an empty folder takes up zero bytes on disk, which is obviously not true, but you can create billions of folders, and it will supposedly take up zero space. So you can convert all your data to be stored in folders

and you have folder programs to read the folder names, and now you have an infinitely large hard drive in theory. That's almost, denographic. It's like hiding something that has meaning in something meaningless. I love that. That gives me a lot to think about.

Well, fantastic. Thank you so much for coming on to talk about your book, Dan. This has been a really nice conversation. Yeah, this has been really fun. Thank you so much. And where can people find your book and anything else about your work?

Yes. my site is Daniel temkin.com and I have an Esselang's blog called soterk.codes which I've been a little slow to update

while I was writing the book but I do have new content coming to the blog soon. But if you go to Danieltemkin.com you'll find out more about the book there and also on the MIT

Press website. It is called 44 SELangs. Great. Well, thanks so much for coming on the show again, Dan. Thank you so much.