[Humanist] 26.92 aesthetic computing

Humanist Discussion Group willard.mccarty at mccarty.org.uk
Sun Jun 17 00:41:40 CEST 2012


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

  [1]   From:    Paul Fishwick <fishwick at cise.ufl.edu>                    (103)
        Subject: Re: [Humanist] 26.88 aesthetic computing

  [2]   From:    Daniel Allington <d.allington at open.ac.uk>                 (42)
        Subject: Re: [Humanist] 26.88 aesthetic computing

  [3]   From:    Daniel Allington <d.allington at open.ac.uk>                 (24)
        Subject: Re: [Humanist] 26.88 aesthetic computing

  [4]   From:    "Acord, Sophia Krzys" <skacord at ufl.edu>                    (7)
        Subject: RE: [Humanist] 26.88 aesthetic computing

  [5]   From:    Paul Fishwick <fishwick at cise.ufl.edu>                     (93)
        Subject: Re: [Humanist] 26.78 aesthetic computing


--[1]------------------------------------------------------------------------
        Date: Thu, 14 Jun 2012 22:27:41 -0400
        From: Paul Fishwick <fishwick at cise.ufl.edu>
        Subject: Re: [Humanist] 26.88 aesthetic computing
        In-Reply-To: <20120614201456.8DC8EFC450 at woodward.joyent.us>


Been out this week but will respond on a related aesthetic computing post
this weekend. I'd like to respond to James's and Henry's observations:

On 6/14/12 4:14 PM, Humanist Discussion Group wrote:
>                    Humanist Discussion Group, Vol. 26, No. 88.
>              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>                       (22)
>          Subject: Re: [Humanist] 26.85 aesthetic computing
>
>    [2]   From:    Henry Francis Lynam<lynamhf at tcd.ie>                       (19)
>          Subject: Re: [Humanist] 26.85 aesthetic computing
>
>
> --[1]------------------------------------------------------------------------
>          Date: Wed, 13 Jun 2012 17:20:36 -0400
>          From: James Rovira<jamesrovira at gmail.com>
>          Subject: Re: [Humanist] 26.85 aesthetic computing
>          In-Reply-To:<20120613204603.C850B281B27 at woodward.joyent.us>
>
>
> Daniel:
>
> Thanks very much for the response.  I tried to include the concept of
> "maintainability of the code" in my prior response here:
>
> <<  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.>>
>
> I called it "serviceability," though.
>
> The issues that I was trying to get to:
>
> 1. Aesthetic computing has to be about the code itself.
It includes code but also all aspects of computing, as well as its
practice.
> 2. Aesthetics has traditionally considered use-value a completely separate
> consideration from aesthetic value, while aesthetic computing would not be
> able to separate the two.  For example, what makes a beautiful hammer
> beautiful has nothing to do with how well it hammers, but what makes
> beautiful code beautiful always has to do, somewhat, with how well it
> works.
My own view on aesthetics is broad-based in that it covers all aspects of
the body (perception as well as cognition), so that what makes a hammer
beautiful is its look, feel, sound, and its function. The separation of
use-value from perception is problematic and artificial. Unfortunately,
this is where we find ourselves: computer scientists with a narrow
definition that is based on optimality and other cognition constructs,
and artists with a narrow definition that excludes use-value. I think we
should bring all of this back under the umbrella and embrace both. This
"two culture" characterization is over-simplistic but there is some truth
to it depending on who you ask. Comments welcome here from others
on this. Do we have a dual-culture division of use value vs. perceptual
elegance/introspection? Some companies (Apple) don't seem to have a clear
division, for the better one would hope.
>
> I do agree, however, that once we acknowledge that aesthetic computing is
> about the code itself, only programmers can judge the aesthetics of code.
Anyone who programs is a programmer by definition (including many
artists I know).

We may be agreeing, not sure until all of the dust settles.

