In a fit of thesis-writing procrastination, I have been reading articles that explore how difficult it is to call some things “society” and other things “technology”. One of these is Adrian Mackenzie’s article on Java programming as a virtual practice. In it he describes the way that Java programmers, because of the way they construct their functioning code from repositories of previous APIs, are caught between perceptions of their own role as “consumers” and “producers” of the internet. At the same time, the code they write is configured by attachment and identifications to all kinds of other documents. In other words, the work of Java programming is in reading, understanding, and recombining other bits of code, written knowledge, and marketing pressure. So what is presented as Java, then, is a virtual construction: virtual because it is shifting, unstable, and perpetually reconstructed.
All of this made me think about the work of coding, so I thought I would return last year’s question about the beauty of computer code. For me as a non-coder, the actual functioning of computer code is completely hidden – in science studies terms it is “black-boxed” – about as obvious to me as the controls of an airplane. But blueprints for an airplane are beautiful, so why not code?
A little while ago I tagged along to Rotterdam as part of Hive Network’s entourage at the Dutch Electronic Art Festival. At the festival many pieces played with the idea of stripping off the representational elements of “new media art” and displaying the means of production (code, hardware, electrical current, machine construction) as themselves artistic (see MK’s wonderful photo here for one example). But is the code itself beautiful? I was tempted to think of it as a sort of technique that could facilitate art, but might not in and of itself constitute art. A bit like the way watercolour can produce both subtle landscapes and paint-by-numbers, or tiles can make a mosaic or line the bathroom wall.
I wasn’t sure if this was being uncharitable, so I one morning I decided to ask the In-House Hacker (IHH). As usual, we had stayed up rather late and left the flat in a mess before going to bed, but by the time I got up everything was tidy and the kettle was boiling. The IHH was already frowning at a laptop in concentration. It was as if the disaster of the previous evening had been made invisible: housework, essentially, placed in a black box. Outside the window the garden had been watered, weeds pulled, blossoms coaxed and tended. And the IHH, sitting there working was still at it. Tidying, streamlining, ordering, compiling.
Making things beautiful? Or creating the perfect conditions for art, for beauty, to blossom?
Java was proudly announced with a large troupe of trumpets, citations of global domination and a hail of silverbulletesque accolades. It was the utopian bridge between infinitely flexible software and infallible application implementation. Unfortunately it had a dysfunctional interface with the keyboard: the twit that sits behind it. Java, like all object oriented languages, is intended for modular re-use that enables developers to encapsulate other people’s work inside their own. A hierarchy of software networks (‘libraries’) is realised in which a certain model of trust evolves. A developer might not need to know what colours and patterns constitute a particular graphic, they just need to know that it will perform just as described on the tin – the black-box approach (black paint tin, strictly speaking).
The problem is that all black boxes can eventually be misused and abused, they have limitations that will only be apparent to the conscientious developer (they do exist, I swear), and not the occasional megalomaniac hacker. Perhaps this is the problem with java, its attempt to span too many bridges and not assume/target a certain audience. Can you imaging buying a book in 30 years time entitled “Open Heart Surgery for the Home!”..?
Code should be hidden (abstracted) away from both the end user and the aspiring developer who seeks to build on existing work. The beauty of code is not only in its syntactic construct – for C programmers this would be brevity – but also in the design of the interface to the outside world (API), where attempting to predict how it may be used will ensure the code’s longevity. Currency for coders is having your name tied to an “About” button.
To borrow the garden context, a gardener wants you to enjoy the flowers and not marvel at the lack of aphids. Similarly, the beauty of code is defined by its transparency.
The trend tends to shift, in art anyways, between putting everything in a black box, or letting all your wires hang out. Some artists stick faithfully to one aesthetic or another. I can’t say that I have a preference, since sometimes the concept is so strong it may in face be a distraction to see the other “stuff” (or as IHH would say, I want to see the flowers, not marvel at the lack of aphids) and then other times, the process and construction is so tied into the work, to hide it would be a shame. I suppose this is my long way of saying “it depends”, as I think both approaches have their time and place.