Regarding Conceptual and Aesthetic Implications of Code in Computer-based Art

Posted by Pall Thayer | Mon Mar 17th 2008 10:50 a.m.

disclaimer: I tried posting this to discuss directly from Google docs but it didn't show up. If it all the sudden appears in your mailboxes multiple times, I'm sorry.

This weekend I delivered a short paper at the Helsinki Pixelache festival. It was sort of a preliminary delivery as I still think that the way I'm presenting the ideas could use a bit of polish (yes, that's polish, not Polish). So what I've decided to do as a bit of an experiment is to post the paper to Google Docs and am now inviting anyone within the Rhizome community to edit the paper or just drop in some comments. The link is:

http://docs.google.com/Doc?id=dcdsc8mn_2ft6j9scr&invite=hbk8dhb

best r.
Pall Thayer
  • Pall Thayer | Mon Mar 17th 2008 10:55 a.m.
    PS... if you're interested in reading the original paper without any edits but my own, the link is here:

    http://docs.google.com/Doc?id=dcdsc8mn_4d49x8ddj&invite=fs982fw
  • damian stewart | Mon Mar 17th 2008 2:42 p.m.
    hey, that's a nice approach.

    the thing is, i fundamentally disagree with your central premise. what we as programmers do with code requires a high degree of technical mastery, it's true. but this isn't something particularly special to do with code as a medium. i don't know anything about welding but i can appreciate a welded sculpture. i don't know anything about painting but i can appreciate a Renaissance painting. (in fact wasn't technique, and particular parts of technical mastery, often a jealously guarded secret in Renaissance times?)

    i also disagree that the code itself is the medium. i think the /runningness/ of the program (for want of a better word) is the medium. i don't look at code-based art to see the code in its raw form, i look at code based art to experience it as running program - to experience this /runningness/.

    lastly, your statement that 'creating artwork with code is, by now, nothing new... way back in 2003' kind of completely ignores the earlier history of code-based artwork. iirc there were some people already making software art in the 1970s...

    just some thoughts, feel free to ignore.

    d
    --
    damian stewart | +351 967 797 263 | damian@frey.co.nz
    frey | live art with machines | http://www.frey.co.nz
  • Pall Thayer | Mon Mar 17th 2008 3:36 p.m.
    Hi Damian, thanks for the comments. I won't ignore because these are ideas I'm actively working on promoting and that I feel quite strongly about. I've met with quite a bit of animosity in discussing the ideas with others and I think it's primarily based on a misunderstanding of my intentions which is why I welcome any and all comments and discussion.

    First of all, I'm not by any means claiming that coded artwork can't be understood or appreciated without regarding the code. I am suggesting that there's another level of understanding to be found within the code. It adds another level to the experience. Also, I'm thinking towards the future. It's easier for us to grasp what this sort of work is about within its contemporary context. But what about 10 to 20 years down the road when someone comes along who wants to really analyze some of the older work in this area? The code provides a very clear window into the artist's conceptual and aesthetic intentions. Also, if we think about preservation, revealing the code provides for a means of preservation that would allow galleries and museums to "re-interpret" the work on future hardware.

    Regarding "the medium" I have a question for you. Why are welding and painting media and not coding? If runningness (I like that term!) is the medium of coded art then how can welding be the medium of an iron sculpture? To me, runningness refers to what a piece does whereas welding refers to how something is created. I see a contradiction there.

    The statement you refer to is not intended to ignore the earlier history of coded art. It simply serves as a convenient means of pointing to a distinct event, that most people in this field are familiar with, where code in art was specifically discussed and analyzed. However, I think it should have been the start of something rather than the start and finish, which is what seems to have happened.

    best r.
    Pall
  • Pall Thayer | Mon Mar 17th 2008 3:44 p.m.
    Oh, and ps. My reference to the 2003 Ars Electronica festival is meant to be a critique on the fact that there was little or no follow-up on the issues; i.e. "Code was neither the language of their time, nor is it ours.
  • damian stewart | Mon Mar 17th 2008 4:50 p.m.
    Pall Thayer wrote:
    > Hi Damian, thanks for the comments. I won't ignore because these are
    > ideas I'm actively working on promoting and that I feel quite strongly
    > about. I've met with quite a bit of animosity in discussing the ideas
    > with others and I think it's primarily based on a misunderstanding of my
    > intentions which is why I welcome any and all comments and discussion.

    i don't know if i've misunderstood your intentions, but i do think you're confusing the medium and/or the process and/or the resulting art object.

    > First of all, I'm not by any means claiming that coded artwork can't be
    > understood or appreciated without regarding the code. I am suggesting
    > that there's another level of understanding to be found within the code.

    understanding of what?

    i don't believe that you can better understand a program's /runningness/ (what it feels like to engage with the program) by examining its code. quite the opposite. i write my own software to make music, and one of the most interesting things about doing this is that often my own software reveals to me things that i didn't even know were there to be found. and after these new possibilities have presented themselves, there's no way i can point to any part of the code and say, this bit happens here. it's the whole system i'm interacting with, not particular parts.

    may i suggest some reading:
    http://mitpress.mit.edu/book-home.tcl?isbn=0262521121

    > The code provides a very clear window into the
    > artist's conceptual and aesthetic intentions.

    no it doesn't. it provides a very clear window into their technical / engineering skills and abilities. like i said above, the aesthetic outcomes don't have a 1-1 relationship with the code. if i don't even know what new aesthetic/creative/phenomenological avenues my code is going to open up when i write it, how can anyone else expect to understand my intentions by reading it?

    > Also, if we think about
    > preservation, revealing the code provides for a means of preservation
    > that would allow galleries and museums to "re-interpret" the work on
    > future hardware.

    if you were an artist working on an iron sculpture would you leave a list of instructions around to allow galleries and museums to 're-interpret' your sculpture using future metals? i don't think such 're-interpretation' is really possible without making new artwork. if you run the same code on different (future) hardware, i expect you'll end up with a different artwork. visual-based code written for a Commodore 64 plugged into a colour TV won't /feel/ the same when you run it on a desktop PC plugged into a plasma monitor, and so it will be a different artwork.

    > Regarding "the medium" I have a question for you. Why are welding and
    > painting media and not coding? If runningness (I like that term!) is the
    > medium of coded art then how can welding be the medium of an iron
    > sculpture? To me, runningness refers to what a piece does whereas
    > welding refers to how something is created. I see a contradiction there.

    my point was the opposite, actually. the process of welding is to an iron sculpture, as the act of painting is to the final painting you hang on the wall, as the act of coding is to the resultant software art. iron is the medium in the first, painting is the medium in the second, software/'runningness' is the medium in the third.

    > The statement you refer to is not intended to ignore the earlier history
    > of coded art. It simply serves as a convenient means of pointing to a
    > distinct event, that most people in this field are familiar with, where
    > code in art was specifically discussed and analyzed. However, I think it
    > should have been the start of something rather than the start and
    > finish, which is what seems to have happened.

    perhaps there was nothing to discuss?

    i just don't think the code is interesting from anything other than an engineering perspective; and there's nothing intrinsically special about software engineering that makes it so fundamentally different from mechanical engineering or any other kind of engineering used for artistic purposes.

    --
    damian stewart | +351 967 797 263 | damian@frey.co.nz
    frey | live art with machines | http://www.frey.co.nz
  • Pall Thayer | Mon Mar 17th 2008 6:54 p.m.
    I think one of the primary differences in our views on these issues is that, based for instance on this comment, "i write my own software to make music..." you're talking about software that you use to make art whereas I'm talking about software that is art in its own right. It doesn't PRODUCE art work, it IS artwork.

    I also think you're looking at the idea of "code" from a much-too-strictly engineer's perspective. I don't think a lot of the artists who write their own code approach it in as orderly a manner as people who have formal, professional training in computer programming. This is just based on personal experience, teaching and discussions with other artists but I don't think artists are that concerned with displaying technical skills and abilities at the code level. The software isn't so much "engineered" as it is shaped and beaten into compliance, gradually taking on form as it progresses. It's not necessarily constructed around a fully formulated idea which is why I think the concept might be more fully revealed within the code.

    Regarding "the medium." If I were a sculptor welding iron together I wouldn't have to leave instructions on how to re-interpret the work. For one, because the method of its making can most likely be fully determined by observing the work and for another because as a physical object it shouldn't need to be re-interpreted. It can be preserved in its physical form. You obviously can't do that with software because it has no physical form.

    I think I understand where you're going with the other "medium" comments; i.e. you WELD iron, you PAINT the painting and you RUN the software. But I think it's pretty common to call iron, paint, clay, graphite and so forth "media" in an art-creation context so referring to welding and painting as media is a pretty unusual approach. Refer to it however you will. I think recent attempts to identify the "media" of new media have more or less shown us that it's a matter of personal preference. I choose to identify code as the medium in software art on the basis that it is the hands-on element that is shaped and manipulated by the artist much in the same way that iron, clay or paint is shaped and manipulated by artists.

    > perhaps there was nothing to discuss?

    The question is never whether or not to discuss something but rather how to discuss it.

    best r.
    Pall
  • damian stewart | Mon Mar 17th 2008 8:53 p.m.
    ok. to be honest, i don't feel like you're willing engage with my point of view on this, and i'm not going to try and convince you to. sorry.

    image
  • Philip Galanter | Mon Mar 17th 2008 8:57 p.m.
    Others have tried to argue that, in at least some pieces, the code *is* the art. I'm not sure if you are also trying to make that point. Personally I've found that thinking about computer art in that way is not terribly helpful. But if one really wanted to make a go of it, it seems to me they would first have to explain what they mean by "art." Yes...the dreaded (although not by me) "what is art?" question.

    Some might say code is to computer art as a script is to a play. I don't think it even goes that far. The tone and meaning of a script is approximately the same as the play. Computer code is nothing like what the audience will experience when they view the piece. Code tells the *computer* what to do and it doesn't directly communicate with the *audience* at all.

    I suppose one could pin paper printouts of a computer program on the wall and claim that it is a work of art. And perhaps it would be. But that's pretty much a one trick pony. And it's not the same at all as claiming that in a digitally driven installation (for example) the art isn't the images and sounds and interactions delivered, but rather the art is actually the unseen code.

    Another way a computer program could be art would be if the intended audience was computers. But so far there is no evidence that computers have any first-person sense of experience. I have to think that Art is wasted on the dead or unconscious.
  • mez breeze | Mon Mar 17th 2008 9:46 p.m.
    Codework refers to the use of the contemporary idiolect of the computer and computing processes in digital media experimental writing, or [net.writing]. Some of the prominent practitioners include Alan Sondheim, who has given the practice and genre its name, Mez (Mary-Anne Breeze), Talan Memmott, Ted Warnell, Brian Lennon, and John Cayley. These writers also use different terms to refer to work: Mez composes in a neologistic "net.wurked" language that she has termed m[ez]ang.elle; Memmott uses the term "rich.lit"; Warnell names some of his JavaScript poems "codepoetry"; Lennon refers to "digital visual poetics"; and Cayley produces algorithmic, generative texts, or "programmable poetry." Writers and artists who have taken up the general practice of codework heed the mandate - "use the computer; it is not a television" - and strive to foreground and theorize the relations between interface and machine and so reflect on the networked environment that constitutes and is constituted by a digital text. The precise techniques vary, but the general result is a text-object or a text-event that emphasizes its own programming, mechanism, and materiality.

    .....this what u mean phil by the argument of the code being the art?

    [read the rest here:http://www.electronicbookreview.com/thread/electropoetics/net.writing">
    http://www.electronicbookreview.com/thread/electropoetics/net.writing].

    chunks,
    mez

  • Pall Thayer | Mon Mar 17th 2008 10:09 p.m.
    Damian, I'm sorry if you expected me to toss everything out the window and agree with you. The fact of the matter is simply that I don't. But in explaining why I don't I have engaged with your views which is what has enabled me to point out the reasons why I don't think the views you mentioned apply. I haven't said that you're wrong about anything. You're entitled to your opinions but if I don't think that they match the context of my argument, then I don't see anything wrong with pointing that out. As I pointed out, although these ideas are quite clear to me, my presentation of them is something I'm still smoothing out which is why I'm presenting them here for some informal discussion. Our discussion has already brought out some issues that I'm rewording to avoid misunderstandings and I thank you for that.

    Phillip, yes, I do mention in the paper that the code, "... IS the art." But it's put forth in a metaphorical sense. What I'm arguing is that an examination of the code alongside the results of running it on a computer would provide another level of understanding to those who have the necessary "language of interpretation." That "language of interpretation" would mean that the viewer is capable of picking out bits of information from the code that may or may not be relevant to an interpretation. They don't have to be proficient coders in the same sense that people don't have to know how to play a musical instrument to understand musical notation. People don't need to be programmers to be able to understand bits of code and something as simple as "if($image->{tag} eq 'love'){ produce_image(); }" can explain a lot. By revealing the code alongside the work we make it relevant to a deeper understanding of the work and promote the development of a "language of interpretation" that extends to the code level.

    I am not suggesting that code can stand alone as the artwork but that it is a meaningful component of the work that deserves examination in an attempt to interpret the artist's intentions. A positive byproduct of revealing the code is that of preservation. With the code being available the piece could be "re-interpreted" on future hardware in the same way that say, Wendy (Walter) Carlos "re-interpreted" Bach on synthesizers. To this someone might respond, "But you can't compare a programming 'language' to 'symbolic' musical notation." But can we really call programming languages 'languages'? They aren't really. They are symbolic notation disguised as language.

    best r.
    Pall
    • damian stewart | Tue Mar 18th 2008 7:46 a.m.
      Pall Thayer wrote:
      > You're
      > entitled to your opinions but if I don't think that they match the
      > context of my argument, then I don't see anything wrong with pointing
      > that out.

      the thing is i think they *do* match the context of your argument. this is what i mean by not engaging with my point of view. i don't care whether you agree with me or not, i just felt like you were dismissing many of the points that i was raising because they 'didn't match the context of your argument'. which is just plain rude. you asked for feedback on your paper, i've given you feedback. there were a lot of other things i could've been doing (learning Supercollider, working on some code for one of my own pieces, going for a walk under the moonlight, ...) but i chose to give you feedback. then to have it dismissed in this way, it's just plain rude. i've been arguing on the intertubes for far too long to take it personally, but it makes me much less likely to want to engage with you in the future.

      i admire you for sticking to your point of view so strongly, but i maintain that i think you're confusing process, medium, and product (the 'art object' for want of a better term). either that, or you're trying to take something that applies to just a subset of code-based art and apply it to all art that uses code.

      from the first paragraph of your paper:

      "... Yet it
       IS the work. The work couldn't exist without it. It controls every single aspect of the “experience.” Furthermore, It is the medium that the creator of the work molds and fashions into the “experience.”"

      there are three terms you're using here: code, "experience", and medium.
      - on the one hand, you claim the code controls every single aspect of the "experience", ie the code controls the experience but is not the same as the experience.
      - on the other hand you claim that the code is the medium that becomes the "experience" through a processing of molding and fashioning, ie the code is transformed into the experience through the act of programming, ie once the artwork is finished the code just is the experience.

      but you can't have it both ways. code cannot both control every aspect of the experience, and be the experience itself, except in specific instances where that is the intention of the artist.

      and i don't think you can get out of this by substituting the word 'software' for 'code': code as language can be experienced in the same way that writing or poetry can be experienced; but code under execution, what i mean by 'software', cannot be directly experienced except through some interface (screen, speakers, lights, motors, etc), and even then, it can only be experienced as its effects or controls on that interface, and not directly.

      Philip raised a very good point, which pins down something where i'm coming from, that i don't think you've addressed:

      "... one could pin paper printouts of a computer program on the wall and claim that it is a work of art. And it's not the same at all as claiming that in a digitally driven installation (for example) the art isn't the images and sounds and interactions delivered, but rather the art is actually the unseen code. "

      at best, the argument you're raising refers to a specific subset of code-based artwork, and this is the subset where the code is written to be seen as well as to be experienced (e.g. 'code poetry', poetry that is also an executable program). but i don't think it applies to the kind of coding that someone will do for example for an entirely screen-based work, ie the kind of coding that makes up the vast majority of computer-based art. and if this is your point, then fine; just make it more clear exactly what you mean by "Computer-based Art".

      lastly, and i don't expect anyone to agree with me on this, i think that if you need to see the code to understand what's going on - if i can't tell that there's 'love' involved without looking at the code, "if($image->{tag} eq 'love'){ produce_image(); }" - then the artwork has failed.

      --
      damian stewart | +351 967 797 263 | damian@frey.co.nz
      frey | live art with machines | http://www.frey.co.nz
  • Jim Andrews | Tue Mar 18th 2008 7:24 a.m.
    The code of programs can be interesting in other ways not yet mentioned that are relevant to the art work. In a similar way to how the plans of a building are relevant to an understanding of the architecture.

    The term 'architecture' is applied to software in Computer Science. It's quite an apt use of the term.

    The plans for a building can range from napkin notes to sophisticated computer simulations of stress tests.

    From an onlooker's point of view, these are useful insofar as they let us understand the fundamental challenges and achievement of the building's architecture.

    When we look at architectural works as art, we don't just look at the finished building itself, necessarily, if we want a deeper understanding.

    So too in looking at software art, we can look at the code, the documentation, the napkin notes, and so on, toward a deeper understanding and appreciation of the whole art work.

    ja
    http://vispo.com
  • Pall Thayer | Tue Mar 18th 2008 11:31 a.m.
    This response is written in spurts between other tasks. I want to address these comments as quickly as possible to keep the thread as well as my train of thought alive. If something doesn't make sense or sounds confusing, just let me know instead of getting hostile.

    Damian, as I mentioned, your comments have been helpful. I don't know why you're getting riled up and I really don't understand how you can accuse me of dismissing or not engaging with your views. I read your comments, thought about them and replied in a manner that I'm pretty sure addressed most if not all of your points, explaining as clearly as possible why I reply the way I do. How is that not engaging with your views? It's not as if I came up with these ideas yesterday and am having this type of discussion regarding them for the first time. They are the result of years of experience in this field and a combination of both formal and informal research. I am now making yet another attempt to get them out there in a way that people from various corners of the artworld might fully grasp what I'm trying to say. It's complicated because a lot of the people I'm trying to appeal to have no technological background so I try to relate points to more traditional ideas within (especially) the visual arts as that is where my background is. My references to code as a medium relate to artists such as Sol Lewitt and Lawrence Weiner referring to language as their medium. I'm not the first person to do this. For instance, Casey Reas and Christiane Paul have both made similar connections. Traditionally, artists listed their various media as the elements they handled directly to create the work; graphite on paper, oil-color on canvas, clay, etc. Now however, some people have a tendency to refer to artistic media in the same way that they refer to communications media (a McLuhan-esque definition); television, radio, newspaper. One refers to the elements handled by the artist, the other to the mode of presentation. But this has always been a term that fluctuates. Ask a painter what their medium is and they answer "painting." Ask a potter what their medium is and they answer "clay" or "porcelain." Some have even extended these notions to the point of referring to the museum or gallery as the medium. What it all boils down to is that the term "medium" simply means something in the middle. So, something between the artist and those who experience the art. There's nothing about the term that defines where exactly it's located between those two. That is a matter of personal preference. Therefore it's impossible to confuse medium with process or product. They can all be referred to as media. The thing is to define your use of the term and stick with it.

    Perhaps it would also help to draw a distinction between the terms art and artwork. One could be said to refer to the completed circuit between artist, media and those who experience the work. The other to refer only to what is made by the artist regardless of it's effect, meaning or message. So if we can think of a painting, disregarding all visual content, as just a mass of paint hanging onto canvas, that is the artwork. Of course it's not just that, it's a carefully calculated construction of paint onto canvas. The art emerges when someone interprets it's possible message and/or meaning. In that sense, the artist isn't the sole creator of the "art." It can only be complete with the participation of an observer. The artist is however the sole creator of the "artwork." In the case of computer-programmed art, we could add another step to completing the circuit, that being the computer. If you're viewing a work of mine, then what you see on your screen as the software runs isn't being created by me. It's being created by your computer based on the code from me. In that sense, the code is the artwork. It's the only element that I am the sole creator of. Everything else, the way the computer displays it, the way that the viewer views it, is an interpretation of that artwork.

    Actually, I have addressed Phillip's point in my response to him. I'm not arguing for code as stand-alone art. I'm not even suggesting that making it available is necessary. I am suggesting that revealing it alongside the work provides a means for a deeper understanding of the work. Let's make another Sol Lewitt comparison. If you haven't seen any of his wall drawings, please look at some. There's one here: http://www.guggenheim.org/artscurriculum/images/sf_lewitt_l.jpg

    It's an aesthetically pleasing drawing that can be experienced in a meaningful way on its own. Now go here: http://www.guggenheim.org/artscurriculum/lessons/sf_lewitt.php#section3 and see if that doesn't entirely change your interpretation of the work and the artist's intentions providing, as Jim mentions, "a deeper understanding and appreciation of the whole art work."

    I'm also perfectly willing to accept the idea that the code only becomes relevant to an interpretation of the work when and/or if it is revealed alongside the work. Min is essentially an appeal to artists producing coded artwork to reveal their code and an appeal to those who examine the work to examine the code alongside the work. I truly believe that we would all be surprised and amazed at what could emerge from interpretations where people make a true effort to understand parts of the code within the context of the running work.
    • damian stewart | Sat Mar 22nd 2008 12:50 a.m.
      In the case of computer-programmed art, we could add another step to completing the circuit, that being the computer. If you're viewing a work of mine, then what you see on your screen as the software runs isn't being created by me. It's being created by your computer based on the code from me. In that sense, the code is the artwork. It's the only element that I am the sole creator of. Everything else, the way the computer displays it, the way that the viewer views it, is an interpretation of that artwork.

      i don't think the nature of the computer is special enough to warrant this extra step in the circuit. it's not an 'interpreter' in the sense that we as humans are interpreters. this is an important distinction between software art and works by the likes of Sol Lewitt: in Sol Lewitt's case a good chunk of the interest in exposing the code comes from the involvement of people (human interpreters) in the execution of the code. we want to read the code so that we can understand what it felt like to be one of the co-creators of the artwork, or so that we can understand what the artist wanted to put the co-creators through; our interest in code here is i think tied very firmly to the fact that the interpreters are human.

      the computer i think needs to be viewed the same way we view the kiln in the case of the ceramic sculptor, or the printing press in the case of the printmaker, or the video player in the case of the video artist. it's just a tool to turn something raw into something, err, 'cooked'. It is this 'cooked' object that can then be interpreted as an 'artwork': raw clay into ceramic sculpture, negative relief into positive print, magnetic field variations on tape into images on a television, and in the case of software art, code (text file) into executed program (software/'runningness'/whatever you want to call it).

      -
      or from another angle: imagine i am Michelangelo. i give a set of instructions to my 50 assistants, then i go home to ponder the infinite, popping in and out again make some changes to the instructions as necessary. my 50 assistants then paint the ceiling of the Sistine Chapel. in which case, the ceiling of the Sistine Chapel is being created by my assistants based on the set of instructions from me. In that sense, the set of instructions is the artwork. It's the only element that I am the sole creator of. Everything else, the way the assistants paint it, the way that the viewer views it, is an interpretation of that artwork.
      • Pall Thayer | Tue Mar 25th 2008 10:50 a.m.
        Sorry for the late reply to this post. I think this threading feature is rather new so I missed it. I think our differences here come down to differences in opinion. If you take the two views combined, then neither is right and neither is wrong. It simply depends on how you look at things.

        First of all, I don't agree with your description of the "nature of the computer" within the circuit. No, the computer is not an interpreter in the human sense but it is still an interpreter. A kiln is not an interpreter. Software art requires the computer's constant participation whereas a clay sculpture only requires the kiln for a single step in the process and then maintains its existence without it. The same applies to the printmaker's press. You can't experience a previously executed program unless it actually creates some sort of hard output but then we get back to the issue I mentioned earlier about software that creates art as opposed to software that is art. Also, if the objective is to produce hard output then "runningness" becomes pretty much irrelevant.

        In the case of video we have something else. Video playback is a record of something that occurred sometime prior. Software runs in the here and now. If it didn't, we might as well make a video because it's going to be easier to exhibit and to conserve. But then again, that's software making art rather than software as art.

        There's a huge difference between the Sistine Chapel and software art. For one, the Sistine Chapel has been visible for 500 years and they didn't even have electricity for more than half that time. But as far as your statements about it go, if I recall correctly Michelangelo did paint most of the ceiling himself and only allowed his assistants to paint very small portions. However, regardless of all that, if there did actually exist written instructions and detailed sketches and he hadn't burned them all (he burned a lot of his sketches), they would provide invaluable insight into his personal thoughts and ideas regarding the painting and specialists today would be analyzing them to gain a deeper, more meaningful understanding of the work. But perhaps the most important thing is that it wasn't the artist's intent to create a work of art based on a set of instructions.

        Pall
  • Eric Dymond | Tue Mar 18th 2008 9:21 p.m.
    Well, if the code is seen as a series of instructions to the machine then I wonder why is it removed from being Art as some of the respondents insist.
    Is a Sol Lewitt drawing, executed according to the instructions by gallery attendents/interns , separate from those instructions? Don't we have to admit that the final drawing can't exist outside of the instructions, and those instructions are intrinsic to the work? Can we admire the instructions conceptually without executing the drawing?
    It seems to parallel Pall's theory.
    Eric
    • damian stewart | Sat Mar 22nd 2008 12:59 a.m.
      Well, if the code is seen as a series of instructions to the machine then I wonder why is it removed from being Art as some of the respondents insist.

      i spoke to some friends who were at Pixelache, and actually saw the lecture this discussion is based on, about this. they're not programmers. they passed on this point, though:

      because it's not directly experienced as part of the artwork (unless that action is taken deliberately by the artist). it can aid in the interpretation, if you understand code, sure, but not in any way that is any more or less special than seeing conceptual drawings, notebooks, and studies can aid in the understanding of a painting or a sculpture.

      i don't think anyone is denying this last point. Pall seems to arguing for something stronger than this, though, almost a necessity for code to always be shown alongside the executing software. but this would be like trying to claim that a painter's notebooks relating to this painting should always be shown alongside their paintings.
  • Pall Thayer | Sun Mar 23rd 2008 1:30 p.m.
    Damian, I'm not arguing for anything stronger, really. And I'll admit that this is a point that needs to be made clearer in the presentation and/or paper. I'm not saying that it's in any way necessary to show the code alongside the work. However, I am arguing that as long as it's not done, it's not being regarded and those who view the work aren't getting a chance to formulate an opinion about it. So what I am suggesting is that we show the code within some sort of framework that can facilitate a more personal understanding of significant parts of it in an effort to underline its possible relevance to a reading of the work. But essentially it's left up to the viewers whether or not they feel a need to regard any of it. Without rereading the paper, I'm pretty sure it doesn't say anywhere that the work can only be interpreted based on the code. It only states that an examination of the code could provide for a deeper understanding of the whole.

    Pall
Your Reply