>   But, only programmers who are capable of understanding an aesthetic
> judgment.
>
> Jim R
>
>
>
> --[2]------------------------------------------------------------------------
>          Date: Wed, 13 Jun 2012 23:43:05 +0100
>          From: Henry Francis Lynam<lynamhf at tcd.ie>
>          Subject: Re: [Humanist] 26.85 aesthetic computing
>          In-Reply-To:<20120613204603.C850B281B27 at woodward.joyent.us>
>
>
> I am enjoying this discussion on aesthetic computing. I think there is a
> tendency to look for aesthetics in computer code after it has been
> finalised and published. But another source of aesthetics in code occurs
> during the creation of the code.
Yes, absolutely.
> Think of a champion cyclist competing in a
> major competition. As they compete in stage after stage, their triumphs and
> failures create a narrative that is both compelling and indeed artistic. I
> think a master programmer pitting themselves against a difficult problem,
> creating code, erasing it, refining it, is also involved in an artistic
> process. Indeed, this narrative may be more accessible to the
> non-programmer than the resulting code. When programmers comment on the
> quality of each others code, the creation narrative behind the code is
> always an integral part of any aesthetic judgement.  I remember a (possibly
> apocryphal) story about Bill Gates coding a version of BASIC for a demo
> with IBM without having access to any hardware to test it. But apparently,
> when he ran it on the IBM hardware it worked flawlessly first time. In this
> example, the aesthetics of the code are not found in the final published
> piece of code, but in the challenge of creating working code under
> difficult circumstances.
Agreed!

-p

>
> Henry Lynam.



--[2]------------------------------------------------------------------------
        Date: Fri, 15 Jun 2012 13:20:10 +0100
        From: Daniel Allington <d.allington at open.ac.uk>
        Subject: Re: [Humanist] 26.88 aesthetic computing
        In-Reply-To: <20120614201456.8DC8EFC450 at woodward.joyent.us>


Jim

>        Date: Wed, 13 Jun 2012 17:20:36 -0400
>        From: James Rovira <jamesrovira at gmail.com>
>        Subject: Re: [Humanist] 26.85 aesthetic computing
>        In-Reply-To: <20120613204603.C850B281B27 at woodward.joyent.us>
> 
> 
> Daniel:
> 
> Thanks very much for the response.  I tried to include the concept of
> "maintainability of the code" in my prior response here:
> 
> << 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.>>
> 
> I called it "serviceability," though.

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'.

> 
> The issues that I was trying to get to:
> 
> 1. Aesthetic computing has to be about the code itself.
> 2. Aesthetics has traditionally considered use-value a completely separate
> consideration from aesthetic value, while aesthetic computing would not be
> able to separate the two.  For example, what makes a beautiful hammer
> beautiful has nothing to do with how well it hammers, but what makes
> beautiful code beautiful always has to do, somewhat, with how well it
> works.
> 

Yes, use-value and aesthetic value are separate considerations. But I don't see why they should be any less separable in computing than in other fields, or - to run with your example - why a computer program is so very different from a hammer. This is what I was getting at above: complaining that code is 'ugly' is entirely different from complaining that it is 'inefficient'; programmers do both. 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).

> I do agree, however, that once we acknowledge that aesthetic computing is
> about the code itself, only programmers can judge the aesthetics of code.
> But, only programmers who are capable of understanding an aesthetic
> judgment.
> 
Absolutely.

Best

Daniel

-- 
The Open University is incorporated by Royal Charter (RC 000391), an exempt charity in England & Wales and a charity registered in Scotland (SC 038302).



--[3]------------------------------------------------------------------------
        Date: Fri, 15 Jun 2012 14:54:58 +0100
        From: Daniel Allington <d.allington at open.ac.uk>
        Subject: Re: [Humanist] 26.88 aesthetic computing
        In-Reply-To: <20120614201456.8DC8EFC450 at woodward.joyent.us>

>       Date: Wed, 13 Jun 2012 23:43:05 +0100
>        From: Henry Francis Lynam <lynamhf at tcd.ie>
>        Subject: Re: [Humanist] 26.85 aesthetic computing
>        In-Reply-To: <20120613204603.C850B281B27 at woodward.joyent.us>
> 
> 
> I am enjoying this discussion on aesthetic computing. I think there is a
> tendency to look for aesthetics in computer code after it has been
> finalised and published. But another source of aesthetics in code occurs
> during the creation of the code. ...
>   I remember a (possibly
> apocryphal) story about Bill Gates coding a version of BASIC for a demo
> with IBM without having access to any hardware to test it. But apparently,
> when he ran it on the IBM hardware it worked flawlessly first time. In this
> example, the aesthetics of the code are not found in the final published
> piece of code, but in the challenge of creating working code under
> difficult circumstances.
> 
> Henry Lynam.

