 So I'm going to be talking about esoteric programming languages. And I'm going to start with the so-called more somewhat traditional esoteric languages. And I'm going to work towards those that are essentially unusable for coding. What I hope to do with this talk is so confusion about what programming languages are. I'd like it if we all walked away a little bit more confused about what code is, what computers are, and what programming languages are exactly. And being here at ZKM, I'm going to be drawing some parallels between esoteric practice with movements in digital art and literary practice that take sometimes similar approaches to some of these languages. So to begin with what I do, I'm an artist. I make a lot of work about our relationship with logical systems, especially those that expose just how bad human beings are at logic, which is basically the experience that I have when I try to use computers. And they tend to fail me because I'm an irrational human and I can't get a logical system to do what I want, which creates a compulsive loop. I take pictures of trees and I straighten them. This is on my work. And I also make programming languages, such as folders, which is a Windows-based language which you write entirely with folders. There's no files. There's no other texts necessary. It's the pattern of folders within folders. That is the code. So this is a Hello World program. And you can see I've nicely labeled it Hello World at the top. And Hello World has a bunch of folders in it. Each one is a command. Each of those commands has a folder and the number of folders within that folder tell it what kind of command it is. And then the second folder has other content, whatever expression is passed to that command, and so on. Now the nice thing about folders in Windows is that they supposedly take up no space on disk. You can see this by creating 300,000 folders and getting info on it. And as you can see, it takes up 0 bytes. So as long as you're storing your information in my folder's file system and using the folder's programming language, you have infinite disk space, right? It's just never going to run out. Of course, that's not entirely true. It just Windows lies to you. But it's kind of a nice feeling knowing that you supposedly have all the space that you want. So apart from this, I write a blog called esoteric.codes, which began as a series of interviews with people who create esoteric programming languages and has expanded to become a blog that's also about other experiments in language and code. It's become sort of a meeting place for people who are more from that hacker and hobbyist side, with people who are approaching this type of work from computational literature or from digital art. So this was an interview from last year I did with Martin Cleppy, who created J.S.Fuck, which is one of my favorite projects. So anyway, this is the kind of stuff that I do. I'm going to be talking a lot about programming languages, but I'm also going to be talking about Yoko Ono, so just to warn everybody, because that upsets some people for some reason. This is going to be both bot art and programming languages. So the first thing I want us to consider is what is a programming language? Now, this is a commonly used term, which is actually, in some ways, surprisingly unspecific. If you look at most books on compilers, they kind of brush past what actually is a programming language. They'll have some initial description. It's an artificial language. It's a formal language. It's used to control machines and so on. But that's really not a very good definition. And I think that what happens when we dive into these esoteric languages is we find languages that kind of challenge conventional ideas of what a programming language is and show that there's much more uncertainty around what this boundary is than we might expect. Now, this is something that happens a lot in language. There's a great game called Something Something Soup Something, which I'm not sure if people are familiar with. But this is the game where you're trying to tell aliens how to produce soup for people you need to feed. And the aliens don't really understand what soup is. And they give you soup-like constructions. And you have to either agree that this is soup or not soup. And the point of the game is to make you more confused about what soup is and what your personal boundary is of, I consider, the soup or not soup. This is a liquid, which is probably edible, although it doesn't actually tell us. And it has croutons, which makes it kind of more soup-like. But it's also in a hat, and it's served with an ice cream scoop. And even more confusingly, it has a cocktail umbrella, which we don't really think of as something that is appropriate for soup. So let's look at some esoteric languages. Now, how many people here are familiar with brain fuck? Kind of the most famous. Yeah, OK. All right. So we're not going to spend very much time on that. It's really hard to talk about esoteric and not start with brain fuck. There's a reason that it's sort of the best known and kind of one of the most influential of these languages because it really is kind of a masterpiece of SLX. But the point that I want to make about it is sure Urban Muller made a lot of really good choices in designing the language. The use of punctuation is sort of arbitrary, but aesthetically nice. Of course, the name has made it very popular as well. But of course, the idea of making this very kind of tiny, turn-complete language kind of showed what was possible with esoteric programming right at the beginning. But the point I want to make is that this is created by somebody who is sort of backed away from SLX. He's not somebody who really seems that interested in the legacy of his language. And in some ways, it's not just his creation that's made brain fuck itself so good. It's the hundreds of people who have discovered all sorts of weird algorithms in brain fuck that have made this continue to be something important and influential. So this is just five different ways to write the number 35 in brain fuck. The top one is kind of the most obvious. It's essentially multiplying two numbers in the most straightforward way that you can in brain fuck, which is sort of a loop. Adding something, one number over and over again in a loop, essentially multiplying it, the outside number with the inside number. But then there's also all the weird ones counting down from zero and all the work that other people have done in trying to find the most compact brain fuck algorithms. So the point that I want to make about brain fuck is that Urban Muller in creating the language asks a question. He's kind of put out a set of rules. Here's a set of commands you can use to write code in. Now, what actually is this language? What actually happens when you try to write code in it? And it's all the people who have written brain fuck algorithms and brain fuck programs that have sort of answered that question in different ways. So I want to draw a parallel to a literary movement called Ulipo. Ulipo is a French acronym. It's for the Workshop of Potential Literature. It's a Paris-based movement, which started in the 1960s. It was made up of writers and mathematicians who created constraint sets for writing. They came up with rules such as write a novel without using the letter E. And then Georges Perac actually did that in French. He wrote quite a long novel. English translation is called Avoid. And it's very often awkwardly phrased because it's hard to write French without the letter E. It's hard to write English without the letter E as well. The piece in the picture here is called 100,000 Billion Poems. It's by Raymond Kino. And essentially, it's a group of poems that are split at every line. So you can recombine them and create all those sort of potential poems out of the book. Now, similarly, with brain fuck, we have the list of commands. Here's your toolbox for writing code. And it's the people who write the code within the language that are sort of answering the question that's set out by the Esselanger. So before we got to some of the more non-programmable languages, I want to discuss Malbolge for a moment, which probably a lot of you are familiar with as well. At the time it was created. It was considered the most difficult to program in a language. It's a self-encrypting language. It's in base three, which is kind of confusing. You can see this is what it loads data in these three registers. The reason it's important that it's base three, meaning it uses 0, 1, and 2, is that the only math that can be done is through the crazy operation, which is a base three, trit-wise operator, which makes this very difficult to work with. So it's self-encrypting. Each command, the program's a run in a big loop. Each command, after it's run, turns into something different. You can kind of get an idea of what's happening with this encryption table here. Now, a while back, I interviewed Ben Olmstead, the creator of Malbolge. And he pointed out something that I didn't know about the language, which is that the encryption table that he provided when he created the language is actually different than what the compiler actually does. So what's happened is it's created a schism between people who think that the mistake is in the documentation and the people who think that the mistake is in the compiler. So basically, there's already two Malbolges from the beginning. He said that if he were to ever do another version of Malbolge, like he had at one point considered creating a Malbolge 2000, he said he would definitely make the documentation subtly wrong to create more schisms in the community between these different sort of potential languages that would certainly become these different dialects of the language. Now, this is something that happens often in mainstream languages as well. Small differences between compilers. One well-known one is a blank file of valid C program or not. It turns out it depends what compiler you use. In GCC, it's valid. It creates a program that does nothing. Now, a program that does nothing has a single no-op instruction, an instruction to do nothing. So the disagreement between is it not a valid C program and it just reports an error, where it is a valid C program and it's a program that does nothing. There's the contest IOCCC, the International Office Gated C code contest. And years ago, there was a discussion about whether they would accept this entry of a blank file as being valid C code or not, since it works in some systems and not others. And in the end, their solution was to accept it as the winner because that way no one could submit it again. So the most common type of language that is essentially non-programmable for anything practical are the esoteric languages where it's not clear exactly what computational class it is and what its potential is. FreeStar Programmer is a language that the code looks like just a series of numbers. It only has one command. That's the parameter to the commands. And basically what happens is it's a pointer to a pointer to a pointer. It dereferences each of those. And then at the end, it adds one to the resulting number. So this is a program in the whole thing runs in a big loop, too. Now, this was created by AIS523, who also created underload and a whole bunch of other great SLNs. And when I was first talking to him about this, it was very unclear what it was that he had created. He liked the idea of these C programmers who were dereferencing over and over again. But so basically this program, the zero, is going to point to the space zero within the program, which is itself, and then it dereferences itself again. It's still pointing to the zero. And then it dereferences itself again, which goes to zero, and it adds one to that. And it also prints out the resulting number as an ASCII character, but I don't think there's anything printable at one, so it doesn't print anything. So now the zero becomes a one. And it goes to the next one. And it does the same thing as pointing to itself. And eventually these things start pointing to each other, and then eventually they point outside the program, and nothing happens anymore. Now, so the thing about this language is it's not very clear what kind of language this is. It's going to take all the experimentation that's happened with languages like brain fuck before people really realize what the potential language is. Now I've heard fairly recently that supposedly this has been proven turn complete, which is kind of baffling to me, but it's pretty amazing if that's true. So to discuss the next couple languages, I have to go back to brain fuck for a minute and introduce spoon, which is basically a variation of brain fuck, which is stored as binary digits and it's Huffman encoded, which just means that the most commonly used brain fuck command, which is the increment, the plus, is stored as a one. So it can be repeated many times in a smaller space. So this is just a simple variation of brain fuck that gets away from the punctuation and is storing everything in binary. Now the next language I want to talk about is called language. Has anybody familiar with language heard of this before? OK. So the creator of language who goes by, I guess, P2 1998, he asked, do we really need both zeros and ones? Why can't we have a base one, essentially a base one representation of code? For some reason, he decided that he would use the number one instead of the number zero. Now the nice thing about language is that there's no differentiation between anything. Every single program is just full of ones. It means that it doesn't really matter what the content of the program is. It could be a one. It could be all zeros. It could be a pile of rocks. Anything that's enumerable we can think of as a language program. Now we start to get into a problem with this language because how do we know where one command ends and the next one starts? The only thing that we have is the length of the entire program. That's the only difference between one language program and another language program. And that gives language its name. LEN is a common length function in many languages. It's just the length of the program that matters. Now the thing about the length of a program is that that's also a number that can be broken down the same way that we break down numbers like in Spoon. Language has its own mapping to brainfuck. And essentially it's a brainfuck program that's represented by the length of the program. So does that make sense to people? Are people kind of following this so far? I mean basically anything that you store in the computer we can be thought of as a number. And we can treat that number in a whole bunch of different ways. So there's one practical issue with language, which is that it takes a lot of wands to represent anything with any meaning. So for instance, if you want to print hello world to the screen and we were going to store our data at the atomic level, it would take more matter than exists in the universe. So it's not a very practical language. But it turns out that had this been represented in this Huffman encoded way, like Spoon, we actually could reduce the size of the hello world program to the size of the sun, which seems much more practical. So it's been theorized that the universe is a computer, but perhaps we're just really living in a hard drive with very poor compression. The next language I want to talk about is called You Are Reading the Name of This Essalang, which is supposed to always be pronounced You Are Hearing the Name of This Essalang. Now this is a language created by Chris Pressie, who also created BFUNGE. And this is a Spoon variation, but it has 0s and 1s and also has brackets. Now the code that's inside the brackets are run as Spoon programs. And let's see, if it runs forever, then it gets translated to a 0. And if it ever stops, then it turns into a 1. So that way we can run this program. OK, it ran forever, so it turns into a 0. And then eventually we end up with a Spoon program in the end. Now of course, the problem with this language is that it's very hard to know whether something's going to run forever or not. Sometimes we can tell, but there's no general answer to the halting problem. There's no way to, in general, decide whether a program is going to run forever or not. So basically, Chris Pressie has taken a problem in the space of the performance of code and moved it into the lexing step of the language so we can no longer tell whether a series of brackets, 0s and 1s, definitively, is a program in this language or not. So language is something that is not runnable in our universe, but you are reading the name of the sessling is not runnable in any universe that has the same logic as ours, no matter how much matter it has. The next few languages I want to talk about are languages that are runnable, but they are not reliable. They're not consistent in how they work. And so this makes it impossible to write code that's going to do what you want each time. Now, whether that's a problem for you depends, again, on what your expectations of a language are. We'll get into some of the specifics of that a little bit later, but I'm going to start with this language called Cat++. It's a language by Noro Marshu. And this was a language that was primarily designed for live performance, but you actually can do computation with it. The issue is you're controlling cats. Any way to control the cats is by adding other cats into their space, giving them food, and otherwise trying to coerce them into doing what you want. So if you can convince the cats to perform the computation that you want, then it's a usable language. But of course, that's very difficult. Even with virtual cats, they really don't do what you want. And so it becomes very difficult to do even very simple things. The next language is one of mine. It's called Entropy. Entropy is a very, the code for it looks very straightforward, but the performance of it is such that all data is stored as floating-point numbers. And the more that you access a piece of data, the more randomized it gets. So at first, it's whatever you stored there, but the more you use it, the more off it goes. It means that if you're going to keep your program something that's going to run for a very short amount of time, it'll basically do what you want. But the longer it runs, the more random it gets. And your window of expressing something to the user, it starts to close. So this is the 99 bottles of beer in the wall program. You can see it. It starts off 98.99005, which is pretty close. By the time you get to 94, the tax is starting to get all scrambled. By 67, it becomes all kind of crazy. And then by the end of the program, it's essentially unreadable. Now I talked a little bit earlier about the compulsiveness of code. This was something that was written about quite a bit by Joseph Weitz and Baum about how he was writing in the 60s. He says the compulsive programmer is the programmer who is trying to get the machine to do what she wants. The computer doesn't respond the way that is expected. So you end up writing more code, trying to coerce the computer to function the way that you want, and trying to fix your code, and so on. And it creates this sort of compulsive cycle. Joseph Weitz and Baum is most famous for creating the Eliza chatbot. So I decided to rewrite Eliza in entropy to see what kind of personality she'd end up with. Because one of the things about Eliza is that even though she has a very small bank of phrases, people saw her as having a personality when they spoke with her. So I did this, and I ended up with drunk Eliza, who is basically Eliza with just those randomized data banks. You can see this is part of a conversation with her. Someone is telling her to fuck off, and then she's saying back fuckly instead of fully, and it becomes this kind of weird exchange. So the next group of languages I'm going to talk about are ones where the code becomes more reduced, more dematerialized. People are probably familiar with Whitespace. It's the language written with spaces, tabs, and returns. The thing about Whitespace is that there's just as much data. It's just data that we can't read. The code is just essentially invisible to us. But then we look at languages like Unnecessary. So this is the language that was created by Keymaker, who I interviewed a few years ago. Basically, if you try to compile a program in Unnecessary and the file exists, then it finds your program insufficiently unnecessary. And it says it fails. It won't compile it. It's not a valid program within the language. However, if you give a location on disk that doesn't exist, then it succeeds in compiling that code. Now, since that code doesn't exist, what is it going to give you? It's going to give you essentially what we got from the blank C file earlier. We're going to get a program that just opens and closes. You run it, and it appears to do nothing. For Keymaker, what this program is actually doing is it's printing its own source code to the screen. Since it doesn't have any source code, it prints nothing, and then it closes. So there's a famous compiler book known as the Dragon Book that was used years ago. And it talks about the recognizer. The part of the compiler that affirms a piece of code is legitimate in a language. Unnecessary essentially has a recognizer that recognizes nothing as being part of the program at all. So this is a language that it does have semantics. It does have the idea of a know-up. It can't produce something that does nothing. But it can't really do anything else. Now, some people might be thinking, how is this a programming language? Isn't there some minimum thing that a language has to be able to do to consider it a programming language? So we're going to talk about that in a minute. But first, I want to talk about the flip side language of unnecessary, a language called Callisty, which I don't know all that much about. It's something that I found on slangs.org, but I haven't spoken with the creator of this yet. The creator goes by the name of the prophet wizard of the crayon cake and the seven-inch bread. It's not somebody I've been able to track down yet. But this is a Discordian language. It has these self-contradictory rules, obey as many rules as possible, obey as few rules as possible. There's plenty of nothing. There's only nothing. Everything is true. Everything is false. The thing about Callisty is that anything that you give it is code within the language. Because it's all accepting, it can't actually process that. It doesn't have any kind of real semantics. All it can do is put back out what came into it. So essentially, it leaves everything unchanged. The code and the performance of the code are the same. So unnecessary is all rejecting. Callisty is all accepting. So you might think that Callisty is the smallest programming language you can have. But I'm going to discuss one more a little bit later that we can't really know whether it actually exists at all or not. But first of all, I want to go back to this idea of the constraint sets that I talked about earlier and the idea of Aleppo, of here's a list of rules and we explore these rules of the language by writing code within it. There's not very much code we can write within either of these languages. There's essentially no code that we can write. So that Aleppo metaphor no longer really works for these types of languages. These are languages that do something different. I like to think of them in terms of the Fluxus event scores. Fluxus was an international art movement in the 60s. It started off in New York, very famously and included Yoko Ono. And it involved a whole bunch of performance scores that blurred the line between the idea of the performer, the audience, and the creator of the score itself. Many of these were performances that were only performed by accident, physically impossible to perform. I particularly like the Yoko Ono pieces because they're obviously intended not to be literally performed, but just to sort of invoke an image and be sort of imagined. Some of the other people involved in Fluxus, such as George Brecht, took a little bit of a different approach. He had these performances like drip music where you would watch somebody dripping water on stage for a while. And the idea is that later when you hear water dripping accidentally you would receive it as this sort of performance, even though nobody was performing it. Now these were done to obliterate the line between art and everything else. But in a sense, these types of SLangs that seem to do almost nothing kind of blur the line between programming languages and everything else. So let's go back to talk about Turing completeness for a minute because I think this is the kind of objection that many people have towards this type of language. If you can't write code in this, if it can't perform even basic algorithms, represent even basic algorithms, how is this a language? And there's this whole system of automata theory, these Chomsky grammars, and there are languages that fit in these different categories. The basically Turing complete languages are languages that can represent essentially any algorithm that can be performed on a conventional machine. Some of these other things have smaller sets of algorithms they can represent. Malibu that we looked at earlier is a finite state machine and so on, right? So why don't we just say, OK, it has to be at least a finite state machine or more in terms of the number of algorithms it can represent to be considered a programming language. But it turns out that all sorts of other systems are accidentally Turing complete and would be programming languages if we weren't to think of them in this way. It's been shown that Magic the Gathering is Turing complete if it's played in a specific way. But Turing complete systems emerge all the time by accident. It's been shown that HTML5 and CSS3 together are Turing complete, which is not what you want. There's a game called Pokemon Yellow, which I don't really know much about, which is apparently Turing complete. Excel is Turing complete. It's really not supposed to be. And it's been shown that human heart tissue is Turing complete. So it's a little bit more complicated than this, but essentially it can be used to simulate NOR gates. And then over the passage of time, you can take a logic circuit with multiple inputs, the same number of outputs as inputs, and repeatedly apply the circuit over the results of the previous iteration, and create a Turing complete system out of heart tissue. Now this was an important finding, not because people want to create computers out of heart tissue, but because it shows that heart tissue is unpredictable and in a similar way to other Turing complete systems. So what does this leave us with? Essentially we still have the idea of computers as these logical systems, but we have to admit that these systems arise by accident as well as by design. And as soon as we get away from the sort of physical, the usual physical manifestation of computers, the fact that they're usually binary, it obviously doesn't have to be the case. It's not the case with quantum computing. It's not even the case with Malbolj, which is base three. There are all sorts of other systems that can function as computers or as programming languages. But essentially the part I want to make is that these SLNs, both the ones that are the more traditional brain fucking Malbolj type, and the ones that sort of break apart what a programming language is like unnecessary. These serve as sort of an avant-garde of computer science. They push the edges of these definitions and cradle these sort of weird spaces around them from accidental computers to languages without code. I started to put together the sentences on code art, which is essentially looking at how we can sort of think about these systems. And the first two points I make here is zero and one. I really show the results of what I've been talking about in this session. So staric.codes is the blog. This is where I interview SLLangers. I have a paper that kind of gets into a little bit more detail about what I was just talking about. In the full paper, you can find up on my site and here's contact information for me. So that's it for me. I do have more SLLengths I can talk about where I'm happy to take questions. Thank you. Thank you, Daniel. Do you want a Q&A? What's that? Have anyone questions? Hello. Do you have any languages that are primarily interesting because they have an interesting logical structure? Like for example, brain fuck was like strange, but the logic was very somewhat familiar. But for example, functional languages are strange in their logic. Do you have something that's even strange or so strange that it's not usable? Yeah, I feel like that's what many SLLangers try to do is create logic that's difficult to engage with and that people have to think of strange logic in order to program with. So the thing about brain fuck for me to go back to that for a minute is just that it took away everything that made a programming language friendly and easy to use, including numbers, variables, everything. And it sort of just exposes, it's basically sort of assembly logic, bare bones assembly logic with these basic characters to control it. And so it creates a sort of confrontation between like human thinking and the logic of the machine in a very direct way. And it really sort of exposes that. But I think that the language is that you're talking about, that you're thinking of things like underload and unlamd are probably more in that category. But yeah, there's, you know, I think that one of the people who's done great work in that space is AIS-523, who I mentioned for that, the three star programmer. He has a language called underload, which I think would be really interesting to look at. And I actually have several interviews with him up on esoteric codes. So yeah, so I would definitely suggest looking at those. But I feel like that that's what, that's why people usually create esoteric programming languages is to explore these kind of alternate systems of logic and sort of ask challenges for people. Yeah, of course, yeah, go for it. Some more questions. Oh, one other thing I brought, I have a scene with a bunch of kind of, some of my programming languages, including folders. So if people want to take them, I'm just gonna leave them up here for people. So. All right, anything else? All right, well, thanks.