In Conversation

Daniel Temkin & Pall Thayer

In Conversation is a series of ‘artist vs artist’ conversation pieces that will be a regular feature. In part one of In Conversation we invited artist and NOOART contributor Daniel Temkin to talk with Icelandic artist Pall Thayer.


DT: Your Microcodes series is written (mostly? completely?) in Perl. Perl is an interesting choice; it often reads as almost psuedo-code, perhaps making it more accessible to non-programmers who view your work. At the same time, Perl has the potential to be written in such unreadable forms that some actually consider it an esolang, out of the box. Could you talk about why you’re drawn to Perl for your work, and if you’ve experimented much with other languages for code art?

PT:  The Microcodes are presented exclusively in Perl. This choice was two-fold; first, Perl, as your comment suggests, is a highly versatile language. It maintains a flexibility that many other languages reject. One of Perl’s motto’s is “There’s More Than One Way To Do It” (TMTOWTDI; pronounced, “Timtoady”), second, I know Perl very well. Combine these two things and Perl feels to me like clay. It’s malleable. I can mold it in a number of ways and on multiple levels. That being said, many of the Microcodes contain system calls and/or terminal codes that either enhance or detract from the general readability of the code. For instance, in the case of “Seedbed”, the Unix terminal command “touch” is used to enhance the suggestive readability of the program whereas a line like ” system 'tput' , 'cup' , $the_spot,  $last_line;” (“The path to enlightenment”) doesn’t read well but enhances the performance of the program. The codes are all conceptually driven. In some cases the concept is more dependent on the readability of the code, in others the performance of the code takes precedence.

I could produce my own vocabulary (esolang) within Perl, i.e. lolcat, but that’s not my objective. I have chosen to work within the confines of Perl and the Unix terminal. It’s a bit like a painter working with a limited pallet. Of course, an esolang does that too, as we see in your own work. Especially the new color image thing but I want people to look at an existing code language and consider the fact that they aren’t as strict and formulaic as many people think. There is an element of creative flexibility involved. Programming code can “read” in a certain way and that may or may not reflect what they actually do. It’s up to the person writing the code.

For other work (besides the Microcodes), I tend to use a number of programming languages. Often, my pieces will involve scripts written in Perl, PHP, JavaScript, Processing and/or MySQL. And perhaps Pure Data. It depends on the work and the technologies it requires.

From what I’ve gathered, your chosen platform is Windows. To me, that suggests a very inflexible system and I have to admit that I don’t really understand how you do what you do in a Windows environment. Have you considered working with open-source environments and, if you have, how do you think that might affect or influence what you do?

DT:  Ha, the UNIX guy is callin’ me out on Windows in the first question!

No, but it is a conflict of sorts. You and I are both working in forms that have to be open-source to function. Code art like yours rely on the relationship between the code and its execution. Esolangs are programming languages; to let anyone else experience it means giving them the rules that define it, either to program in themselves, or at least to consider the logic that makes it function as a system.

I tend to work in Windows for one of the reasons you mentioned; it’s just how I’m used to working. It’s my background (from years of working as a programmer for my day job) and I still have easy access to its tools. When I first began creating esolangs (such as Velato, my first project), I created Windows compilers for them first, with the idea that I’d get around to making ones for other platforms. A language, again, is simply the list of rules that defines it — but the compiler allows others to actually start working with it and often exposes surprises in its behavior that aren’t apparent from just seeing a description of the language. I find compilers difficult to write, it’s the laborious task that comes at the end of designing a language; it became a hurdle I would have to overcome to put the language out.

The aha moment came when I came across Andrew Hoyer’s javascript implementation of my language entropy. Suddenly, this language was opened to everyone (and, btw, this is a great aspect of programming culture online, the way these ideas are shared and built on by others…). Now, when I meet with students who want to create esolangs, I generally encourage them to start with javascript interpreters, or to simply to create languages that extend javascript in some way, in part because particularities of different operating systems don’t become a factor.

This question of the rules of the language and the execution (the necessity of having a compiler) gets me thinking about the tension between them. I often compare esolangs — and code art — to Fluxus event scores or other performative scripts. Geoff Cox, in his Speaking Code, makes the point that code is a special type of performance, in that the machine always “performs” the same piece of code the same way: the speaking of the code and performing of it become flattened. I think of your codeworks as opening that back up, even if there is no literal performance of the code by the reader, it is still invoking an idea apart from the machine’s interpretation, which reinserts some level of creative interpretation by the reader. Maybe you could speak to how that functions in your work?

PT:  You should consider telling students about Perl for early esolang experimentation. That way they don’t need to think about a compiler. They can build it as a Perl module.

