[Humanist] 26.94 aesthetic computing

Humanist Discussion Group willard.mccarty at mccarty.org.uk
Sun Jun 17 22:58:39 CEST 2012

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

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

  [2]   From:    Willard McCarty <willard.mccarty at mccarty.org.uk>          (44)
        Subject: traffic

        Date: Sat, 16 Jun 2012 19:19:28 -0400
        From: James Rovira <jamesrovira at gmail.com>
        Subject: Re: [Humanist] 26.92 aesthetic computing
        In-Reply-To: <20120616224141.09586283C8C at woodward.joyent.us>

Many thanks to all for this interesting conversation, especially Daniel,
Paul, Sophia, Henry, and Willard for starting it.

I would like to start by saying that I introduced the Kantian separation of
use value from aesthetic value to illustrate how they have to be combined
in computer programming.  I'm not so much advocating the separation as
stating that aesthetic computing would have to be judged by somewhat
different criteria than other aesthetic objects because in normal
programming circumstances they have to be combined.

Sophia's example of a light switch that "entices" people to use it I think
only illustrates the separation, I think.  There are really only two things
you can do with a light switch: turn it on and turn it off.  If you turn on
the light to see in the room, you don't need to be enticed to do so -- you
need the light on.  You turn it off to save electricity.  All use value.

But if a light switch entices you to turn it off and on, here in the US we
call that "playing with the lights."  Children do that.  But then you don't
necessary care about the lights.  You care about playing with the switch --
and seeing the lights flash, maybe -- which doesn't really serve any
purpose either.  So I think in the case of an object use value and
aesthetic value tend to remain separate.  I like the definition of
aesthetics as the science of sensory perception, so long as we narrow that
to a certain kind of sensory perception -- the kind that produces sensory
perceptions regarded as artistic effects. Otherwise, that's just
biomechanics.  We wouldn't say that sensory perceptions that cause a sharp
pain in my big toe or gastrointestinal disturbance are the product of an
aesthetic effect.

The idea of aesthetics as the science of sensory perception (generally
speaking) can be found in Kierkegaard's Either/Or and its discussion of the
aesthetic personality -- and Kierkegaard's presentation of the aesthetic
personality overall.

Regarding Daniel's paragraph below:

<<Ah, sorry about that - you did explain what you meant by that, but I
missed it because the word 'serviceable' means something else (and in this
context, almost opposite) in British English! It's still not quite what I
was getting at, though. When a programmer takes over responsibility for the
maintenance of an application or library he or she didn't write, he or she
has to read the existing code - and this is the point at which you'll often
hear him or her complaining about 'ugly', 'horrible', or 'unidiomatic'
code. These are aesthetic judgements that are entirely independent of the
end-product's usability. There's an entirely different set of judgements
that the same programmer might make with regard to usability: for example,
he or she might complain that the code is 'inefficient'.>>

What you describe above is pretty much what I had in mind, but I think when
a programmer says that code is "ugly" they usually mean it's difficult to
read, hard to work with, hard to troubleshoot, hard to follow the logic of,
etc., don't they?  I would agree that these judgments do not necessarily
relate to the end-product's usability (as we'd have to assume that the
product works with this ugly code for the example to work), but isn't this
still use-value?  I'm not talking about efficiency either, which usually
does relate to the end product (say, how long the webpage takes to load).
 I think complaints about ugly code have to do with its lack of linearity,
lack of simplicity, its redundancy, its lack of logic, etc., which tend to
relate to how easy it is to understand.  I would be the most beautiful code
to programmers is streamlined, simple, and logical -- easy to understand
and to change and otherwise "work" with.   But they're still thinking of
working with it.  Use value.

Also there are cases where code is produced only for aesthetic reasons,
> with no particular attention paid to use value. Perhaps the most obvious
> case of this is Perl poetry, eg. 'Black Perl' (Wall, 1990). Perl poetry has
> to compile, but the compiled program doesn't have to do anything useful.
> Yes, that is a fringe phenomenon - but it shows that programmers are just
> as capable of separating aesthetics from use as other makers are, even if
> they choose not to make that separation in every case (programming being an
> applied art, after all).

Now the Perl poetry example is I think a real exception. It has to compile
(work), but no one cares about the usability of the product.  A gesture at
usability is made, but the point is the beauty of the code itself.  I think
we need to ask ourselves, why the gesture at usability?   But, I like this

