It seems Thursdays are database days in the digital humanities, as along with Ben Schmidt’s excellent look at building performant databases for humanities research, Sean Takats of Zotero has just posted an extremely informative exploration of Zotero’s migration to Amazon EC2.
All this comfortable familiarity with complex digital systems makes me feel like the humanities turn toward the digital is much better timed than social science’s own experience years (decades? centuries, if you ask some social scientists) ago. Web APIs, cloud services and mature tools and architecture (and scripting languages) provide a more empirical landscape for scholarship than the punch-cards, 8″ floppies, Gopher and command-line stats packages of the distant past. Like the PASCAL programming wizards of the 1980s and their disdain for later programming languages, surely there will be curmudgeonly scholars who insist that if something is beautiful, convenient and intuitive to operate that it is somehow less rigorous than their old jalopy that got them to work on time, but I find it difficult to disdain modern projects simply because they don’t have to have every component painstakingly built and tweaked by hand.
Zotero’s maturity and robustness is one of those signs. There are also convenient *AMP stacks that allow me to set up MySQL databases for English professors with a couple clicks, cloud services that really work, analytical tools that allow for ready exploration of a variety of data and content management solutions that prevent me from becoming a webmaster. I still need to write SQL and script and know how indexes work and how spatial data can be manipulated, but fortunately I lucked into the university when you could actually focus on those things and leave the systems administrating, network administrating and web administrating to professionals, computers and off-the-shelf solutions.
Yes, I still need to run MALLET at the command-line, and by no means is this meant to be advocating that digital humanities scholars don’t need to know how to code. But they do need to be aware of how jargon and high barriers to entry have always equated to technological cachet. I’m sure that, right now, Richard Stallman is trying to convince somebody that the entire universe could be run in Lisp, if you were just willing to spend the time to learn how. And while it can be terribly inefficient, writing code in 2011 is incredibly easy. Whether it’s Javascript or R or Python or PHP or SQL (or Java or C++ or Actionscript or Objective C) it’s not like you’re writing Pac-Man in 1979 (or God forbid, actually coding in Lisp). Besides the curmudgeonly scholars and their digital jalopies, there’s an established community of old white men who think that complex digital work should be terribly difficult, and I’m sure they dislike the unwashed masses “playing at” writing code without really understanding it, but like most paternalistic orthodoxies, it’s mostly just an attempt to maintain that cachet.
It’s also a particularly good moment to become digitally literate (and by that I do not mean finger-literate or aware of how an Accutron watch operates but rather understanding the fundamental logical structures of the algorithmic and parametric processes embodied in the software, processes and data structures that make up so much of our waking world) not only because things have grown incredibly easy and convenient but because they’re not quite so easy and convenient as they soon will be, and so the structures are still visible. It was much more difficult to comprehensively engage with complex software and data structures even ten years ago due to the tremendous barriers to entry that came along with their expense and technological immaturity. I would wager that in ten years it will be equally difficult to comprehensively engage with complex software and data structures because of their seamlessness and ubiquity.