[Humanist] 26.78 aesthetic computing

Humanist Discussion Group willard.mccarty at mccarty.org.uk
Mon Jun 11 22:17:13 CEST 2012


                  Humanist Discussion Group, Vol. 26, No. 78.
            Department of Digital Humanities, King's College London
                       www.digitalhumanities.org/humanist
                Submit to: humanist at lists.digitalhumanities.org

  [1]   From:    James Rovira <jamesrovira at gmail.com>                     (119)
        Subject: Re: [Humanist] 26.77 aesthetic computing

  [2]   From:    "David L. Hoover" <david.hoover at nyu.edu>                 (201)
        Subject: Re: [Humanist] 26.70 aesthetic computing

  [3]   From:    "Acord, Sophia Krzys" <skacord at ufl.edu>                   (13)
        Subject: RE: [Humanist] 26.77 aesthetic computing


--[1]------------------------------------------------------------------------
        Date: Sun, 10 Jun 2012 20:26:54 -0400
        From: James Rovira <jamesrovira at gmail.com>
        Subject: Re: [Humanist] 26.77 aesthetic computing
        In-Reply-To: <20120610202437.A6E3837DDD at woodward.joyent.us>


Many thanks to Daniel Allington and Paul Fishwick for their responses to my
post, which I feel were well-considered and understood my intent to the
extent that I expressed it clearly.  I'm wondering if it would help advance
discussion if we spoke concretely about a specific example?  Keep it simple
to illuminate fundamental issues and then observe from there instances that
complicate those fundamentals?  Some of this has already begun.

In my previous post, I had in mind something like an .html model.  There is
the code (.html), and there is the visible product of that code (the
specific webpage viewed in a browser).  The purpose of the code is 1) to
produce the visible product and 2) register information about that product.
I think this model works about the same with any web technology and with
documents and video games and images.

The audience for the code itself is limited to programmers, but the
audience for the visible product of that code is both programmers and
everyone else: all other users. All other users include people who play
video games and view webpages and write Word documents who, for all
practical purposes, may as well believe in magic as understand how all that
is produced.

Now, isn't code always subordinate to some kind usable product?  Haven't we
users usually thought that it doesn't matter how you get there, just that
the end product is stable, functional, and has some aesthetic appeal?
 Doesn't that mean that in this economy programmers always are clever
people who produce usable end products by arcane means?  Blacksmiths and
tanners and all other tradesmen, for that matter, have always been so.
 Programmers care -how- we get to that end product too -- how efficiently,
effectively, even elegantly, etc., but none of that matters except within
the context of an end product that works.  We don't appreciate code that
doesn't work.  That's like building a very beautiful car without an engine.
 There's not much point.  Imagine a millionaire with ten such cars in his
garage? Wouldn't we think he was crazy or stupid or very funny?

I would think that "aesthetic programming," if it's to be a field truly
distinct from the rest of aesthetics (in other words, a real subset of
aesthetics), would deal primarily with how code is written, not the end
products of code (like a webpage).  I would think that simplicity (finding
three step solutions rather than ten step), servicability (easy to fix when
things go wrong), and readability (easy to view and understand) would be
very important.  These all  have some aesthetic value but I think they're
still very much dependent upon use value as well.

Now, to return to Paul's responses -- they seem to me to be leading us to
the point where we can separate use value from aesthetic value in
programming, and truly, that's the way aesthetic value has often been
understood.  What makes a light switch a light switch is pure use value.
What separates a beautiful from a plain from an ugly light switch has
nothing to do with the functioning of the light switch.  That's pure
aesthetic value.  We might come up with a ten-step light switch, and that
might conceivably be part of some kind of artistic exhibit, but I think
most people would think it was either a real pain in the arse or very funny
-- because they were thinking in terms of use value, and no one but Willy
Wonka would actually want one in their house.

My sticking point with this issue is that use value always has to be part
of aesthetic value when considering programming. Use value is the starting
point.  It doesn't even count as programming unless it does something.
 -How- it does it make be part of our aesthetic judgment about it, but it
has to do something, like a car has to be able to be driven down the road.

Paul's next two paragraphs nicely complicate the issue and I have no
response to them until I've educated myself more in this area --

Code is not always going to be such a combination. If you look at the
> encyclopedia chapter, you will see "code" that is represented as
> analog machinery. We also have visual languages such as PureData,
> MAX/MSP which do not use writing at least at the higher levels of
> abstraction.
>
> Does "humanities computing" imply writing? Or can it suggest non-written
> products? And if it does imply writing, is there is a reason why writing
> and
> building are made separate? I realize that they are typically in the
> academy, but if we are to cross disciplines, perhaps we should
> cross more seamlessly between writing and non-writing. This thought
> may be reflected by the "build vs. write" debate that occupies some of
> the digital humanities books.
>

