The Kolkata Lecture 4: Polish
(I pass over for the present a survey of various accomplishments of digital humanities generally, and of hypertext specifically; this was in many ways the meat of the talk, but regular readers of this blog have heard all this before.)
previous sections here
When I started to build hypertext systems, most people thought Ted Nelson’s vision of what we know as the Web to be a silly pipe-dream, a phantom of the sixties. That dream turned real, and its reality has transformed the humanities.
But of course we now know to be wary (and weary) of master narratives and to be bashful about “naive American technodeterminism” when we attribute such wide-reaching influence to the simple everyday technology of the link. So, though I’ve been living through, and playing a small part, in these tumults, perhaps this account is a fable, fabula, invention, perversion.
It’s hard to be sure. If we know anything in these days After Theory
Emerson said, “We will walk on our own feet; We will work with our own hands.” Our hands may get dirty.
I once heard a poet who was interested in new media ask, “Do I have to become a programmer?” This was, mind you, a woman who had been willing to incur discomfort and injury in the course of her work, which was getting her poems right even if here wrists hurt like hell. She was a teacher who would not hesitate to insist that one learn medieval Italian because any poet needs Dante. Yet, the thought of programming seemed entirely too much.
The two cultures problem – the chasm that divides the humanities from the sciences – did not begin in 1945, but 1945 made reconciliation all but impossible. Most people think the fault lies with the scientists; it always does. And so a few years studying Italian is mere necessity, but a few days learning a symbolic vocabulary that borrows a few symbols from mathematics, that is asking far too much.
Should digital humanists create tools, or merely learn to use them? This question ought to require no debate: the humanist must do what the problem requires.
Ruskin was not Turner. But if Ruskin had never attempted watercolor, could he have explained Turner half so well? If the critic is too far removed from the concerns of the creator – if she really has no idea how paint acts or how characters misbehave – criticism can quickly disappear down a rabbit hole of theoretical pretense, untethered to real work, unconnected to any sense of truth, and cut off from sympathy with the creator and her work.
And then there’s the simple understanding that the tools are themselves made, not decreed by God or inflicted by malificent capitalism. It is terribly important that we not delude ourselves into thinking that the craft of programming is beneath us, that we should confine ourselves to seemingly intellectual tasks. The architect and the builder, the sculptor, the painter, all need to work together.
And, to whatever extent possible, they should be the same person.
Sympathy for the scholar, to be sure, requires that we temper our expectations. Too much of what we think we prize in software today concerns polish, mere surface issues. If a program hangs or crashes, or a button is a few pixels out of place, people speak of it as worthless junk. We cannot expect this sort of polish from humanists, and perhaps we should not expect it from anyone.
We understand this, or at least we understood it once. We accept brushmarks because, without them, we cannot have spontaneity. Yet, perplexingly, we demand nothing but polish from our digital artifacts.