Paul confirmed a suspicion I had early on with his response.  I think those
books could contribute quite a bit to this discussion indeed.

> There are books on the aesthetics of mathematics (a major anchor for
> computer science) that focus on the elegance of proof, theories, and
> products of mathematics. Computing inherited this tradition. In the arts
> and humanities, aesthetics are often based on other criteria.

The thing is, what makes an object usable and what makes an object
aesthetically pleasing usually does tend to be two different things.  I
think most people who create things that work are aware of this tension.  I
mean, even a simple object like a pinewood derby car (5 oz. wooden cars
that children or their parents modify, decorate, then race) can be designed
for speed or for aesthetic effect.

When I was a child my father and I built our cars to win on speed, but the
cars designed to win for looks were designed very differently.  One looked
like a face -- nose, lips, and all.  Amusing.  And then we can set
aesthetic criteria within the parameters of usability too. So the cars
designed for speed will all be wedge-shaped, low, weighted toward the front
(the cars go down a ramp at first) -- so once you take those design
parameters into account, which cars are the more beautiful?  But,
importantly, what makes them the more beautiful doesn't make them any
faster.  Beautiful code might actually process more quickly, but I recall
now that I was told in the 90s not to put any spaces between my code
elements or break it up into lines.  Doing so makes the code easier to read
and follow but makes the page load more slowly.  Use vs. aesthetic value.
 I wrote my code with spaces and line breaks.  I was a literature guy.  I
wanted it readable, especially if (when) I made mistakes.

Of course all objects have both going on at once -- usability and aesthetic
value.  These are different ways of looking at the same objects, yes.  What
I was suggesting  about aesthetic computing is that computing is
exceptional in that usability has to be part of its aesthetic value (with
exceptions).  What makes the code more beautiful can be the same as what
makes the page load faster.

Jim R

        Date: Mon, 18 Jun 2012 06:55:26 +1000
        From: Willard McCarty <willard.mccarty at mccarty.org.uk>
        Subject: traffic
        In-Reply-To: <20120616224141.09586283C8C at woodward.joyent.us>

When I responded to the news of aesthetic computing, I had in mind the 
traffic from aesthetics to computer science as a case of a relation 
between the humanities and CS that is more than specification of a 
problem to be solved. I don't think it's particularly difficult to talk 
at least in a preliminary way about such a relation if we talk about a 
particular discipline of the humanities, such as history or philosophy 
or literary studies on the one hand and CS on the other. And it's 
possible to get further by being more specific as to what sort of 
history, philosophy or kind of literary studies. Aesthetic computing 
thus begins with aesthetics, but the relation could just as easily be 
with respect to ethics or epistemology on the humanities side. And the 
discussion here has been with respect to CS in the form mostly of 
programming but could be AI or HCI, for example. But is it possible, 
indeed attractive to try to say what exactly all such cases could be 
cases of?

To ask the question in a different way: why is this discussion taking 
place now? Or politically: cui bono? What need or desire is being felt? 
Is there more than humanists wanting to be involved in something 
scientific and computer scientists needing more interesting problems to 
work on? Is a Leibnizian marriage on the horizon?

In Plans and the Structure of Behavior (1960), George Miller, Karl 
Pribram and Eugene Galanter ask why the confidence of psychologists has 
received such a boost from being able to do things with machinery. They 
dismiss Clark Hull's notion that machinery keeps the psychologist from 
too much anthropomorphic subjectivity. The answer they arrive at is a 
form of Vico's verum factum -- that, as they write, "The creation of a 
model is proof of the clarity of the vision. If you understand how a 
thing works well enough to build your own, then your understanding must 
be nearly perfect." (46) The attraction for the psychologist is that he 
or she is able to achieve, they write 10 pages later, "the concrete 
actualization of an abstract idea".

Could we then say that the principle of the two-way traffic between at 
least some disciplines of the humanities and CS is centred on this 
concrete actualizing of abstract ideas?


Willard McCarty, FRAI / Professor of Humanities Computing & Director of
the Doctoral Programme, Department of Digital Humanities, King's College
London; Professor, School of Computing, Engineering and Mathematics,
University of Western Sydney; Editor, Interdisciplinary Science Reviews
(www.isr-journal.org); Editor, Humanist
(www.digitalhumanities.org/humanist/); www.mccarty.org.uk/

More information about the Humanist mailing list