© The Financial Times Ltd 2014 FT and 'Financial Times' are trademarks of The Financial Times Ltd.
January 31, 2014 2:08 pm
Even if you’re the kind of person who tells new acquaintances at dinner parties that you hate email and ebooks, you probably recognise the words below as being some kind of computer code:
public static void Main ()#
System.Console.WriteLine (“Hello, World!”);
You may even be able to work out, more or less, what this little “program” does: it writes the line “Hello, world!” to the console of some system.
A geek hunched over a laptop tapping frantically at the keyboard, neon-bright lines of green code sliding up the screen – the programmer at work is now a familiar staple of popular entertainment. The clipped shorthand and digits of programming languages are familiar even to civilians, if only as runic incantations charged with world-changing power.
Computing has transformed all our lives but the processes and cultures that produce software remain largely opaque, alien, unknown. This is certainly true within my own professional community of fiction writers; whenever I tell one of my fellow authors that I supported myself through the writing of my first novel by working as a programmer and a computer consultant, I evoke a response that mixes bemusement, bafflement, and a touch of awe, as if I had just said that I could levitate.
Most of the artists I know – painters, film-makers, actors, poets – seem to regard programming as an esoteric scientific discipline; they are keenly aware of its cultural mystique, envious of its potential profitability and eager to extract metaphors, imagery, and dramatic possibility from its history, but coding may as well be nuclear physics as far as relevance to their own daily practice is concerned.
Many programmers, on the other hand, regard themselves as artists. Since programmers create complex objects, and care not just about function but also about beauty, they are just like painters and sculptors. The best-known assertion of this notion is the 2003 essay “Hackers and Painters” by programmer and venture capitalist Paul Graham. “Of all the different types of people I’ve known, hackers and painters are among the most alike,” writes Graham. “What hackers and painters have in common is that they’re both makers. Along with composers, architects, and writers, what hackers and painters are trying to do is make good things.”
According to Graham, the iterative processes of programming – write, debug (discover and remove bugs, which are coding errors), rewrite, experiment, debug, rewrite – exactly duplicate the methods of artists. “The way to create something beautiful is often to make subtle tweaks to something that already exists, or to combine existing ideas in a slightly new way,” he writes. “You should figure out programs as you’re writing them, just as writers and painters and architects do.”
Attention to detail further marks good hackers with artist-like passion, he argues. “All those unseen details [in a Leonardo da Vinci painting] combine to produce something that’s just stunning, like a thousand barely audible voices all singing in tune. Great software, likewise, requires a fanatical devotion to beauty. If you look inside good software, you find that parts no one is ever supposed to see are beautiful too.”
This desire to equate art and programming has a lengthy pedigree. In 1972, famed computer scientist Butler Lampson published an editorial titled “Programmers as Authors” that began: “Creative endeavour varies greatly in the amount of overhead (ie money, manpower and organisation) associated with a project which calls for a given amount of creative work. At one extreme is the activity of an aircraft designer, at the other that of a poet. The art of programming currently falls much closer to the former than the latter. I believe, however, that this situation is likely to change considerably in the next decade.”
Lampson’s argument was that hardware would become so cheap that “almost everyone who uses a pencil will use a computer”, and that these users would be able to use “reliable software components” to put together complex programs. “As a result, millions of people will write non-trivial programs, and hundreds of thousands will try to sell them.”
A poet, however, might wonder why Lampson would place poetry-making on the same spectrum of complexity as aircraft design, how the two disciplines – besides being “creative” – are in any way similar.
After all, if Lampson’s intent is to point towards the future reduction of technological overhead and the democratisation of programming, there are plenty of other technical and scientific fields in which the employment of pencil and paper by individuals might produce substantial results. Architecture, perhaps, or carpentry, or mathematics. One thinks of Einstein in the patent office at Bern. But even the title of Lampson’s essay hints at a desire for kinship with writers, an identification that aligns what programmers and authors do and makes them – somehow, eventually – the same.
. . .
Both writers and programmers struggle with language. The code at the top of this article is in Microsoft’s C#, one of thousands of high-level programming languages invented over the past century. Each of these is a “formal language”, a language “with explicit and precise rules for its syntax and semantics”, as the Oxford Dictionary of Computing puts it.
Formal languages “contrast with natural languages such as English whose rules, evolving as they do with use, fall short of being either a complete or a precise definition of the syntax, much less the semantics, of the language.” So these formal dialects may be less flexible and less forgiving of ambiguity than natural languages but coders, like poets, manipulate linguistic structures and tropes, search for expressivity and clarity.
While a piece of code may pass instructions to a computer, its real audience, its readers, are the programmers who will add features and remove bugs in the days and years after the code is first created. Donald Knuth is author of The Art of Computer Programming, a revered magnum opus on computer algorithms and data structures. Volume three of The Art was published in 1973; the first part of volume four appeared in 2011, the next part is “under preparation”.
If ever there was a person who fluently spoke the native idiom of machines, it is Knuth, computing’s great living sage. More than anyone else, he understands the paradox that programmers write code for other humans, not for machines. “Let us change our traditional attitude to the construction of programs,” he writes. “Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do.”
In 1984, therefore, he formalised the notion of “literate programming”: “The practitioner of literate programming can be regarded as an essayist, whose main concern is with exposition and excellence of style. Such an author, with thesaurus in hand, chooses the names of variables carefully and explains what each variable means. He or she strives for a program that is comprehensible because its concepts have been introduced in an order that is best for human understanding, using a mixture of formal and informal methods that reinforce each other.”
Good code, then, is marked by qualities that go beyond the purely practical; like equations in physics or mathematics, code can aspire to elegance. Knuth remarked about the code of a compiler that it was “plodding and excruciating to read, because it just didn’t possess any wit whatsoever. It got the job done, but its use of the computer was very disappointing.”
To get the job done – a novice may imagine that this is what code is supposed to do. Code is, after all, a series of commands issued to a dumb hunk of metal, silicone and plastic animated by electricity. What more could you want it to do, to be?
Knuth answers: code must be “absolutely beautiful”. He once said about a program called SOAP (Symbolic Optimal Assembly Program) that “reading it was just like hearing a symphony, because every instruction was sort of doing two things and everything came together gracefully.”
We are now unmistakably in the realm of human perception, taste and pleasure, and, therefore, of aesthetics. Can code itself, as opposed to the programs that are constructed with code, be beautiful? Programmers certainly think so. Greg Wilson, editor of Beautiful Code (2007), an anthology of essays by programmers about “the most beautiful piece of code they knew”, writes in his foreword to that book: “I got my first job as a programmer in the summer of 1982. Two weeks after I started, one of the system administrators loaned me Kernighan and Plauger’s The Elements of Programming Style ... and Wirth’s Algorithms + Data Structures = Programs ... [These books] were a revelation – for the first time, I saw that programs could be more than just instructions for computers. They could be as elegant as well-made kitchen cabinets, as graceful as a suspension bridge, or as eloquent as one of George Orwell’s essays.”
Knuth himself is careful to limit the scope of his aesthetic claims: “I do think issues of style do come through and make certain programs a genuine pleasure to read. Probably not, however, to the extent that they would give me any transcendental emotions.” But in the many discussions that programmers have about craftsmanship, elegance, and beauty, there is an unmistakable tendency to assert, as Wilson does, that code is as “eloquent” as literature.
. . .
“Before 10 years are over, the Devil’s in it if I have not sucked out some of the life-blood from the mysteries of this universe, in a way that no purely mortal lips or brains could do,” the 19th-century mathematician Ada Byron wrote to computer science pioneer Charles Babbage, with an inkling of the uncanny powers they were beginning to glimpse.
“The Analytical Engine does not occupy common ground with mere ‘calculating machines,’ ” she wrote elsewhere. “It holds a position wholly its own ... A new, a vast, and a powerful language is developed ... in which to wield its truths so that these may become of more speedy and accurate practical application for the purposes of mankind than the means hitherto in our possession have rendered possible. Thus not only the mental and the material, but the theoretical and the practical in the mathematical world, are brought into more intimate and effective connexion with each other.”
This is why comparisons and analogies between programming and older disciplines can obtain only to a limited extent. When programmers say what they do is just like what writers do, or painters, the error is that they aren’t claiming enough, the fault is that they are being too humble. To compare code to works of literature may point the programmer towards legibility and elegance but it says nothing about the ability of code to materialise logic.
. . .
What programmers want to do in their investigations of the “eloquence” of code, I think, is analogous to what Anandavardhana and Abhinavagupta, 9th- and 10th-century philosophers, tried to do with poetic language in the Sanskrit cosmopolis: to understand how the effects of a language can escape language itself.
The Indian theorists were also dealing with a formal language tightly constrained by rules, that had been analysed only in stylistic terms. Seeing that this understanding of beauty was incomplete, they tried to formalise the processes of literary affect, to investigate how poetry moves across the borders of bodies and selves, and to understand how consciousness uses and is reconstructed by poetry, how poetry allows access to the unfathomably vast, to that which cannot be spoken.
Programmers also use formal languages but programming is sui generis. It is unlike anything else. Programmers need to claim the extraordinary nature of what they do. Most discussions of the beauty of code I have encountered emphasise formal qualities of language – simplicity, elegance, structure, flexibility – what a style-inclined theorist might have described as the qualities of the code.
But programs are not just algorithms as concepts or applied ideas; they are algorithms in motion. Code is uniquely kinetic. It acts and interacts with itself, with the world. In code, the mental and the material are one. Code moves. It changes the world.
This is an edited extract from ‘Geek Sublime: Writing Fiction, Coding Software’ by Vikram Chandra (Faber, £14.99)
Copyright The Financial Times Limited 2014. You may share using our article tools.
Please don't cut articles from FT.com and redistribute by email or post to the web.