Programming languages that are not useful for solving real‐world

Programming languages that are not useful for solving real‐world problems, at least not in a way that makes things easy for us, known as esoteric languages or esolangs
1
I interview esolangers and people who do cool things with text & code for my blog esoteric.codes. And I have a zine of my own programming languages.
2
Almost every piece of code I’m going to show in this talk is the classic Hello World or a variation, like this Commodore BASIC version that repeats it endlessly.*
The important thing to note is that there are the commands, each of each clearly state their behavior: PRINT to print to the screen, and GOTO, which is the simplest flow control – moving the action of the program back to line 10. * This was not true; I also used 99 Bottles programs, as we shall see! 3
Hello World in INTERCAL, a language created by two bored graduate students in 1972 as a parody of languages of the day (FORTRAN, etc).
The text of the code becomes opaque; there’s nothing that looks like PRINT and nothing that looks like Hello World
Instead of PRINT or GOTO, INTERCAL uses the much less specific DO on nearly every line. The actual command is the angle bracket and hyphen, which in INTERCAL are called the angle and worm, forming a “gets”. INTERCAL is full of such jargon. Instead of Hello World, we build a string with these words, letter by letter, using the numbers like 108 and 112.
It uses the word PLEASE, which humanizes the compiler; we’re not just talking to the machine in a general sense, but something more specific, which cares about how we word things, and expects us to be polite. But the pleading in the code is necessary. If you don’t use “please” often enough, it’ll ignore your program for rudeness – if you use it too much, the machine finds you 4
simpering and also ignores the program. The right amount of please to use is left undocumented in the original INTERCAL documentation
4
Why give up the clarity of code, what do we get instead? INTERCAL gives us some clues.
Some esolangs bring to code qualities of communication beyond what the machine can recognize ‐‐ meaning gesture, connotation, associations apart from denotative meaning. They also play with the rigor and compulsiveness of code.
Formal, constrained languages become disorderly
5
Part of a Hello World in Shakespeare – created in 2001, also by bored students blowing off steam. The majority of great esolangs seem to be hobbyists, people who are not even necessarily programmers, but have taken a compiler class and found a way to use their new skills for evil.
The characters in the play are variables. If you want to assign a character, let's say Hamlet, a negative value, you put him and another character on the stage and let that character insult Hamlet.
Juliet is in a play with Romeo AND Hamlet, and here is angry at both. A lot of obscure references to mathematical relationships between animals.
Suddenly we’re using emotional content to code, elements of communication that are played down in traditional programming languages. Since negative and positive tone is used as part of commands, the characters go back and forth between loving and vengeful very fast.
Gives a sense in the dialogue that it is something encoded, that it’s a kind of a secret knowledge, which puts the “esoteric” in esoteric language.
6
In my 32 Variations in C++, I create not new languages, but what can be thought of as dialects or coding styles for C++. The code is all valid C++ but uses special header files to allow you to write in unusual ways.
This is from my Variation 2, where I’m identifying with the compiler. It’s a rambling, exasperated commentary on the code. Condition 0: Wait, but zero is going to be the end of the program, bit weird that we are talking about it first but fine.
Condition 1: Wait, now one? Really I have to explain 1 as well?
But the words I’m using to complain about the code are the code itself. The words are mapped to commands.
7
So those were all dealing with style in human communication vs the machine. But languages are also rulesets; systems for what set of symbols are recognized and how they’re allowed to be used. Some esolangs use these to their advantage.
8
Whitespace; a language where only space, tab, and return matter. All text is ignored (the opposite of most languages). A file can look completely empty and have a Whitespace program.
A file that says “say hello,” that part is ignored, and some selected all so you can see the length of the lines
This is also a Hello World
9
What has even less content than a (seemingly) blank file? My answer was an empty folder.
This is a Hello World program. Only the pattern of folders within folders matters; the names don’t matter, and neither do the contents. Each folder that’s a command has two folders; the number of folders in the first determine the type of command, any expressions or subcommands sit in the second.
Another important precursor for Folders was this language, Piet
10
Folders also indebted to Piet, perhaps the first language to use non‐text based data as code.
Immediately, the text of the code is more opaque; programmers have to understand the logic of Piet to be able to read this. Where an experienced programmer can come across code in a language she’s unfamiliar with and work out what it does, here there are no clues. It’s actually the change in lightness and huge between color blocks that are the vocabulary of this language. The middle program is a Hello World not too different from the INTERCAL one, in the sense that it’s building a string letter by letter and printing it to the screen. Some commands tell the interpreter to turn down or right; it starts off left to right, but ends up forming a spiral.
When I interviewed David about the language for esoteric.codes, he sees it not as having a very specific aesthetic, but one that allows for many alternatives to the programmer. So it’s something which is open‐ended and not controlled by the designer of the language, but always a conversation with the esoprogrammers who take the time to write code in your language. You can see in the Piet example, Schoch
11
has created an image in Mondrian’s style to reference the language and artist. There’s a relationship between the image (the source code) and the behavior of that code (printing the name Piet). This struck me as something powerful, that I wanted to continue to explore.
11
I decided to get even further away from the classic presentation of code, and work with photographs. Although there is abstract photography, photographs tend toward representational images, which forces the conversation of the code to talk about something not just visual but indexical. Even photos of the same exact place over time tend to be read narratively.
In Light Pattern, it’s not a single photo that’s a program, but a directory full of jpegs; it’s the change in color and exposure from one image to the next (read in alphabetical order) that are the vocabulary of this language.
12
This allows me to write programs that relate the content of the program text (the photos) to how it will behave as a program.
George Brecht was a Fluxus artist, interested in turning everyday occurrences into performance; as a kind of Duchampian gesture. He wrote an event score called Three Lamp Events, where one turns on and off a lamp. I performed his score, turning on and off three lamps, with red green and blue bulbs, photographing them at different exposures, to write code which will print the instructions to Brecht’s score to the screen. Inverting the performance, where the performance causes the score. This idea of making code performative is indebted to this Fluxus line of thinking.
13
So far, we’ve looked at languages where the code is unusual. Next I will discuss languages with ordinary looking code but that behave in a strange way.
14
In 2010, I made a programming language called Entropy.
It has much more conventional looking code, but the performance of that code is strange.
I print Hello World three times, but it approximates the string, and the string keeps changing the more often you print it. All data is stored as floating point numbers, which go a little more “off” each time they are accessed.
15
99 Bottles of beer on the wall
16
Down to 67
Here it is really starting to fall apart. 17
By the end it’s all gibberish
But why do this? There’s a rigor to programming, a sense that you have to get things exactly right. Mostly because, when we don’t get things exactly right, we introduce bugs.
However, thinking this way all the time reinforces a compulsive way of thinking, and I wanted to create a language where you couldn’t get things exactly right, instead having a little window (maybe in this loop from 99 to around 90) where you can get an idea across to the user before your program falls apart.
I always re‐wrote one of the first chatbots, Weitzenbaum’s Eliza from 1966, in Entropy and ended up with ….
18
Drunk Eliza!
I put Drunk Eliza online and found people have very lengthy conversations with her. What was interesting is how drunken the responses to her seem to become; as her databank degrades HAL‐style, people interacting with her start typing with their fists, and it can become hard to tell one from the other.
19
However, a language is something to be used by others. A language isn’t a piece of software, it’s a set of rules for how symbols (commands) will be interpreted.
After I put Entropy online, someone I didn’t know before, Andrew Hoyer, created a version of Entropy in JavaScript, which allowed for visual pieces like this Mona Lisa with Entropy data that decays the more it’s moused over.
Esolangs are always collaborative; to make one is to ask people to use it; and by using it, they will take it in directions you weren’t expecting; this is one of the things that’s great about it as a medium. It’s a truly dematerialized practice – there’s no single “piece” that’s Entropy, not the compiler, not this Mona Lisa, but rather the constraint (storing data as floating point numbers that slowly decay) which programmers explore
20
21