An interesting and very pertinent point.

Btw, there's a similar - though unfortunately not /quite/ true - story about Donald Knuth winning a programming contest with a program that worked first time. If anyone deserves to be guest of honour at the first international conference on aesthetic computing, it surely must be Knuth.

Daniel

-- 
The Open University is incorporated by Royal Charter (RC 000391), an exempt charity in England & Wales and a charity registered in Scotland (SC 038302).



--[4]------------------------------------------------------------------------
        Date: Fri, 15 Jun 2012 16:43:53 +0000
        From: "Acord, Sophia Krzys" <skacord at ufl.edu>
        Subject: RE: [Humanist] 26.88 aesthetic computing
        In-Reply-To: <20120614201456.8DC8EFC450 at woodward.joyent.us>


Thank you, Jim, Willard, Daniel, and Henry for your thoughts. I think that it is pure serendipity that Paul and I begun following the listserv days before Willard's first post on aesthetic computing. On some of your points (from my 'outsider' perspective as a sociologist):

Daniel (26.85) makes an important point that aesthetic computing is not a 'one size fits all' model. Well put!

Daniel (26.85) and Jim (26.78) seem to be emphasizing the Kantian separation of aesthetic value from use value. How does this understanding relate to Paul's use of Alexander Baumgarten's view of aesthetics as the science of sensory (non-purely-ocular) experiences, which, to me, seems to blur aesthetic value and use value? This latter view has gained much traction in the social sciences because of research that emphasizes aesthetic encounter and sensory perception as an activity that results in action or knowledge acquisition. (cf: research on the medical applications of music: http://www.ncbi.nlm.nih.gov/pubmed/22584037). Put this way, isn't the aesthetic beauty of the light switch an important part of its use value? Doesn't it 'entice us' into using it, as Bruno Latour might say? So, when Jim notes that use value has to be part of aesthetic value when it comes to programming, I think Paul would agree completely. What aesthetic computing is pushing, as I understand it, is to find ways to increase the use value of computing by making it more aesthetically accessible. And, by 'aesthetically accessible', I mean designing ways that programming structures and languages can appeal to our bodies, senses, and forms of tacit and embodied knowledge in semi-conscious ways that are not reducible to their apparent ocular surface beauty. This may be where Henry Lyman's good point about the importance of process comes in; aesthetic computing aims to engage on the level of process and not only output. (Paul - please correct me if I've got this wrong.)

Willard (26.85) makes another great point that computing technologies change how we think, and that our goal must be to find ways to take charge of these transformations to do them well. (Note to self: integrate some of this into my spring STS class after we read Walter Ong's Orality and Literacy.) My question: can aesthetic computing help us think differently about computing such that we can use computing more consciously and for the better? For example, applied drama (cf. John Somers' work at Exeter, my alma mater) can help teenagers to resolve conflicts because the aesthetic engagement through performance provides a different way for teenagers to view and think about their problems. Could aesthetic computing operate under similar principles? Could visualizing and engaging with programming structures differently enable us to build more responsive programs, or enable non-programmers to engage with formal language structures more accessibly? 

Ok, those are my wild postulations based on my own naiveté about the mechanics of computing. Thank you for your grounded and corrective thoughts!

Best wishes,
Sophia



--[5]------------------------------------------------------------------------
        Date: Sat, 16 Jun 2012 12:02:03 -0400
        From: Paul Fishwick <fishwick at cise.ufl.edu>
        Subject: Re: [Humanist] 26.78 aesthetic computing
        In-Reply-To: <20120611201713.0CDB714A95A at woodward.joyent.us>


Some replies on aesthetic computing based on quotes from the Humanities
mailing list. Thanks to all for this conversation, especially to
James Rovira, David Hoover, Willard McCarty, Sophia Acord, and
Daniel Allington.

USE-VALUE vs. NON-USE-VALUE

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. My point is that
we need to bring all of this back together and stop separating use-value
from non-use-value, and instead, note that when we view phenomena, our
perceptions are guided by many dimensions. As with a Necker Cube, an object
such as a steam engine may be viewed almost simultaneously from different
viewpoints and perspectives. It does not serve us well to continue to
separate use-value from non-use-value. It simply serves to divide us by
discipline. The beauty of the hall of engines in the Science Museum in
Kensington is in both functionality and sheer beauty of perception. It is
not really practical or possible to separate out that a Newcomen engine
actually works from its corporeal presence. Much like the Necker Cube, these
facets are natural dimensions of the same phenomenon. The engine is
beautiful because it functions and because of its form.

CODERS AS BUILDERS

I feel as though I am walking on egg-shells by playing the role of futurist,
for who can really say how code and programs will look in 10 or 20 years? As
suggested in the encyclopedia chapter, I believe that a combination of the
following two conditions will take hold:

1) "Writing code" will yield to richer, more body-centric representations.
In my aesthetic computing class, I encourage students to drop the slates for
a moment and sketch how they can build a quicksort or bubblesort machine
(out of any materials they desire). Most choose game engines such as
Starcraft, Minecraft, and Second Life for these games are progenitors of our
future HCI interfaces (to everything, including "code"). It is a different
way of thinking, to be sure. How do you build a bubblesort machine? Well,
let's see. You need a swapping device, a rail, perhaps a robot, some objects
whose attributes sense data. At first sight, this method of programming may
seem extremely expensive. Not so in the Holodeck/Matrix/Minority-Report
future. We are already experiencing a situation where we can plug and play
virtual objects bought from marketplaces that have their own "stock
values."

