10 Programming as Art
Ernest Edmonds
10.1 Art and Programming
The computer enhances the artist’s ability to shape the underlying structures of artworks and art systems. This is because the computer enables us to define the structure and organization of data in a new way. We are able to define the dynamics of that data: how it changes and develops in time and as a result of interactions with the world. As a result, artists can define the underlying structures that they are concerned with and let the computer system put them into practice. The computer enables the artist to work at the level of structure and organization, leaving the realization to automatic processes.
Computer systems are used in art practice in many different ways, as discussed in chapter 2. Sometimes the computer and its software provide a tool for the artist to work with. At other times it is best seen as a medium in which the artwork is formed. A tool is used to make a task easier, whereas a medium is the substance in which an artwork is made.
In the case of the tool, it might extend capability or it might simply make the artist’s task less difficult. On the other hand, in the case of a new medium, the computer may be used to create new art forms. When the computer is seen as a new medium, the artist often needs to use the full capability of the machine by writing programs. Although a computer-based tool might come in the form of a packaged application that requires no programming to be done, our concern in this discussion is with computer systems used as a medium and with programming undertaken as a central part of art making.
Through the advent of computer programming, new concepts and constructs have become available in ways that enable new forms in art. One significant concept is generative art, discussed in chapter 2 and, for example, in the collection edited by Paul Brown (Brown 2003). Here, artists specify their intentions and a computer program builds the artwork from that specification. Many new possibilities arise from this development and challenges also present themselves. One such challenge is to find appropriate methods and notations in which to represent the specification of the artwork. These specifications amount to programs, subject to the condition that they completely describe the generative processes involved.
The computer scientist Donald Knuth famously promoted programming as an art. In fact, he titled his much-read technical compendium The Art of Computer Programming (Knuth 1973–1998). Knuth was concerned with a thorough, precise, and clean approach to writing computer programs of quality. He considered this an art. Whether the word “art” is thought to be appropriate or not, programming is certainly a skill and has much in common with craft, as I discuss in the next section.
Knuth’s concern goes beyond considering just how the code looks, in terms of a neat layout and so on. Knuth’s concern includes also how attractive it is in its organization, efficiency, and structure. Programming is mostly done by software engineers, who are deeply concerned with the technical and functional aspects of their work. However, the design process that they use has strong aesthetic values. If the resulting code control structure looks like spaghetti, for example, it is not highly rated even if it performs its functions perfectly. In many ways the aesthetics of software design are derived from the aesthetics of formal mathematics, in which brevity, elegance, and clarity are much admired.
Today, the majority of software is probably interactive. Hence, integral with the design of the algorithms is the design of the interactions that the user will have with the system. This does not change the core nature of the art of programming, but it does extend the range of the issues of concern. Our desire for elegance (for example) in the algorithms and their expression in the code is extended to an additional desire for elegance in the interaction design and its expression in the code.
As with programming, concerns for the aesthetics of interaction design go beyond user interface presentation. The issues are to do with the abstract representation of interaction processes and the realization of those representations in software architectures and code. This area has been widely discussed in the field of human-computer interaction. A review of much of the foundation work is contained in the book The Separable User Interface (Edmonds 1992).
Interaction design is, of course, important for many artists working in this field but we consider the broader issue of programming in general, interactive or otherwise. Generative artists write programs of primarily one kind or another. Although they certainly practice the art of programming, they may be seen, more significantly, to be turning computer programs into art.
All is not simple or clear in the world of generative art, however. As Florian Cramer puts it, “While software, i.e. algorithmic programming code, is inevitably at work in all art that is digitally produced and reproduced, it has a long history of being overlooked as a conceptual and aesthetic factor” (Cramer 2001, 8).
Cramer’s point is that we tend to look at art produced with digital means as if the digital programming is a minor technical part of it. In fact, programming is at the center of such work. Digital art cannot exist without programming, and the concepts that underlie programming, such as the use of variable values, differentiate such art from other forms.
The Internet and, in particular, the rapid growth in the central importance of the World Wide Web, social communication software, YouTube, and so on, to many people has an impact on art as well as on other aspects of life. The implications were discussed, even before much of this technology existed, by Roy Ascott, for example (Ascott 1966). Artworks that encourage audience participation over the Internet are common today. These involve both the modification and the contribution of material to the structures that artists have provided. To date, the collective aspect has not normally involved programming—that has been retained in the artists’ territory. However, the concepts of open source software, in which everyone is free to modify or add to the code, have attracted artists and point toward a new art form, involving collective programming, that may soon emerge.
10.2 Craft and Programming
We normally consider craft to be an activity that is very much involved with the use of our bodies and, in particular, the hand (Boden 2010). In this respect, programming can hardly count as a craft; however, many characteristics are common to programming and craft. As Boden remarks, “Craftsmen focus on the execution and perfection of their skills” (Boden 2010), which is certainly what programmers do. In fact, Richard Sennett goes so far as to say, “Craftsmanship cuts a far wider swath than skilled manual labour; it serves the computer programmer, the doctor and the artist” (Sennett 2008). However, he goes on to make the more widely accepted point that craftsmanship “focuses on the intimate connection between hand and head” but then says that “the Linux system is a public craft,” by which he meant that, as open software, it is free for everyone to work on, changing, extending and improving it. It is crafted by the public, one might say, although Linux’s public is a very select group of experts, of course.
In any case, it is quite clear that programming requires significant skill and considerable attention to detail. All of Sennett’s dimensions of skill, commitment, and judgment play a significant role. The Arts and Crafts movement may not be one that happily embraces machinery and certainly is not a movement that one would link to modern computing (see chapter 7). Nevertheless, the use of computer programming in art practice is closely connected to the broader notion of craft.
Although the use of computer-based tools, such as painting systems or photograph-manipulation applications, might be seen by some as an easy way of making art, the medium that includes a central role for programming is certainly not. Learning how to program in the first place is a serious undertaking, for which people often follow formal courses. Once learned, the skill of programming requires considerable attention to detail and often depends on experience to succeed.
Most obviously, programming requires that one undertake a significant degree of abstraction from the physical world. This alone makes it quite hard for some people. Second, the detail of the descriptions that must be provided is considerable and beyond anything that we are used to providing when we give instructions to human helpers.
Beyond these issues, however, it is also necessary to take many possible eventualities into account. These include everything from unavoidable problems, such as the need to recover after a power failure, to unexpected circumstances, such as unplanned changes in the lighting when analyzing images. It is also quite normal for hardware and systems software (that software that comes with a computer to enable it to work) to have faults in them. Programmers are used to looking for such faults and finding work-arounds that avoid them.
Computer programming within art making introduces a new skill and certainly matches the earlier skills with which we are familiar, such as carving, drawing in perspective, or impasto painting. The art, of course, relies on the skill but is something else beyond it. This is as true of computer-based artworks as it is of oil painting. We see in the use of programming within art practice, however, what might be considered to be a revival of the central role of craft, or at least skill, in art, a revival because the importance of skill was explicitly denied by the Conceptual artists of the 1970s.
In sum, computer programming is quite hard, has many features of craft in it, and when used in art making, is often of central importance to the nature of the work produced.
10.3 Art Theory and the Implications of Software
How programming has affected art and art theory is important to understand. This new medium has encouraged experiments and investigations both in practice and in theory. Jack Burnham was an extremely important early theorist in the area of software as art. “He conceived of ‘software’ as parallel to the aesthetic principles, concepts, or programs that underlie the formal embodiment of the actual art objects, which in turn parallel ‘hardware’ ” (Shanken 2002).
In making an artwork through writing a computer program, the artist might be seen to be describing, in the program, the core concepts or principles of the work. The program contains a complete description of the arrangements—timing and dynamics, for example—that are to be used. Of course, certain aspects will be excluded, such as the size of the screen or the color of any physical structure (a frame, for instance) that forms part of the work. The parts of the work that are essentially digital are specified within the computer program. Even if pseudorandom numbers or interactions with the world are used, how they are used has to be fully stated within the program.
Edward Shanken (2002) explains a key implication for art practice of the use of programming: “Here meaning and value are not embodied in objects, institutions, or individuals so much as they are abstracted in the production, manipulation and distribution of signs and information.”
Burnham saw very significant implications for art in the developments of information technology. In particular, he saw art as being redefined by making systems, rather than objects, the central concern.
Information processing technology influences our notions about creativity, perception and the limits of art. … It is probably not the province of computers and other telecommunications devices to produce works of art as we know it, but they will, in fact, be instrumental in redefining the entire area of esthetic awareness. (Burnham 1970a, 11)
Specifically, he asserted that the “central thesis of my book … is that we are moving from an art centered upon objects to one focused upon systems” (Burnham 1969).
In this sense, a system is a collection of interacting entities that can be completely abstract. A computer program is a description of a set of abstract entities, signs, variables, or numbers and their relationships: a definition of a system. Systems of this kind are not new for artists. Perspective is a very familiar example of a system used in art. However, the computer program is of a new level of complexity and so has made us much more focused on the systems aspect of art. Burnham recognized that it was not altogether new. In an interview, he drew a specific parallel between the concerns of the programmer and those of the artist in which he mentions the computing concept of recursion, wherein something refers to itself: “All this business about recursion … and I thought to myself, you know, this is the way artists think” (Dammbeck 2001).
So we might say that the computer has led to a greater concern for the systems aspect in art making, and the center of this concern is in the task of programming. To return to the computer science viewpoint discussed earlier, John von Neumann (1956) said, concerning mathematical theorems, “One also expects ‘elegance’ in its ‘architectural’ and structural makeup. These criteria are clearly those of any creative art.”
10.4 Conceptual Art and Software
In visual art—for example, painting—the artist works directly with the materials that form the final work. In traditional Western music, on the other hand, the composer will normally work with a score, which is an abstract representation of her or his intentions. The adequacy of such representations largely depends on the composer’s ability to mentally map the notation to sound. Such mappings are difficult and sometimes very complex but, nevertheless, are direct and one to one. They are specified in a presentation notation, the process being an implicit linear progress in time. The one-to-one nature of the notation used makes it relatively easy to move between abstract and concrete representations of the music. However, this exact mapping between representations does not apply to generative art.
As explained in chapter 9, perhaps the most obvious starting point for generative art was in the discussions of the General Working Group of Objective Analysis in 1921 in Moscow (Lodder 1983). This was the beginning of the art movement generally known as Constructivism. The group drew a distinction between composition and construction in making their art. Briefly, composition was seen to be about arranging forms according to relationship rules, and construction was about making a work according to a plan for its production. The discussions of the group were complex, and its members did not all take the same position. It is probably best understood through Maria Gough’s careful analysis of the composition-construction drawing pairs that the group made (Gough 2005). For our concerns, however, the key point was the introduction of the notion of making a visual art work according to a plan rather than by the application of rules of composition. In 1921, of course, the plans were executed by the artists themselves, but in generative art they are executed by computers.
The art theorist Nelson Goodman drew an important distinction between what he called notional and non-notional works of art. He argues that any sequence of letters in a novel for example, that corresponds with the original text is a genuine instance of the work. One might say that the essence of the novel is not the book object at all. It is in the notional object that we access through the book (Goodman 1978). He drew a distinction between execution and implementation, such as the writing of a novel and its implementation as a book (Goodman 1982). The parallel with programming a work of art and realizing it physically is easy to draw. From this point of view, we can see that art that involves significant programming is more conceptual than, for example, traditional painting.
Conceptual art is, of course, a significant movement within twentieth-century art (Alberro and Stimson 1999). Sol LeWitt made clear contributions to the practical realization of such art that made full use of the execution-implementation distinction without using software. “In conceptual art the idea of concepts is the most important aspect of the work. … The idea becomes a machine that makes the art” (LeWitt 1967).
The idea, the system, the concept, or the computer program can be thought of as invisible, which must be seen to be important, Burnham argues, using Hans Haacke as an example: “In a systems context, invisibility, or even invisible parts, share equal importance with things seen” (Burnham 1968).
For example, Haacke’s piece Photo-electric Viewer Programmed Coordinate System reacted to its environment, and in the artist’s view, the invisible behavioral system was as important as the physical object (Haacke 1968).
Of one artist, Burnham said, “I suggested … that his pages of computer data … were more intriguing than the resulting sculpture” (Burnham 1970b). This was not intended as a criticism of the sculptural object but as an assertion of the importance of the system that it rested on.
The boundaries of art are changed by the advent of software. In practice, the software itself becomes a key component of the art (if not its core) and the art object becomes the implementation of the work in Goodman’s meaning. In this sense, art becomes more conceptual than before. Burnham even predicted that
the traditional notion of consecrated art objects and settings will gradually give way to the conclusion that art is conceptual focus, and that the boundary conditions of form as process and system transcend the more literal notions of geometrically defined form. (Burnham 1970b)
The art in software is increasingly recognized (Fishwick 2006). Software, the computer program, in art has been underrated, however. The computer artist’s challenge is software, not because it is difficult, but because it is the conceptual representation of the new art.
How an idea, concept, or instruction is represented has a significant bearing on both the ease with which we can understand it and its precise meaning. Some things are easier to say in French than in English: “See you later” might be close to “Au revoir” but does not have quite the same meaning. The nature of the representations in which programs can be expressed is important.
Computer programs are descriptions of instructions to be followed by the machine. Through the development of methods for providing such descriptions, very many programming languages have been devised, and quite a few different approaches to the issue have arisen. These approaches amount to different ways of representing sets of instructions. There is no universal best representation. Rather, different representations are convenient for different purposes.
Pioneering artists, such as Harold Cohen or Manfred Mohr, have used various programming languages as their work has developed, but the choice has rarely been arbitrary. In recent computer-based artwork, such as live coding, in which digital musicians write and modify programs during a performance, an appropriate representation is vital (Brown 2006) as discussed in chapter 12. A survey of the full range of approaches used is beyond the chapter’s scope, but in the next section, I present a brief review of approaches I have used as an indication of the variety of methods that can be employed.
10.5 Representations: A Personal History
Given that software is important for art, then the precise nature of software needs to be understood. In this section, the representation needs of generative art are considered, and I review a few examples from my personal experience. Three main approaches are covered: procedural, logical, and graphical. No one of these entirely fulfills the needs but each has a significant role to play. My own approach to generative art making provides the basis for all the work discussed.
10.5.1 Generative Composition
In generative art, such as my video constructs (Edmonds 2005), the composition is notated as a set of rules, constraints, or logical structures, and a computer program automatically generates the artwork using them. There is an important distinction between the structures that define the work’s progress in time and the mappings (Doornbusch 2002) from those structures to specific images and sounds. Whereas the former are not necessarily perceivable in the art object, the mappings directly result in the artwork as seen or heard. The terms “process notation” and “presentation notation” distinguish between the two distinct representations that correspond to defining the progress in time and the mappings, respectively.
In generative artworks, the representations that artists create specify the rules that must be used in the process of realizing the work. These rules may be of many forms, such as instructions to follow, constraints (things to avoid), or contingencies (rules about what to do should some specific event occur). But in all cases they cannot be mapped by a simple one-to-one relationship onto the concrete artwork. Instead, they must be used together with some well-defined process, normally a computer program, to make the work. For example, the specification of a piece of music might be as a set of rules that govern the evolution of a given life game (Gardner 1970). It is specified in a process notation. This can give us the structure of the work, but then a one-to-one mapping must also be defined so as to select which sounds and sound features relate to the aspects of the structures.
For this reason, two forms of representation are required for generative works, both a presentation and a process notation. One notation relates abstract entities, which could be letters or numbers, to colors, shapes, sounds, or other physical attributes of an artwork. The other notation specifies the rules by which the generation process should proceed. This second type of notation could, for example, be an algorithm that leads to a drawing or a process that produces an infinite piece of music. Whereas the implications of the first can be inspected and reviewed by placing the notation next to the physical elements, a list of numbered colors, for example, the second has a more distant relationship to the final work. In generative art the artist may truly not know how the work will look or sound in detail until the generative process is performed.
10.5.2 Procedural Representations
In 1968 and in the early 1970s, I used the procedural programming language FORTRAN (Katzan 1978) to implement problem-solving algorithms used in art practice. From this experience, it became apparent by 1980 that the steps in the operation of a program, known as its trace, could be used to define a sequence of events. The process of the program running could be the center of interest rather than the result that the program came up with. Thus, a computer program could be used to define a generative process for a time-based work. A significant issue was to find appropriate ways in which to specify work of this kind.
At around this time the Atari 400 and 800 computers appeared on the market.1 They had, for their time, significant computer graphics capability built into their firmware. This could be accessed from the languages that were available for the machine. The key programming language available was BASIC. In some respects, of course, this was not unlike FORTRAN. However, there were also significant differences.
One difference was that BASIC was an interpreted language rather than a compiled one.2 Interpreted representations seemed then, as they have since proved, to be extremely important in supporting creative system development. Just as the composer often sits at the piano and switches frequently between writing a score and listening to the equivalent sounds, so this flexibility of an interpreted language allows the artist to switch at will between composition and execution. All the representations that I used after BASIC have this property.
Another difference that applied to the Atari version was the integration of computer graphics functions. These were very significant for the production of generative visual work because it was possible to specify an algorithm that produced or modified graphical objects on the screen, as it was executed, instruction by instruction. Almost certainly, the main intention of the developers of this version of BASIC was to enable programmers to construct static images and graphical user interfaces. However, because the changes to the images were made after each graphical instruction was executed, it was a system in which a time-based generative work could be specified in terms of the execution of a program.
In the Atari BASIC representation, the presentation notation was direct and intuitive. The process notation, however, was that of a procedural programming language3 and hence was weak in expressing the rules that define the generative artwork. In any case, the Atari was limiting, and I found it necessary to move to other machines. I settled on the significant new machine of the time, the Apple Macintosh.
10.5.3 Logic Programming
The next step was to recognize that logic programming4 could be used as a method for handling structures in time and as a more appropriate process notation. It can be used to make generative work in which the rules specified in logic control the form and order of a sequence of images. The sequence can potentially go on forever without loops, depending on the rules. So, for example, an endless series of changing images can result.
In practice, this approach depended on using the logic programming language Prolog (Shapiro and Sterling 1994), which was widely available, including on the Macintosh computer. In Prolog, one writes statements, in something rather like logic, that express the rules that the system must obey. For instance, the rules (expressed in English) may say “If the number X exists, then so does the number X + 1” or “If the line X exists, then the parallel line Y must exist 1 centimeter away from it.” Once a set of such rules has been composed, Prolog can be given the task of trying to find out if something or another is true under those rules. It does this by adding a rule that says that the target fact is false and then looking at the consequences (making deductions using the rules) to see if it can find a contradiction. If it does, then the assumption that the fact is false must be wrong, and so we then conclude that the fact must be true.5 The point here is that, as Prolog works this out, we can follow the program at work or the trace of the steps. In the way that I used Prolog, I defined the rules, posed a question to the system, and used this trace as the process that the artwork follows.
Another concept in Prolog is the side effect. This is an action, such as drawing a line on a screen, that can be linked to the operation of a rule. So our previous parallel-lines rule can be linked to a side effect: “If a line X exists, draw a line Y parallel to it 1 centimeter away.” In this way, I used side effects to define the presentation, or appearance, of the works.
Naturally, a fundamental aspect of this process is coming up with rule sets that characterize both interesting images and interesting transitions between images over time. In my case, I have taken geometric rules that I have used in my art over the years (when working without computers) and coded them into computer programming languages, such as Prolog. These rules deal with issues such as adjacency and also color relationships.
10.5.4 Graphical Representations
A further development has been the integration of audio and visual elements in the generative pieces. At first, the Prolog-based notation was used together with more or less conventional scores for the music. My work with the sound artist Mark Fell has integrated the audiovisual production into a single generative process (Edmonds and Fell 2004). This work has raised new issues in the choice of notation, because of the added complexity, and a new approach has been developed based on the Max/MSP notation.6 The simple presentation notations used previously no longer seemed adequate. This was because of the need to specify both audio and visual elements and, in addition, to specify the sound processing that was to be used so as to effect the specification in real time.
The Max/MSP system is a graphical object-based notation using familiar sound art constructs, such as patching, in its language. It is natural in this notation to provide sound, shape, and color palettes while composing the code to determine exactly how those elements are employed on the screen and through the sound system. In this way, the presentation notation itself is divided into two parts: the palettes and the realization methods.
Max/MSP, on the other hand, does not include any logic programming constructs. However, it has not proved difficult to add appropriate elements to the system so that the equivalent to the earlier logic programming process notation can be incorporated into the Max/MSP environment.
One of the most attractive aspects of language systems like Max/MSP is that a program can be changed as it is running, so that programmers can obtain immediate feedback as they try out different ideas. Of course, in classic approaches to programming this facility is frowned on, on the basis that everything should be determined before a program is written. However, in creative uses of software there is often an intimate intertwining of designing the program and seeing the implications of a design decision. This is a point that we see more of in chapter 14, when interviews with ten artists who write code are presented.
10.6 Conclusion
It is very instructive that computer scientists consider programming an art. They see aesthetic issues as significant ones for their work. It is not altogether surprising from that point of view that programs can be seen as art. The important point, however, is that software art is a radical and relatively new step forward for art. Notwithstanding much said here, software art does not remove the importance of art objects any more than an understanding of the executed object that is a novel reduces the importance of a book. Rather, software art adds a conceptual dimension to art that changes the focus from a largely object-oriented one to a broader and perhaps deeper systems-oriented one.
Art is all the richer for embracing software, but in so doing, the challenge to artists is to be at least as deeply involved in software as in any other aspect of their practice. There are many ways of writing code, and each way has different implications for the creative process. Programming is as much a new skill, or new set of skills, for the artist to choose and master as it is in many other walks of life.
______________
1. See “Atari 400,” Obsolete Technology (website), updated May 7, 2016, http://
2. An interpreted language is used by the computer in the form in which it is written and acted on (interpreted) line by line as the program runs. When a program is written in a compiled language, on the other hand, the whole program is translated into the computer’s internal code before it is run. The distinction is, in practice, rather more blurred than this, but this describes the principles behind the difference.
3. A procedural programming language is one in which the actions that the computer is required to perform are specified step by step.
4. Logic programming language provides a set of sentences in a variant of formal logic that expresses facts and rules, without any explicit information about the steps to be taken.
5. This may sound a little like a twisted argument, but it is soundly based on the idea that a set of true statements cannot imply a contradiction. It also requires the belief that each fact is either true or false. Although this seems simple enough, it is not always accepted in practice—but we leave that for another debate.
6. See “Max Connects Objects …,” Cycling ’74, accessed August 13, 2014, http://
References
Alberro, A., and B. Stimson. 1999. Conceptual Art: A Critical Anthology. Cambridge, MA: MIT Press.
Ascott, R. 1966. “Behaviourist Art and the Cybernetic Vision.” Cybernetica 9:247–264.
Boden, M. A. 2010. “Crafts, Perception and the Possibilities of the Body.” In Creativity and Art: Three Roads to Surprise, 50–69. Oxford: Oxford University Press.
Brown, A. 2006. “Code Jamming.” M/C Journal 9 (6). http://
Brown, P., ed. 2003. “Generative Computation and the Arts.” Special issue, Digital Creativity 14 (1).
Burnham, J. 1968. “Systems Esthetics.” Artforum 7 (1): 30–35.
Burnham, J. 1969. “Letter: Art’s End.” New York Review of Books, November 20. http://
Burnham, J. 1970a. “Notes on Art and Information Processing.” In Software Information Technology: Its New Meaning for Art, edited by J. B. Burnham, 10–14. New York: Jewish Museum.
Burnham, J. 1970b. On the Future of Art. New York: Viking.
Cramer, F. 2001. “Software Art and Writing.” American Book Reviews 22 (6): 8.
Dammbeck, L. 2001. “Excerpts from an Interview with Jack Burnham.” October 17. http://
Doornbusch, P. 2002. “Composers’ Views on Mappings in Algorithmic Composition.” Organised Sound 7 (2): 145–156.
Edmonds, E. A., ed. 1992. The Separable User Interface. London: Academic Press.
Edmonds, E. A. 2005. On New Constructs in Art. Forest Row, UK: Artists Bookworks.
Edmonds, E. A., and M. Fell. 2004. “Broadway One.” In Electronic Art and Animation Catalogue, SIGGRAPH2004, edited by Sue Gollifer, 30. New York: ACM Press.
Fishwick, P. A., ed. 2006. Aesthetic Computing. Cambridge, MA: MIT Press.
Gardner, M. 1970. “The Fantastic Combinations of John Conway’s New Solitaire Game of ‘Life.’ ” Scientific American 223 (4): 120–123.
Goodman, N. 1978. Ways of Worldmaking. Indianapolis, IN: Hackett.
Goodman, N. 1982. “Implementation of the Arts.” Journal of Aesthetics and Arts Criticism 40:281–283.
Gough, M. 2005. The Artist as Producer: Russian Constructivism in Revolution. Berkeley: University of California Press.
Haacke, H. 1968. Hans Haacke. New York: Howard Wise Gallery. Exhibition catalog.
Katzan, H. 1978. Fortran 77. New York: Van Nostrand Reinhold.
Knuth, D. E. 1973–1998. The Art of Computer Programming. Reading, MA: Addison Wesley.
LeWitt, S. 1967. “Paragraphs on Conceptual Art.” Artforum 5 (10): 79–84.
Lodder, C. 1983. Russian Constructivism. New Haven, CT: Yale University Press.
Neumann, J. von. 1956. “The Mathematician.” In The World of Mathematics, edited by J. R. Newmann, 2053–2063. New York: Simon and Schuster.
Sennett, R. 2008. The Craftsman. London: Allen Lane.
Shanken, E. A. 2002. “Art in the Information Age: Technology and Conceptual Art.” Leonardo 35 (4): 433–438.
Shapiro, E., and L. Sterling. 1994. The Art of Prolog: Advanced Programming Techniques. 2nd ed. Cambridge, MA: MIT Press.