Research and Advances
Computing Applications

Software as Art

Encouraging a greater appreciation of the interplay between software and fine art.
Posted
  1. Article
  2. References
  3. Author
  4. Footnotes
  5. Figures

Compared to other artistic media, software has a very short history. Painters have been painting and sculptors have been sculpting for millennia while software itself has been around for just 60 years, and “software as art” is an idea that is only a few decades old. Casting software as an artistic medium might strike many readers as odd, or even objectionable, but there is a growing body of evidence to show that it is perceived and utilized in just this way.

Programmers passionate about their work may sense an aesthetic that underlies their approach to software development and provides them with visceral feedback at every stage of development. They have a sense of what is pleasant to perform and what is unpleasant to endure, what is beautiful to behold and what is intolerably ugly. Observations like these naturally raise the questions: What are the bases for these aesthetic judgments? Does the context for making these judgments extend beyond the domains of engineering and computer science? Can software transcend its traditional boundaries as utilitarian artifact to become art?

Only recently have these questions been discussed and explored in earnest, and readers may be surprised to learn that the participants in the discussion are not software practitioners, but artists, grounded firmly in the new-media artistic community. In fact, in the past four years new-media art festivals have presented awards for “artistic software” and art museums have featured software in exhibitions. Historically speaking, we are living in the first period of software art, and this appears to be largely overlooked by the programming community—people who best understand the medium and its possibilities for expression. In this article I will describe how the concept has evolved, from programmer-centric to artist-centric, over its short history and speculate about how it may evolve in the future.

The renowned computer scientist Donald Knuth has expounded on the art inherent in both programming and the program since the 1970s. As the sole developer of a number of large software projects, notably the still-popular TeX typesetting program, he has developed a refined sense of software aesthetics. As a professor at Stanford University, he also has had ample opportunity to subjectively assess the work of his students.


Lucidity is often pursued as an aesthetic goal unto itself and, when it is achieved, it can impart the most powerful of all reactions.


When he received the ACM Turing Award in 1974, Knuth chose to address the topic of “Computer Programming as an Art” for his award lecture [5]. In the lecture, Knuth provides an entertaining overview of the concept of art and its role in science and computer programming. He observes there is an aesthetic associated with both the act of programming and with the program itself, and points out that a programmer’s programming style may provide gratification to the programmer, and possibly also to the program’s reader. He recounts the thrill of reading an assembly code listing written by an accomplished programmer and declares there is beauty to be found in computer programs. In a 1999 lecture series at MIT entitled “God and Computers” [4], Knuth likens beauty in a program to beauty in literature or music—programs whose tasks are elegantly stated, and whose parts come together symphonically. In his experience, he has found some programs painful to read, and others to possess wit.