2) The idea of reading and writing will change. Building a machine or some
other construct will become a form of writing. Writing will no longer be
confined to flat surfaces. Likewise, reading will not be similarly
confined.

I do not claim to be the first to make these projections by any means. I
would enjoy hearing of books and articles whose authors make similar
claims.

Part of the argument in the AC chapter is that if our minds are already
grounded in the body, then why aren't we leveraging this in our
representations? To some extent, we already are. The arts and humanities
have generated a wide selection of media and representations. In mathematics
and computing, we are bound by considerations of efficiency, but
technologies that stress the body are exploding in number. These new
technologies will yield new representations for code, data, and program.

Both Daniel and James make good points about the nature of programming and
strategies that are used by computing professionals. Will the visual
continue to be a fringe element? Is it confined to a small number of
adherents? Perhaps, but I don't see this as programming's future. Instead, I
see something quite different than writing characters on flat surfaces. The
transition will take time, and traditional writing will always be with us
(the book didn't disappear with cinema). At the present time, my own work in
this area targets non-computing experts and education. Suggesting what
experts will be doing in 20 years is fraught with speculation.

NOVICES VS. EXPERTS

On the importance of visualization in computing, I have to recall my time as
a grad student when I saw the first MacIntosh. I had a PC and was quite
familiar with writing things such as find . -name "*.doc" -print | xargs
grep "Test" What's not to like?   At first, it was only the novices who were
drawn to Xerox/Apple gestural interfaces. This opened computing to the
masses. But now we all do it, even the experts. Since the beginning of the
computer revolution, the use of visual and audible cues have increased and
will continue to increase. It is not just a matter of MAX/MSP catering to a
fringe element. Much of what we do is visual. Workflow systems (Kepler,
built on Ptolemy, Simulink, Yahoo Pipes, etc) are all visual. Of course, all
digital architectures are visual (IC layout, digital logic diagrams). Most
large-scale programming is mapped out visually first (UML and BPEL
workflows). All of this is a logical progression if our cognition is
grounded in the body (to where using spatial metaphors is an improvement
over a removal of the body from our media interfaces).

Interfaces, for experts, must be efficient. So, until we have the holodecks
or easier ways to code control and and data flow, traditional writing
approaches will continue to dominate. I think for those who are not experts,
or who wish to learn about computing, there are more opportunities in
representation.

--Paul Fishwick, PhD
Florida Blue Key Distinguished Professor
Director, Digital Arts and Sciences
CISE Department, CSE 301
University of Florida
Gainesville, FL 32611
Email: fishwick at cise.ufl.edu
Web: http://www.cise.ufl.edu/~fishwick
Blog: http://www.representationz.com






More information about the Humanist mailing list