I would only ask that in terms of the coding/product split that I describe
above, how common is this?  Isn't it somewhat rare compared to the number
of webpages out there and the numbers of their viewers?  Or users of Word
documents or Diablo III?

I feel that I am on more familiar ground with his following responses,
though.  Under response [1] I think all different interactions with all
forms are equally and divergently meaningful.  Reading Harry Potter the
book, seeing HP the film or playing HP the game do not replace one another.
 I would extend this response to [2]: reading and viewing the play Hamlet
are two completely different experiences of two completely different media.

I don't mean to say that anything that is not written is superfluous,
though I can see how I may have come across that way.  Just, a play is
written, just like code is written and games are written and films are
written.  Even impromptu work such as the comedy show Whose Line Is It
Anyway? follows variations on comedic formulae.  Half of the fun is seeing
them follow genre conventions to get started then vary them -- but without
these conventions (which are already written and have been for centuries in
some cases, decades in others) there's no impromptu comedy.

Now this response perhaps takes us to the future of this discussion:

<<Why should code be any different than communication in the arts
and humanities which have resulted in a great variety of media products and
forms?>>

The beginning of an answer returns us to the fact of a code/product split.
 Because the other media products are identically product and code.  The
same brushstrokes that constitute the product of a painting also constitute
the code in which it is written.  As in all codes, not everyone can decode
a painting, but the code is equally visible to all viewers.  If we're
viewing a webpage or playing a videogame or reading a Word document,
though, the code is never visible.  It's beneath the product.  We can view
the product in most cases without ever viewing the code, and no one needs
to see the code to see or use the product.

In fact, in these cases, we can see the code OR see the product, but we can
never see both at once.  In the case of a painting, we always see both code
and product.

I think a programmer's dream is something like the closing scenes of The
Matrix, in which Neo viewed his entire world as streaming code constituting
the objects that he once viewed as material and solid and "real" in a
physical sense.  Viewing code and product simultaneously gave him godlike
powers -- the ability to write as he interacted and manipulate his
environment.  But programmers don't even view webpages that way, although
good ones could probably look at a page and write at least a good bit of
the code for it.

I think to get there we'd all have to be programmers and speak to one
another in code: code would have to be our actual language.  Then we could
begin to discuss aesthetic value apart from use value.

When I think of aesthetic vs. use value I'm using Kant's Critique of Pure
Judgment as a starting point.

Jim R



--[2]------------------------------------------------------------------------
        Date: Mon, 11 Jun 2012 08:59:10 -0400
        From: "David L. Hoover" <david.hoover at nyu.edu>
        Subject: Re: [Humanist] 26.70 aesthetic computing
        In-Reply-To: <20120609204605.E765C370A2 at woodward.joyent.us>

There is another kind of aesthetic computing that I don't think has been 
mentioned. My colleague Gabrielle Starr has a forthcoming book in which 
she writes about her experiments with looking at brain scans of people 
taken during aesthetic experiences. Information about her course is 
available here: http://www.cns.nyu.edu/~vessel/courses/NeuralAesthetics/

more information here: http://neuroaesthetics.net/papers/visual-arts/

David


--[3]------------------------------------------------------------------------
        Date: Mon, 11 Jun 2012 17:54:09 +0000
        From: "Acord, Sophia Krzys" <skacord at ufl.edu>
        Subject: RE: [Humanist] 26.77 aesthetic computing
        In-Reply-To: <20120610202437.A6E3837DDD at woodward.joyent.us>

I second Paul in thanking the humanist@ community for sharing your thoughts and reactions to Aesthetic Computing from a humanities computing perspective. We began talking about Aesthetic Computing with our Digital Humanities Working Group here at the University of Florida only this past spring, so the conversation is new for us as well. (I should situate myself briefly as a sociologist who is interested in how different academic disciplines use new technologies.)

One of the biggest criticisms that I hear about computing from humanities scholars is that formal computing languages risk being reductive, rather than productive, when creating computing environments for humanities work (which may require ambiguity, nuance, or multiple interpretations/meanings). In its emphasis on creating visual mechanisms to engage in embodied ways with computing structures (code, etc.), we wonder if aesthetic computing could provide a terrain or platform where humanities scholars and computer scientists can come together (regardless of familiarity with formal languages) and collaboratively 'tinker with' computing structures to create digital humanities projects. 

Your thoughts on anything above (or anything else) are quite welcome. We're particularly interested in the 'ambiguity' idea right now. Can we build computing structures for ambiguity? 

Best wishes,
Sophia
-----
Sophia Krzys Acord, Ph.D.
Associate Director, Center for the Humanities and the Public Sphere
Lecturer, Department of Sociology and Criminology & Law
University of Florida



More information about the Humanist mailing list