I’ve never thought about my Microcodes not being literally performed by the reader. I’ve always expected readers of them to try running them. To me, the experience is incomplete until you see what the code does. Each of the works exists on three primary levels: the code, the title and the running process. Ignoring any of these makes the experience of the work incomplete. Even in the case where the code doesn’t produce any output, the way that it runs is important. Does it loop or does it exit? Take for instance “The beginning of the end”. If you were to try running it and it were to immediately exit, it wouldn’t make any sense. But it enters a loop that may not be immediately apparent in the reading of the code. The idea here is that a person would never actually experience their own end for the end wouldn’t be reached until the person ceases to be. Therefore, a wait for “the end” will never be more than that, a wait.

What are your thoughts on the notion that we create for a very limited audience? In my case, the general public is expected to be able to read and interpret lines of code as well as running them in a terminal. In your case, they are expected to be able to write code and/or appreciate the quirkiness of an esoteric programming language. Do you think about who your audience is?

DT:  I think as more people learn how to program, art that builds on code will not just have a wider audience, but grow in sophistication. Douglas Rushkoff (in Rhizome’s Seven on Seven 2012 keynote) called for children to be taught programming in elementary school, to help train them to create content instead of becoming passive consumers. Already, programming is moving away from being a specialized skill. I visited Paul Hertz’s Artware course at School of the Art Institute recently and was blown away seeing art students, some of whom were just beginning with javascript, come up with conceptually complex scripts and getting them to work by combining existing code and rigging them together.

However, I don’t want esolangs or code art to be limited to people who can program, anymore than to have paintings built from a visual vocabulary that makes sense only to other painters. That is the hurdle with this type of esolangs; on the one hand, there are the programmers / the esolangers (who really developed this form in the first place), who will program with the language, or at least consider its strange logic. Some of the most beautiful esolangs (FRACTRAN for instance) are not easy to approach, even for seasoned programmers.

Hello, World in Piet by Thomas Schoch

Other esolangs can be understood by viewing the code itself (or presented, as you do, alongside its output). Piet for instance, the visual programming language, is like a reverse generative art, where the rules of the language shape the visual work, but it’s the programmer who designs it according to those rules. In my own esolang work, I’m interested in the tension between how we communicate with the machine verse with each other — I see it as inevitable that at some level, human expression overflows the denotative nature of programming. Making this clear to non-programmers can be challenging. In Light Pattern, I pair the camera and the computer as two apparati, each of which has no concern for what is meaningful or expressive to us. It’s a programming language that uses technical changes between successive photographs to determine commands. But as an installation, I add a camera controlled by an Arduino, programmed to take photos that create a working program in the Light Pattern language. People read a narrative thread in the photographs, even though the photos are taken by a machine for reasons wholly apart from the content of those images. This is done to make the project more clear to non-programmers, people who will not set out with a camera in order to make a Light Pattern program itself.

I mentioned my language Entropy earlier; it was made to comment on the compulsiveness of programming. In it, all data decays over time, so programmers have to give up on perfection and write code that can get a message across to the user before their program falls apart. I realized that the best way to show this language to an audience of non-programmers was to write code in it that somehow got across that conecpt in its execution. So I took the first chatbot, Eliza; I chose Eliza because people see her as a person with a distinct personality even though her code is very simple. I was curious what personality she would have in Entropy, and I ended up with Drunk Eliza. When I put Drunk Eliza on my website, I was surprised by the response; people tended to write the way she did; as she became less coherent, people talking to her would tend to mimic that behavior. The flipside was that there were a lot of guys who seemed to be there just to hit on her, which seemed odd and surprising to me…

Who do you see as your forerunners in code art? From where did this form evolve, or who were the important influences for you?

Still From Pall Thayer’s Self-Portrait

PT: That’s an interesting question without a short answer. I can jump to the middle of the story (but it’s still going to be long). First of all, I was originally heavily invested in painting and drawing. Those were my strong points through much of my early art education. I was very involved with computers early on but they didn’t figure into my visual art until much later in life. About midway through college, I went to The Helsinki Academy of Art in Finland as a guest student. There I was introduced to a group called MUU Media and that was the first time I saw artists using computers in ways that intrigued me. I haven’t painted since. However, in those early years, I was still heavily invested in the visual aspect of things and as my knowledge of contemporary computer programming grew, I veered further and further towards “painting with code”. My “Self-Portrait” experiments are a good example of the aesthetic I developed through that practice. By that time, I had been heavily influenced by the likes of Mark Napier and casey reas. Especially through their work with The Whitney Artport that I believe was curated by Christiane Paul at the time. The Whitney’s CodeDOC project was especially influential because it made you scroll through all of the code to find the link to the running process at the end. To me, this really accentuated the concept of code being more than a method, it became a medium. The idea of manipulating code became synonymous with shaping clay or manipulating paint with a brush. Around this time, I ceased writing “artist’s statements” to go with my work and released the source code as documentation instead. My idea was that anything anyone might want to know about the work is embedded in the code, in one form or another. The code was often sloppy, with many lines that had been commented out. To me, this suggested the thought processes of the artist. They displayed the failed attempts and highlighted the successes. If anyone cared enough, they could view the code and glean the creative process from start to finish. The real turning point though, was a piece I did while in grad school at Concordia University in Montreal titled “On Everything”. This piece went, systematically, through the public collection of photographs on and reprocessed them in much the same way as my “Self-Portrait” experiments. At the same time, it pulled recent blog posts from and read them out with a very computerized voice. The piece was displayed on a website and received some good reviews. However, the reviewers consistently claimed that the material was randomly chosen while it was an important aspect of the piece, to me, that the images were not chosen at random. The piece was in fact going through the Flickr images in the order that they were uploaded to the site. I felt this was important because of the title, “On Everything”. You can’t approach “everything” by jumping through a collection in random order. It needs to be organized. The only documentation for the work was the source code but for anyone who understands code, it should have been quite clear that this was the case. Obviously, people didn’t really care about the code and weren’t paying any attention to it. This is basically what lead me to start producing work as code first and foremost. I felt that people needed to be “forced” to engage with the code side of this type of work.