With regard to the program itself, Knuth identifies correctness, maintainability, readability, lucidity, grace of interaction with users, and efficiency as properties that inspire pleasure, or pain, in its readers. Practicing developers would likely agree with the primacy of this list. In fact, in a number of discussions devoted to the topic of `beautiful software’ on the Slashdot Web site (“news for nerds”), most discussants, the majority likely being experienced software developers, identify these same properties. It would seem that the developer’s aesthetic has not changed since Knuth gave his Turing Award lecture more than 30 years ago.

Nearly two decades after receiving the Turing Award, Knuth developed “literate programming,” an approach to program development that has the goal of making writing and reading software more enjoyable [5]. Literate programming turns the traditional approach to programming on its head: instead of a programmer documenting the code, the documentarian embeds code in the document. This allows the programmer to write a program as a narrative, free from the structuring constraints and conventions imposed by a programming language. Knuth created two tools to support this approach: one tool (“tangle”) takes the completed “story” as input and produces compilable code as output, and another (“weave”) produces a typeset version of the story (using TeX, naturally). In terms of Knuth’s aesthetics, literate programming improves a program’s maintainability, readability, and lucidity—properties that are close to the developer’s heart. The best-known instances of literate programming are, not surprisingly, Knuth’s own TeX and Metafont programs. The documented programs are still available in print as The TeXbook and The Metafont Book (see www-cs-faculty.stanford.edu/~knuth/abcde.html#texbk). Widely acknowledged to be beautiful programs, many would modify this description to say these programs constitute works of art produced by an accomplished artist.

Lucidity is often pursued as an aesthetic goal unto itself and, when it is achieved, it can impart the most powerful of all reactions. In this respect, a lucid program exhibits a beauty analogous to the beauty exhibited by a profound mathematical theorem, or theory of physics. Typically, it is the mathematically oriented computer scientists who produce the great works in this genre. Consider Dijkstra’s algorithm to serialize access to shared data by N concurrent processes, shown in Figure 1 [1]. In the figure, b[1:N] and c[1:N] are Boolean arrays of n elements initialized to TRUE, and k is an integer, 1≤kN. This little program not only solves the important problem of synchronizing access to shared data by concurrent processes, but also demonstrates the genius of the program’s author—his deep understanding of concurrency, and his mastery of programming. In reading and comprehending the program, a reader may perceive all of this, in addition to gaining a deeper understanding of concurrency and programming themselves. Certainly, the primary purpose of this algorithm is to solve a problem, but the way in which it does so transcends the practical, resonating with the reader the same way an effective work of art might.

Programming languages have come a long way in helping programmers achieve lucidity. Languages based on mathematical calculi such as ML, Scheme, Prolog, and Occam not only enable the programmer to declaratively state mathematical concepts but, by virtue of the languages’ operational semantics, program execution brings the concepts to life. As an example, Figure 2(a) shows the “insertion sort” algorithm expressed in the Prolog programming language. For mathematicians, this program suffices as a precise description of a sorted list relation in the first-order predicate calculus. However, executing this program actually sorts a list. Let mathematicians try and do that with their paper tigers!

In contrast to the sensible, utilitarian aesthetic considered so far, Knuth also identifies a less pragmatic aesthetic in his Turing Award lecture. In the category of “art for art’s sake,” he discusses the pleasure derived by programmers and readers alike from programs that operate under potentially artificial constraints. As examples, he mentions one-line programs, and programs that, when executed, output a copy of themselves.

The art world abounds with examples of art that are appreciated in light of the challenge the artists face creating the art and how successfully they meet the challenge. Consider, for example, Michelangelo’s Sistine Chapel or Christo and Jeanne-Claude’s “The Gates” in New York’s Central Park. One-line programs and programs that output themselves are no different, although they have had less exposure to the general public.

In Gödel, Escher, Bach: An Eternal Golden Braid [2], Douglas Hofstadter coins the term “quine” to mean, among other things, a computer program that outputs itself. Upon first glance, quines appear deceptively simple but on closer investigation they reveal themselves to be maddeningly self-referential. A particularly parsimonious quine written in the Scheme programming language (author unknown) is shown in Figure 2(b).

In the spirit of one-line programs, the annual Obfuscated C contest invites programmers to contribute C language programs for adjudication by fellow programmers. Programs score points not only in inverse proportion to the program’s size, but also in direct proportion to how difficult it is for the reader to predict what the program will do. Figure 2(c) shows a vexing 1987 award winner from Dave Korn. Another “one-line” program is the subversive “qrpff.pl,” a program in the Perl programming language capturing the deCSS DVD decoding algorithm, written by Keith Winstein and Marc Horowitz in 2000 (Figure 2(d)) [6].

In a similar vein, there are multilingual programs, so-called “polyglots.” A polyglot is a legal program in more than one programming language. Polyglots tend to make cunning use of comments to selectively hide otherwise illegal language constructs. Of the polyglots I’ve found on the Web, the most impressive example is the one by Kevin Bungard, Peter Lisle, and Chris Tham written in 1991 that satisfies seven different language compilers (see www2.latech.edu/~acm/helloworld/multilang.html.

What all these programs have in common is that they are not appreciated in terms of their utility, since they rarely serve a utilitarian purpose. This goes against the grain of the traditional concept of software, and therein lies the art. Instead, these programs are appreciated in terms of the technical mastery shown by their authors—their intimate knowledge of language semantics and quite often the wit suffused in their code. While lacking utility, these programs are technical masterpieces that can only truly be appreciated by those close to the field.

So is it in software’s nature to be forever inaccessible to the general public as an art form? Sharon Hopkins’s poetry shows this does not have to be the case. In 1995, her poem “listen” was published in the Economist magazine1 (see Figure 3) [3]. The poem, a syntactically correct program written in the Perl programming language, can be appreciated not only on a poetic level but also because it casts programming languages in a strange and unfamiliar light. Here, a programming language is used to convey very human sentiments to humans, not to a computer! But why not? A programming language is a language after all, albeit a highly constrained one. As such, it is a perfect medium for the poet comfortable with other highly constrained poetic forms like the sonnet or haiku. By removing software from its familiar utilitarian context to achieve artistic goals, the poem shares much with obfuscated programs, quines, and polyglots. Much more Perl poetry (some good, some bad, like all art) can be found on the Web.

Hopkins introduces us to the notion of the software artist. The software artist uses software in a wholly new way, unlike any of those enumerated by Knuth. In contrast to the programmer-artists we have examined so far, the software artist is, first and foremost, an artist. In the purest sense, artists use a medium to express themselves—all other potential uses of the medium are of secondary importance. When Hopkins uses Perl as a poetic language, she chooses to abide by Perl’s language syntax but ignores its semantics and, instead, uses the semantics of the English language. This might be considered anathema to programmer-artists whose programs always function in some fashion, even if that function might be absurd. Nevertheless, by ignoring the constraints imposed by Perl’s semantics, Hopkins is able to convey her message more freely in a way that is accessible to a large audience. In doing so, her poems also convey another, radical, message directly to the programming community—that software can be harnessed in the pursuit of art, and in doing so, violence may be done to it.


A programming language is a language after all, albeit a highly constrained one. As such, it is a perfect medium for the poet comfortable with other highly constrained poetic forms like the sonnet or haiku.


Doing violence to media in the pursuit of art has a long history. In the history of painting, the introduction of impressionism and, later, of abstraction left many artists and art lovers alike feeling disoriented and even angry. Software as an artistic medium is evolving in a similar way. Initially, there are playful artistic experiments in the form of obfuscated programs, polyglots, and quines. By removing software from its utilitarian context, these experiments serve to highlight the expressive possibilities of the medium beyond those strictly related to function. Conversely, part of their aesthetic impact derives from the fact that their utility plays such a minimal role. Certainly, this is one source of delight of reading Perl poetry.

A program’s utility is just one familiar property associated with the concept of software. Today, denizens of the industrial world are familiar with the concept of software. It is pervasive and hidden within a myriad of devices that one comes in contact with every day. Software controls how the devices behave and how they interact with people. It is logical but frequently bug-ridden. It is susceptible to infiltration and infection. It is software’s familiarity in the popular conscience that is motivating artists to work with it as a medium and, in the fashion of much of contemporary art, software artists are producing works that address the metaphysical “concept” of their medium. A sampling of software art prize winners at recent art festivals provides a good overview of the concepts software artists are currently exploring.

Transmediale is a major annual international media art festival held in Berlin. In 2001, Transmediale became the first festival to offer an award for artistic software with a substantial cash prize of $4,700. The award jury demanded that the “programmes had to be more than purely functional and pave the way for experience going beyond practical applications.” The prize was split between Adrian Ward for his program “Auto-Illustrator” and Netochka Nezvanova for “Nebula.M81-Autonomous.” Of “Auto-Illustrator,” the jury said: “Upon first glance, the Signwave Auto Illustrator is a smooth vector-based graphics programme similar to Adobe Illustrator or Corel Draw. When a user actually employs these tools, they resist the accustomed actions and seem to perform tasks at their own will.” The jury described “Nebula.M81-Autonomous” as “a Web-based Macintosh user application and an aesthetic processor of HTML code retrieved from Web sites, which it turns into animated text, graphics, and sound displays that can partly be influenced by user-triggered parameters.” In 2002, the award was shared by Local Area Network for “TraceNoizer-Disinformation on Demand” and Alex McLean for “forkbomb.pl.” TraceNoizer is a Web application that creates a permanent home page given an individual’s name and email address. The home page is a collage of snippets from existing pages found on the Web that may or may not relate to the individual. The concepts underpinning “forkbomb.pl” may be familiar to system programmers. When executed, this simple Perl script makes copies of itself and executes those copies which, in turn, make copies of themselves and then execute those copies, and so on. Needless to say, a computer executing the script is summarily brought to its knees under the strain of providing the resources necessary to execute so many copies of the program.

The “READ_ME 1.2” international media art festival was held in Moscow in 2002. Devoted solely to software art, the jury solicited “…art whose material is algorithmic instruction code and/or which addresses cultural concepts of software.” The $1,200 prize was split three ways between Mark Daggett for “DeskSwap,” Eldar Karhalev’s and Ivan Khimin’s “Screen Saver,” and Joshua Nimoy’s “Textension.” “DeskSwap” is a screen saver that displays the computer desktop of another DeskSwap user on the Internet, making DeskSwap users privy to one another’s commonly accessed programs, folders, and files. “ScreenSaver” is a set of instructions for intentionally misconfiguring the screen saver of the Microsoft Windows operating system so that it becomes a slowly moving, shimmering, colored curtain. “Textension” is a program that animates user-input text in a variety of enchanting ways, my favorite being bubbles.

What one sees from this sampling of software art is that it addresses, and often confronts, the popular concept of software. In doing so, it highlights software’s role in the machines it occupies and its role in our lives. It also builds upon Knuth’s materialistic characterization of artistic software. While Knuth’s characterization is likely to be familiar only to software developers, the general public can appreciate this conceptual characterization. Programmer-artists may feel disgruntled that their legacy has seemingly been passed over by the artistic establishment; however, it is understandable given the technical background required to appreciate their work. As time passes, the increasing ubiquity of software will engender a more sophisticated understanding of the medium and challenging forms of artistic expression will be appreciated by wider audiences, just as Igor Stravinsky and James Joyce came to be appreciated by wider audiences.

Unlike most artistic media, software is evolving very quickly. From its primitive beginnings as raw binary code only 60 years ago, software artists today have a broad and diverse palette with which to work. Programming languages present increasingly abstract and specialized representations of computation. There are, for example, mathematical, graphical, modeling, object-oriented, mark-up, domain- specific and, let us not forget, literate programming languages. In addition, there are the code processors including compilers, analyzers, translators, virtual machines, pretty printers, and reverse-engineering tools. And then there are the programs themselves, like the indispensable word processor or Web browser, and the insidious virus or worm. There are few other artistic media that offer so many possibilities for self-expression.

In the 30 years that have passed since Knuth first addressed the subject of the art of computer programming, the field has been active but remained static in scope. With the artistic community just beginning to explore the medium, programmer-artists have an opportunity to take part in extending the field’s boundaries, showing what is possible by drawing on a virtuosity that comes only from an intimate relationship with their medium.

Interested readers are encouraged to visit www.softwareaesthetics.com, which includes links to material related to software art and software aesthetics.

Back to Top

Back to Top

Back to Top

Back to Top

Figures

F1 Figure 1. Dijkstra’s mutual exclusion algorithm for the ith process, 1≤iN.

F2 Figure 2. (a) The insertion sort algorithm in Prolog; (b) A quine in Scheme; (c) Dave Korn’s 1987 “Best One Liner” award winner; (d) Keith Winstein’s and Marc Horowitz’s “qrpff.pl.”

F3 Figure 3. Sharon Hopkins’s “listen.”

Back to top

    1. Dijkstra, E.W. Solution of a problem in concurrent programming control. Commun. ACM 8, 9 (Sept. 1965).

    2. Hofstadter, D.R. Gödel, Escher, Bach: An Eternal Golden Braid. Penguin Books, 1980.

    3. Hopkins, S. The Economist. (June 19, 1995).

    4. Knuth, D.E. Things a computer scientist rarely talks about. In CSLI Lecture Notes, Number 136. Center for the Study of Language and Information, Stanford, CA, 2001.

    5. Knuth, D.E. Literate programming. In CSLI Lecture Notes, Number 27. Center for the Study of Language and Information, Stanford, CA, 1992.

    6. Wired, issue 9.06 (June 2001); www.wired.com/wired/archive/9.06/mustread.html?pg=6.

    1 Reprinted here with the permission of the author.

Join the Discussion (0)

Become a Member or Sign In to Post a Comment

The Latest from CACM

Shape the Future of Computing

ACM encourages its members to take a direct hand in shaping the future of the association. There are more ways than ever to get involved.

Get Involved

Communications of the ACM (CACM) is now a fully Open Access publication.

By opening CACM to the world, we hope to increase engagement among the broader computer science community and encourage non-members to discover the rich resources ACM has to offer.

Learn More