Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Categories
In this Discussion
Book: Forty-Four Esolangs by Daniel Temkin
Daniel Temkin's Forty-Four Esolangs: The Art of Esoteric Code is our featured book discussion for this week.
Strands forming a glyph as part of a short program computing the Fibonacci sequence in the esolang Rivulet.
From the MIT Press:
A riveting collection of one artist’s many approaches to esolangs—esoteric programming languages—showcasing the form’s limitless artistic potential. In Forty-Four Esolangs, Daniel Temkin challenges conventional definitions of language, code, and computer, showing the potential of esolangs—or esoteric programming languages—as pure idea art. The languages in this volume ask programmers to write code in the form of prayer to the Greek gods, or as a pattern of empty folders, or to type code in tandem with another programmer, each with one hand on the keyboard, their rhythm and synchrony signifying computer action. Temkin includes languages written over the past fifteen years, along with some designed especially for this book. Other pieces are left as prompts for the reader to simply consider or perhaps to implement on their own. Esolangs are a collaborative form. Each language is a complete world of thought, where esoprogrammers build on the work of esolangers to make new discoveries. The language Velato, for instance, asks programmers to write music as code; while the language creates constraints for the programmer, each programmer brings their own coding and musical sensibility to the language. Other pieces are pure poetic suggestion in the legacy of Yoko Ono’s event scores. These ask the programmer to, for example, follow the paths of the clouds over a single day and construct a language in response that uses those movements as code. Just as Ben Vautier claimed everything is art, this book blurs the lines between computation and everything else.
Homonymic symbols encoding a multivalent statement with multiple GOTO interpretations in the esolang Valence.
Forty-Four Esolangs is a part of the Hardcopy series at the MIT Press edited by Nick Montfort and Mary Flanagan. From their series forward:
Hardcopy features computational artworks that manifest themselves in print. Works in the series engage with and arise from computation in culturally important ways. The series is a space for (among other things) books that are computer-generated by artists and poets, whether they include text, image or both; print works based around glitched media formats; ones that feature type-in programs with sample output; and ones arising from online interaction with automated agents.
For this Critical Code Studies Working Group book discussion of Forty-Four Esolangs we may begin with a framing and a common starting point of a few selected passages (provided below). To situate the provided selections it is important to understand the structure of Temkin's book, which draws on Sol LeWitt's distinction between "concept" and "idea" in conceptual art and adapts it to code art practice. Accordingly Forty-Four Esolangs enumerates the presentation of 44 conceptual "Prompts" in the first half of the book (Language 0, Language 1, Language 2...). The book then presents variously-implemented "Realizations" in the book's second half, each named ("Velato (2009)", "Olympus (2022)", "FatFinger (2017)"...) and each corresponding to a numbered Prompt.
This week in our Working Group is organized around the topic "Where is the Critical in Critical Code Studies?" -- and it makes particular sense at this moment for us to unpack the critical heft behind Temkin's works of "pure idea art" in a conceptual art tradition. Forty-Four Esolangs features an excellent forward by Allison Parrish, who frames Temkin's code art practice as aesthetic-political as she draws a line departing from Peter Naur's notion of the programmer's abstract “Theory Building View” through to Lillian-Yvonne Bertram's "Of course, programming is political. How could it not be? No one is doing anything in coding without someone else.” Parish arrives here by way of a key passage from the conclusion of Amy J. Ko's "What is a Programming Language, Really?" (2016):
"[W]e understand what [programming languages (PL)] are formally and we increasingly understand what they are as tools. Other agendas, particularly those that probe the human, social, societal, and ethical dimensions of PL, are hardly explored at all. As researchers, we should be concerned with every view, and see each as an opportunity to understand holistically how PL can shape our world"
Selections from Forty-Four Esolangs are provided here as shared starting points for discussion. The short excerpts include the author's Preface, the manifesto-like "Sentences on Code Art", three conceptual Prompts (4, 40, and 41), and three corresponding Realizations ("Cloud Computing", "Rivulet", "Valence"). The selections are embedded and attached below along with linked resources, including the source code for two realizations, corresponding online interactive editor for each, and some introductory tutorials / documentation. Consider trying out the examples given in the reading selections (or exploring your own creations).
Temkin's work may illuminate (and be illuminated by) LeWitt's conceptual art, Montfort and Flanagan's print computational artworks, Naur's "Theory Building View," Bertam's "programming is political," or Ko's "human, social, societal, and ethical dimensions." However, in the end, we may return to the bare question: What are Temkin's esolangs? What is the art of esoteric code? Thank you for joining this discussion.
-- Jeremy Douglass, CCSWG 2026
For Discussion:
- What is the relationship of esoteric code to code in culture?
- How does esoteric code relate to conceptual art?
- What do these programming languages look like through the lens of software engineering and computer science?
- What do they look like from the point of view of the history of computation?
- How is Forty-Four Esolangs related to the concept of "print computational artwork"?
- How do we see Bertram's "programming is political" or Ko's "human, social, societal, and ethical dimensions" in this work?
Resources:
- Realization 40 (Rivulet) [source code] [online editor] [introduction]
- Realization 41 (Valence) [source code] [online editor] [introduction]
- Chinchilla, Chris. "Esoteric Languages Challenge Coders to Think Way Outside the Box: Daniel Temkin’s new book dives into the coding exercise/art form." IEEE Spectrum, 04 Sep 2025. [Feature author interview]
Forty-Four Esolangs--excerpts (Preface, Sentences on Code Art, Prompts 4,40,41, Realizations 4, 40, 41):
Comments
As regards "What do these programming languages look like through the lens of software engineering and computer science?" I'm pretty much a work-a-day engineer, often computational, but equally often mechanical, chemical, or biological. I am not very artistically-oriented; I like art but I'm definitely not an artist nor art ... connoisseur. Last week, for example, I went 200 miles out of my way to visit the Dali museum in Tampa, and it was fantastic, but a day of direct Dali every 20 years is enough for me. Although I appreciate (in the Dali-like sense, as above) "artistic" engineering, like the Gateway Arch or the Eiffel Tower, what I get emotional about is great USEFUL engineering, like airplanes or Lisp, and when you can combine them, as for example the Golden Gate Bridge, I am literally brought to tears. Given this personal background, my reaction to most esolangs is more like my response to Dali or the Eiffel Tower: That's nice, and kind of a cool engineering hack -- and I really do appreciate the beauty! -- but if no one had bothered, I wouldn't miss it. Whereas, if no one had bothered with airplanes, Lisp, or the GG Bridge I would definitely miss it (in retrospect). I sometimes try to spend time working through an esolang problem, for example the interesting post on ambiguity in Valence, but because these are actual programming languages, and one needs to actually work through them in order to puzzle out the details -- as opposed to just walking through the Dali museum and looking at all the cool melty things and flaming giraffes, or simply taking an elevator up the Eiffel Tower -- I quickly find it not worth the effort to figure out, and move on. This isn't at all to dis those who have the mental space to work through problems in esolangs, but ... well, you didn't quite ask about what esolangs look like through the lens of a specific engineer, but that's the only perspective I can offer, FWIW. (I do often wish that they esolangs used simple alphabets where possible. I used to be quite an active APL programmer -- in fact, I inherited and ran the project that wrote Univac's APL environment! APL, as you may be aware, had a specialized character set, but it needed that because it was specifically (mostly, anyway) a mathematical language, and ... well, math is done with fancy characters, so we're sort of stuck with it. Also, by having built-ins be single characters, it made complex expressions extremely compact -- for better or worse can be argued, and has been ad nauseam! APL was one of those "esolangs" -- although it's not too eso -- that is more like the GG Bridge -- beautiful, obscure (at least these days) but really really useful. In fact, APL in modern form -- with actual words, is still used in the financial industry in the guise of a language called "K".)
I love to see this reflection on technological art @jshrager and appreciate this report of an engineer's eye on art. I wonder if rather than trying to learn the esolang as you might a programming language that we need to use to build something (as an engineer builds a bridge) perhaps it would be more useful to see an esolang -- particularly @DanielTemkin 's esolangs collected in his book -- as a provocation.
For example, in the case of Valence, what would it mean for tokens in programming languages to have multi-valent rather than ambiguous effects? Or what thoughts and feelings does a programming language stir in which the programmer must plead with and interpreter-god with every line they write? I guess the question is not so much how do you esteem these languages as what thoughts do they inspire?
In some ways, just the short passage "SENTENCES ON CODE ART (2017, 2024)" (selections pg 6) could have been an entire discussion thread on its own -- and perhaps should be! Sometimes I can get overwhelmed by the abundance of riches, even when we have already pared down the book to excerpts and selections...
Many of these Sentences give me different roads into different facets of CCS. In some I recognize the approaches of different bodies of work, different scholars, or different moments in my own work. For example, from SENTENCES, holding up 5 and 8 together reminds me of some of the materialism/philosophy dialectical framings that Mark and I pointed to in the "Where is the Critical in Critical Code Studies?" introduction this week.
Speaking of pairs in tension, the prompts for Language 40 and Language 41 do read very well in productive tension between "strands never split: there are no alternate paths" (40) and "each possible reading plays out in parallel / the program is an accumulation of all possible interpretations" (41). They are both glyphic, and both circuitous, yet, like the maze and the labyrinth, they share profoundly similar shaping while having profoundly different topologies.
I’ll try to add something to @jshrager ’s comment and to superficially answer the question ’How does esoteric code relate to conceptual art?’ As somebody with a background in Fine Arts, I see that the relationship between esolangs and conceptual art does not only reside in the fact that some esolangs do not have an implementation (although somebody might work on it ) and are just a concept without a true materialisation, so to say. Both conceptual art and esolangs, open up a space to question what art and a programming language are, respectively. This is one of the most valuable things.
Of course, esolangs are not useful in terms of efficiency, but I consider that their value resides in the fact that they might help position programming languages as an interesting phenomenon in fields such as arts, humanities or philosophy, in a different way than regular programming languages do.
In the same way as people are skeptical regarding conceptual art, I understand that some of them might not see the value of esolangs. Still, I perceive them as a resilient practice that is very necessary in a moment when everything is measured in terms of practicality. Esolangs do not solve problems; they create a space for reflection.
@martapcampos:
Yes, and I think this has been part of esolang culture from early on: whether as formal works that use alternate models of computation, or langs that explicitly challenge the culture of programming (e.g. esolangs that are anti-corporate or reject the monoculture of English keywords).
@jeremydouglass: so glad you highlighted Sentence 8. For me, this is as close to a one-line artist statement as I have for the collection as a whole.
I think the excess of language is perhaps easiest to discuss in terms of languages 40 and 41. But to bring the conversation back to how esolangs and conceptual art meet, I want to highlight two other entries:
Sentence 6. For any definition of the term “programming language,” there is a language that sits on its border.
Sentence A. Code is code because it conforms to the grammar of a language. The computer is the person or thing that executes code as the language specifies. In this way, the language defines everything else.
The book sometimes uses this circularity of the definitions of language, code, and computer (here computer = the executor of code) to lift all three away from our current and historical technology, allowing for alternate formulations of code and models of computation.
In Cloud Computing (Language 4), code is literally written in the clouds; its alphabet is the motion and interaction (as perceived from the ground) of clouds through the sky over a day. These are interpreted by a sole programmer who looks for patterns that can be interpreted as its lexicon, and ascribe meaning to these based on their own thoughts, perhaps on an algorithm they’re meditating on.
The prompt states that the language exists for one programmer for one day; one Cloud Computing language may not work with other atmospheric conditions, or for another person who has different concerns. Pointing out what one sees in the clouds might be fun in the moment, but (for most people) of little interest recounted later. The documentation of the performance of the work is thus “kept for personal reflection.”
Cloud Computing is unlikely to be used to program a conventional computer — although don’t let me stop you if you want to use it that way. The other two languages in the excerpt —Valence, with its built-in ambiguity, and Rivulet, a calligraphy-based language — are more “practical” in the sense that one could write Hunt the Wumpus in them.
The general idea of taking all possible paths is a standard conceptual feature of probabilistic programming languages, although they prune those paths in accord with the data being modeled. (In actual implementation they sample the space, not actually try all possible paths.) Probabilistic programming is an exceedingly useful and active area of research. It has major conferences. And presumably Valence’s conceptual similarity to quantum computation has been observed by someone.
I've loved esolangs for more than 30 years, and I'll probably buy this beautiful book. Perhaps this means my taste is overly esoteric (as an ex-engineer), but then I also like "conceptual" art. However, all art involves ideas, so I've never found it easy to draw a boundary of how the "conceptual" genre should be defined, other than a marketing category. I do see a strong connection between esolangs and live coding, as well observed in Geoff Cox and Alex McLean's book Speaking Code. My Palimpsest language looks fairly esoteric, but it does function, sufficiently well that I could perform with it.
In the early days of live coding performance, I sometimes argued with musician friends whether this was, or wasn't music, and I find the question of whether esolangs are, or are not, art, is reminiscent of that. Live coders are not usually too precious about this. We do it because it's fun, and we find it interesting. That makes it harder for the art police, who just look silly if they come round telling us that it's not fun, or it shouldn't be fun, or that they don't believe us when we say we're having fun. Is having fun political? I guess in these dark times, we have to remember Entartete Kunst, and those are parallels suggested by Geoff's book too, in the final parts of Speaking Code where he draws on Hannah Arendt.
@AlanBlackwell: Livecoders are some of my favorite folks to talk shop with. Like esolangs, sharing the text of code is essential to the work (I'd put both in a general "code art" category, although I realize that term is somewhat contested) -- and many create their own languages (Live-coder Sarah GHP and I had a dialogue about this a few years back). Plus we have a growing field of eso-livecoding languages like ORCA and the languages it's inspired. Language #15 from my book, Pas de Deux, is an eso-livecoding language that requires one programmer's left hand and the other's right, working in synchrony (which I expect to release this Spring).
The "are esolangs art?" question seems unanswerable to me in a general sense (any more than you could generalize about another medium), although it's posed to me a lot. When I stated interviewing esolangers for esoteric.codes in 2011, very few saw their work that way, but more do now, and also there are now more computational artists and poets making esolangs themselves. More importantly to me, esolangs are primarily cultural objects. In making practicality a secondary concern, they are no longer just tools -- like Heidegger's hammer, they disrupt the immediate utility to tell us something, to show us something else.
As a very novice programmer, working primarily in Python, what I find interesting is that @Temkin 's work with esolanguages itself recreates some of the canonical struggles that coding students encounter, pleading with their machine to successfully run their scripts in the same way the Olympus language makes pointedly clear. It brings attention to the embodied, and very human, experience of pushing the mouse and keyboard aside, perhaps snapping the laptop shut, and walking away to return to working on a program at another time.
This experience is part of what drives my interest in critical code studies-- not just the practice of interrogating the rhetorical or ontological arguments made by codes as texts, but by the arguments that emanate from these languages on a larger scale, existing within an ecosystem of DIY programmers, hacktivists, and critical readers who all share in some of these experiences as they trouble through learning how to read and write code. The affordances of esoteric code, then, may rest in these often unspoken moments that arise from human-computer-language relations. As Temkin says, “this is the classic bind in programming. We command the machine when we’re writing code, but how much control do we really have over what happens? I think that we’re now all used to the idea that much of what’s out there in terms of code is broken in some way” (Taken from this interview). Olympus, then, satirizes the problems posed by computational idealism and dominant paradigms that privilege clean, orderly, logical code while also itself artistically toying with messiness, lengthiness, and emotion. The stuff that novice programming, and really all programming, is made of.
Perhaps one aspect of esoteric code’s relationship with code in culture more broadly, then, is its ability to interrogate those ideals and to redirect attention to emotion in a medium that otherwise risks being mistakenly positioned as neutral, which is precisely what makes Temkin’s work critical. This at least feels like my answer to @markcmarino ‘s question about what feelings esolangs evoke. For me, they invoke a sense of recognition that programmers share in these confrontations no matter the language they write in or their skill level.