In all honesty, when I began to produce the “Microcodes”, I thought to myself, “This is probably going to mark the end of my career as an artist.” But I think it’s received more attention than any of my previous work. Which seems odd to me because I’m not convinced that people really get it. Maybe they get the concept. I’m not sure. But there are other influences that have emerged since my focus shifted to code. The first is one that Casey Reas has based work on, Sol LeWitt and another is Lawrence Weiner. Both of these artists created instructional pieces. It’s interesting to explore the relationship between early Conceptual, instructional work and computer programming code. But I think code takes things further. It gets interpreted by a strictly logical machine. LeWitt and Weiner’s work wasn’t intended for machines. There’s something else going on here.

I’ve always been very sure of my progression towards this type of art. I can easily trace the steps and see what led from one point to another. How would you describe your progression? I know that your educational background is in photography. How do you go from photography to writing compilers and who or what influenced it? What was the initial spark and how does it relate to your background?

Still from Drunk Eliza by Daniel Temkin

DT:  When I first discovered esolangs, I just thought they were really cool and wanted to experiment with them myself; I didn’t know you could do such things with programming languages. At that point, I didn’t think of them in an art context, it was more of a way to work off the frustration of thinking in the orderly, compulsive way I wrote code at my day job. When I decided to go back to art school, I picked a photography program; I love photography and I think I wanted to an escape from from programming, which was starting to feel kind of oppressive. But I found that ended up using photography to explore the very same issues I began exploring with esolangs; it just took art school to help me figure out what I was doing with esolangs and how to articulate it…

Esolangers are what Jon Cates calls an “expert culture,” people who make work as a community, each building on the work of others, but without institutional support that legitimizes it (sort of like fan fiction). The more research I did on esolangs, the more I was surprised by the conceptual complexity of the work; built by people who were not explicitly thinking of it in an art context and didn’t necessarily have access to or any interest in art history. It showed me that, as important as that history is, the playfulness and the urge to take systems apart to reinvent them to express things they hadn’t seemed possible to express before is an instinct that comes as naturally to hackers as to artists. The language Unnecessary, for instance, takes compilation apart to use the compiler as an all-rejecting system—the only true Unnecessary program is one which doesn’t exist, and when compiled, it prints its own source code (which is nothing). I found this brilliant, and when I show it to non-technical art audiences, they get it right away. That was really exciting for me.

So, the esolangers themselves were my big influence, but Sol LeWitt and Gerhard Richter, who I see as personifying two strategies for sublimating one’s agency into a system, are huge influences. I looked quite a bit at Fluxus event scores, especially the ones which annihilate distinctions between artist, performer, and audience; and considered how esolangs similarly blend the roles of language designer, programmer, and audience.

One final question: what do you see as the future for code-based art?

PT:  Before I answer the question, I would like to mention that I find it interesting that Sol LeWitt’s name comes up so often in these sorts of discussions. I would venture to say that it’s quite obvious that he is one of the prime figures that justifies tying this sort of work to the visual arts.

My dream for the future of code-based art is quite simple. I foresee a greater general understanding of code in the near future. How long it’s going to take for the general “art world” to comprehend this new language of creativity is anyone’s guess but it’s something that has happened over and over again throughout art history. I have a hard time believing that it will eventually be dismissed as our interactions with code in our daily lives continue to grow.

Eventually, people are going to figure out that compiled code doesn’t live forever. In fact, as works of art, they have a very limited life-span. When this happens, some person, more prominent than I, is going to point out that making the source code public, will prolong the life of this kind of work. The code will become a map, or notation, for recreating the piece on later technology for the sake of cultural preservation.


Daniel Temkin studies the clash between human compulsiveness and the irrationality of the machine through images, programming languages, and interactive pieces. His writing on esoteric programming (esolangs) and glitch art have been taught and presented widely.

Pall Thayer is an Icelandic/American artist working primarily with computers and the Internet. He is a devout follower of open-source culture. His work is developed using open-source tools and source-code for his projects is released under a GPL license. His work has been exhibited at galleries and festivals around the world.