Information
Technology
Software
Shockwave
Descriptions & Essays
click here to launch the project >
Java Applet
ADA Editor 16-06-2015
Artist statement Antoine Schmitt
"Showing the code of my programmed artworks is something that I never do. If I was a painter, I would not show my studio, my paint and my paintbrushes: I would show my paintings. I believe that in programmed art, the produced artwork is the execution of the program, not the text (the code) that it is made out of.
Of course, an artist-programmer can show his code alongside his artwork; it is the artist's choice, just like showing the scenario and the script notes alongside a finished movie can be an artistic posture in itself. This is what Alex McLean did with forkbomb.pl: it was confrontation of the simplicity of the program to its dramatic results that was the artwork. If the code had not been shown, it would not have been interesting at all. This is also what Alex Galloway did in CODeDOC I: it was showing the dangerous code and *not* executing it that created the artwork.
But this is not my artistic position. I am interested in this very specific feature of programmed artworks: they act on the world. As an artist-programmer, this is what I do: I create actions and I show them. I don't show the material that helped me create them. I dont think that it is of artistic interest.
But the CODeDOC exhibition series is about demystifying the programming process behind the art. So like in a documentary, I decided to play the rules of the game of the curator. I think that it is very important to demystify programming: there is just too much fascination with it in the art world, just like there is too much fascination with (computer) technology. I believe that we are at a point in time equivalent to the invention of the woodblock printing by Gutenberg: all of a sudden, a technology (writing and reading) that was mastered only by Religion was accessible to everyone. Nowadays, a technology (programming) that was mastered only by today's religion (Business and Finance) is slowly accessible to everyone, thanks especially to the OpenSource movement. I am sure that in the future this is going to lead to unimaginable new works of all kinds, in all fields (artistic, but also political, economic, philosophical, etc.). But for now, everyone is reacting to this liberation of programming. And this leads to all sorts of misunderstandings, false truths, rumors, myths, fear and fascination. There are just too many artwork descriptions that look like a cut-up of a system engineer's college manual. Obscurantism reigns. An initiative like CODeDOC may help reduce this obscurantism, and this is why I show one of my programs here, heavily commented.
I also want to take a few precautions so that this exhibition does not distort the public's idea of programmed art:
- there is a good chance that when asked to show their code, artists will have the tendancy to "clean it up" (I did). So the shown programs will be clean, in the programming sense. But a clean program does not necessarily make a good artwork. I have been a programmer for 25 years, and I have seen everything in the relationship between a program and its result : awfully written programs that are absolutely the best at what they do, and very clean programs that are very bad at what they do. The "cleanness" of a program is a value only in an engineering environment: for economic reasons, a program needs to be efficient, maintainable, readable, modularisable, portable, etc. But dont be mislead, all these values are not what makes a good artwork.
- the second wrong idea is about virtuosity. Some artist programmers may be inclined to show programming virtuosity in their code (I did not): using memory tricks, insider's knowledge, compact code, advanced langage features, etc. While this is entertaining and educational for other programmers, it may induce another distorded idea: that virtuosity is important when making programmed art. Like in most art (except performance art), this is not true with programmed art.
I would not like CODeDOC to (unconsciously and despite all its good intentions) somewhat create a link between good craftmanship or programming virtuosity and artistic value, so I say it again here: a program is what it does, not how it is written, even and especially in the art world.
And finally, I want to clarify the assignment's assertion that "Every medium may have its specific language but in digital art, this language has a quite literal rather than figurative manifestation. The visual results of an artwork are derived from the language of code." This phrase creates a shortcut that is misleading: the langage in which the programmed artwork is written has nothing to do with the language of programmed art. It would be like saying that English (the langage in which scenarii are written) has something to do with the language of cinema. The language of the programmed artworks has yet to be created, we are at the beginning of an era and this language will arise slowly with the history of programmed art. And it will have nothing to do with the language in which the programs are written, it will have to do with what the artworks do, it will be about space, time and mostly action.
Christiane Paul: You are right, the sentence you are quoting could indeed be misleading, and I'm very glad you are pointing this out. There are in fact many different layers of language at work here, and I failed to make proper distinctions between them. One layer consists of the programming language (with its 'rules' and 'grammar'); another one is the 'creative writing' process of the code and the individuality of expression it entails (which is what the sentence above was meant to refer to); and there is the 'aesthetic language' of the code's actions and its behavior in time and space - comparable to the language of painting or cinema. It would be wrong to equate the programming language or the artist's writing with 'the language of software art,' which is a much broader repertoire of expression, and I certainly did not mean to do that.
Despite all my nitpicking and warnings, I want to thank Christiane Paul and the supporters of CODeDOC for helping widen the audience and the intelligence around programmed art, and for leaving this 'comments' space open for the artists' point of views."
ADA Editor: Threesome, 16-06-2015, in: Archive of Digital Art Artist statement Antoine Schmitt
"Showing the code of my programmed artworks is something that I never do. If I was a painter, I would not show my studio, my paint and my paintbrushes: I would show my paintings. I believe that in programmed art, the produced artwork is the execution of the program, not the text (the code) that it is made out of.
Of course, an artist-programmer can show his code alongside his artwork; it is the artist's choice, just like showing the scenario and the script notes alongside a finished movie can be an artistic posture in itself. This is what Alex McLean did with forkbomb.pl: it was confrontation of the simplicity of the program to its dramatic results that was the artwork. If the code had not been shown, it would not have been interesting at all. This is also what Alex Galloway did in CODeDOC I: it was showing the dangerous code and *not* executing it that created the artwork.
But this is not my artistic position. I am interested in this very specific feature of programmed artworks: they act on the world. As an artist-programmer, this is what I do: I create actions and I show them. I don't show the material that helped me create them. I dont think that it is of artistic interest.
But the CODeDOC exhibition series is about demystifying the programming process behind the art. So like in a documentary, I decided to play the rules of the game of the curator. I think that it is very important to demystify programming: there is just too much fascination with it in the art world, just like there is too much fascination with (computer) technology. I believe that we are at a point in time equivalent to the invention of the woodblock printing by Gutenberg: all of a sudden, a technology (writing and reading) that was mastered only by Religion was accessible to everyone. Nowadays, a technology (programming) that was mastered only by today's religion (Business and Finance) is slowly accessible to everyone, thanks especially to the OpenSource movement. I am sure that in the future this is going to lead to unimaginable new works of all kinds, in all fields (artistic, but also political, economic, philosophical, etc.). But for now, everyone is reacting to this liberation of programming. And this leads to all sorts of misunderstandings, false truths, rumors, myths, fear and fascination. There are just too many artwork descriptions that look like a cut-up of a system engineer's college manual. Obscurantism reigns. An initiative like CODeDOC may help reduce this obscurantism, and this is why I show one of my programs here, heavily commented.
I also want to take a few precautions so that this exhibition does not distort the public's idea of programmed art:
- there is a good chance that when asked to show their code, artists will have the tendancy to "clean it up" (I did). So the shown programs will be clean, in the programming sense. But a clean program does not necessarily make a good artwork. I have been a programmer for 25 years, and I have seen everything in the relationship between a program and its result : awfully written programs that are absolutely the best at what they do, and very clean programs that are very bad at what they do. The "cleanness" of a program is a value only in an engineering environment: for economic reasons, a program needs to be efficient, maintainable, readable, modularisable, portable, etc. But dont be mislead, all these values are not what makes a good artwork.
- the second wrong idea is about virtuosity. Some artist programmers may be inclined to show programming virtuosity in their code (I did not): using memory tricks, insider's knowledge, compact code, advanced langage features, etc. While this is entertaining and educational for other programmers, it may induce another distorded idea: that virtuosity is important when making programmed art. Like in most art (except performance art), this is not true with programmed art.
I would not like CODeDOC to (unconsciously and despite all its good intentions) somewhat create a link between good craftmanship or programming virtuosity and artistic value, so I say it again here: a program is what it does, not how it is written, even and especially in the art world.
And finally, I want to clarify the assignment's assertion that "Every medium may have its specific language but in digital art, this language has a quite literal rather than figurative manifestation. The visual results of an artwork are derived from the language of code." This phrase creates a shortcut that is misleading: the langage in which the programmed artwork is written has nothing to do with the language of programmed art. It would be like saying that English (the langage in which scenarii are written) has something to do with the language of cinema. The language of the programmed artworks has yet to be created, we are at the beginning of an era and this language will arise slowly with the history of programmed art. And it will have nothing to do with the language in which the programs are written, it will have to do with what the artworks do, it will be about space, time and mostly action.
Christiane Paul: You are right, the sentence you are quoting could indeed be misleading, and I'm very glad you are pointing this out. There are in fact many different layers of language at work here, and I failed to make proper distinctions between them. One layer consists of the programming language (with its 'rules' and 'grammar'); another one is the 'creative writing' process of the code and the individuality of expression it entails (which is what the sentence above was meant to refer to); and there is the 'aesthetic language' of the code's actions and its behavior in time and space - comparable to the language of painting or cinema. It would be wrong to equate the programming language or the artist's writing with 'the language of software art,' which is a much broader repertoire of expression, and I certainly did not mean to do that.
Despite all my nitpicking and warnings, I want to thank Christiane Paul and the supporters of CODeDOC for helping widen the audience and the intelligence around programmed art, and for leaving this 'comments' space open for the artists' point of views."
Literature

Paul, Christiane. »CODeDOC II: curator's statement.« http://www.aec.at/CODeDOCII.
Exhibitions & Events