Stephen Ramsay

Nebraska Cluster Hire in Digital Humanities (Part 2)

2012-08-16T00:00:00-05:00

This year, the University of Nebraska-Lincoln will be reviewing applications for round two of our cluster hire in Digital Humanities. Here’s the job posting:

The University of Nebraska-Lincoln (UNL) seeks to hire additional faculty for its cluster hire in digital humanities. In this second phase of our effort, we hope to hire two or three additional tenure-track assistant professors to further propel this signature program. Field of expertise is open within the humanities. Preference will be given to candidates engaged in the building of digital projects, archives, editions, models, tools, and other creative scholarly works in the digital medium. Initial interviews will be conducted via Skype. Candidates should be accomplished digital humanists able to contribute to a thriving interdisciplinary initiative and to a home department. Candidates must provide evidence of successful teaching and an active research agenda. PhD required by August 2013. The participating departments seek specialists who would contribute to UNL’s research profile and teaching capacity in digital humanities. Applicants should go to http://employment.unl.edu, requisition 120608, and complete the Faculty/Academic Administrative Information form and apply online. Applicants should be prepared to attach the following to their online application: a letter of application, a curriculum vita, and a PDF or a link to one representative sample of their digital work. Please do not send paper applications. Review of applications will begin September 25 and continue until suitable candidates are found. For further information contact Kenneth Price, search committee chair, at 402-472-0293 or kprice2@unl.edu. The University of Nebraska has an active National Science Foundation ADVANCE gender equity program, and is committed to a pluralistic campus community through affirmative action, equal opportunity, work-life balance, and dual careers. Web sites: http://cdrh.unl.edu/, http://www.unl.edu/

Learning to Program

2012-06-10T00:00:00-05:00

I am a fool. Oh, yes! I am confused.
Others are clear and bright,
But I alone am dim and weak.
Others are sharp and clever,
But I alone am dull and stupid.
– Tao Te Ching

Aporia is the normal state of the programmer.
– Hugh Cayless, via Twitter

Years ago, when I started teaching programming to humanities students, I would distribute a brief questionnaire on the first day of class that tried to discern “where people were” with technology. I asked, of course, if anyone had any programming experience, though I quickly made it clear that this course didn’t require any. Mostly, I was trying to figure out what skills they had already acquired (raw HTML? PhotoShop?). I was also looking for sandbaggers from the CS department; toward the end, I had a list of acronyms and asked them to identify all the ones they could. Anyone who got “VLSI” was out.

I soon stopped giving out the questionnaire, though, in favor of a more informal, show-of-hands quiz. It goes something like this:

Have any of you ever studied programming?

A few, in high school.

How many of you play a musical instrument at any level of proficiency?

Lots.

Have you ever studied a foreign language?

All.

Well enough to make your way in a country where that language is spoken?

Hands are raised tentatively in a series of mezza mezza gestures.

Do you ever read the manual?

The ones who don’t overpower the ones who now won’t admit that they do.

Is anyone here a bike mechanic?

There’s always one.

For those of you who are not bike mechanics: When your bike breaks, do you try to fix it yourself or call the shop?

Fix it myself. Then call the shop.

Do you like to play chess? Or go? Or bridge?

A few. “Don’t worry,” I say. “Any hard game will do.”

Now, the real purpose of this quiz is to do the opposite of what the original questionnaire did: namely, to get everyone to relax about what is required for success in this course. And while it’s true that I’ve never seen a ukulele-playing, we-don’t-need-no-stinking-manual, chess nut fail the course, the questions really have more to do with a habit of mind than with any skill or innate talent.

People who enjoy studying foreign languages tend to make good programmers, but not for any of the more obvious reasons. Some people acquire languages more quickly than others, but anyone who succeeds at it has developed the remarkable ability to be more-or-less happy while being stupid. They’re not frustrated when they can only say “Hello” and “Goodbye” in French, and they still won’t be frustrated two years later when they still can’t really hold a serious conversation in the language. What’s more, they’ll gleefully and enthusiastically start trying out their broken, high-school-textbook French the minute they land in Paris. One of these days, they’ll “know French.” But they’ll think of themselves as “knowing French” way before that day comes.

Musicians, too, are often natural hackers, and I think it’s because they know what it means to be inept. You’re not Eddie Van Halen when you start out on the guitar. In fact, your fingers hurt for weeks and you wonder how anyone manages to make music with this damn thing. But hey! That sounds sort of like “Smoke on the Water.” And off they go. Sucking for years. But then gradually, they don’t. And way before they definitively don’t, they think of themselves as guitarists.

People will often cite hard work and a high degree of motivation as the secret to success in these areas. And while I certainly won’t disagree with that, I think this Zen-like comfort with knowing a little, with being a beginner, with kinda sucking, is the deciding factor in the end. They’re often persistent, and hard working, and all that, but mostly they’re okay with a process that makes them always feel a bit dumb. Such people seldom read manuals, in part, because they’re not bothered by not having Total Information Awareness before they begin. Such people imagine that they will botch the job before the bike is eventually fixed, and they’re okay with that. Every good chess player has suffered through years of humiliating slaughter at the chess board, and had a good time doing it.

And all of this is a very, very good sign in someone “learning to program” – not because knowing French or mastering the Queen’s Gambit means you have the right kind of brain, but because programming requires, above all, a quiet, peaceful attitude toward the feeling that you don’t really know what you’re doing.

Many academics I meet aren’t fond of this sensation, and so approach the acquisition of knowledge like a pilot who has not yet earned their endorsement for night flying. They’re always looking for moments in which they can declare that they are not specialists in eighteenth-century history or cognitive linguistics (usually, right before offering an opinion). When pressed, they’ll readily acknowledge that anything to which they can claim expertise is, in fact, a vast sea, the surface of which they’ve only barely penetrated. But the point is that they have a set of degrees and a long list of books they’ve read from beginning to end. Acquiring expertise in something else will presumably require a similar slog, and only after completing the requisite training will they dare admit to knowing something about it. Perhaps this is why I hear so many say, with a certain bitter mockery in their voice, “So, we have to go become computer scientists?!

Such humility might be socially and professionally appropriate, but it won’t do to have such an attitude in your heart when you sit down to “learn programming.” Nearly every programmer I know – and I know some great ones – started out not with a course, or a book, or a teacher, but with a problem that was irritating them. Something in their computational world didn’t seem right. Maybe it was broken, or maybe just missing. But being comfortable with not-knowing-what-the-hell-they’re-doing, they decided that getting a computer to do something new was more-or-less like figuring out how to get the chain back on the bike. They weren’t trying to “be programmers” any more than the parent determined to fix the kid’s bike is trying to be a “bicycle mechanic.”

But then, it worked. Just some little hack. Just some little fix. Suddenly, they knew more than they did before, and emboldened by that, they decided to go a little further next time. Sometimes, it happens early: these are the teenagers who go buy a book on C++ because they have a great idea for a game (and who aren’t in the least daunted when they can’t see their way from “Hello, world” to 3D graphics). Sometimes, it happens late (as it did for me, relatively speaking). The first time I got a Perl script to sort some lines in a text file, I thought I was genius. More importantly, I thought I was a programmer. I might not have admitted that to others, but I knew it. Or I had fun believing it was true. And then one day, it was true.

By some more common definition, most of my students aren’t “programmers” at the end of my course. There’s a great deal they don’t know, and they’ve still never written a long, serious, mission-critical piece of software. But when it comes to cultivating the right attitude toward it, many of them are programmers by the end of the first week. Because more than understanding control structures or sorting algorithms, they now see their computational world as something they can fix and change. In fact, the minute they have an idea for anything they want to write, I let them write it. There is no problem set I can possibly come up with that could replace the thing they’ve decided to change themselves.

I would like to end this post by saying that anyone can acquire this habit of mind, but I’m aware that in order to acquire this habit of mind, you have to already have this habit of mind. But that might be good news. Because if that sentence struck you as really interesting, you undoubtedly have the mind of a programmer.

Centers Are People

2012-04-25T00:00:00-05:00

[This is a talk I gave in April 2012 at the Digital Humanities Summit sponsored by the Committee on Institutional Cooperation of the Big Ten Conference. I have modified the talk slightly to remove some remarks that were particularly focused on the local context of that meeting. This paper might be thought of as a companion piece to Centers of Attention, which I gave at Emory a couple of years ago, and which now appears in Hacking the Academy.]

I’ve been involved with digital humanities centers for close to twenty years, and have now held most of the positions that one can hold (short of actually directing one). I’ve been a graduate student staff member, a full-time software engineer, an outside consultant, and a Fellow. I’ve watched centers rise and fall, flourish and fade, but centers have always played a, well, central role in my scholarly life.

What have I concluded from this long involvement? I’ve concluded that centers are people.

Now, that’s a bad way to begin, because in addition to a rather unfortunate association with Soylent Green, it also suggests any number of corporate platitudes and bromides. “It’s really about the people,” we say – mainly as a way to thank them on those rare occasions when it seems appropriate to do so, or to emphasize that whatever terrifying bureaucracies might arise, this is still all about human beings and collaborations among them. It’s the sort of sentiment companies emblazon on t-shirts and coffee mugs. It’s the mantra of departments, which, despite their avowed commitment to people, continue to go by the degrading and dehumanizing title, “human resources.”

Do I seem to make light of this noble intention? I hope so. Because I rarely see efforts to create centers that proceed from the proposition that centers are about people.

I suspect that many of you are eager either to create a center or to raise the profile of existing one. Centers, it may seem you, are exactly how you “get into DH.” I often hear resigned comments from faculty at other institutions who “don’t have a center,” weary and nervous confessions from those who are “working on getting a center,” and delighted cries of jubilation from people who finally, at long last, “have a center.” And I’m often invited to act as a consultant for groups at one or another stage of this process.

They invariably want to talk about money, and computers, and “infrastructure” – about the balance between research and service, the various reporting lines, the projects they might undertake, their position relative to other centers, grant funding, outreach, and furniture. Often, they are brought up short when I ask a question that seems to me a very logical one to ask (especially for a group that hopes to be “all about people”): Who here is doing digital humanities?

The answers are breathtaking. “Well, there are some people around who we think would be interested, but we haven’t really contacted them yet,” or “You know, it’s really spread across a few different departments, and we’re hoping use the center to bring them together.” Sometimes the answer is, “Um, us” (us being the two or three people to whom I posed the question). The credo, in other words, is that if we build it they will come. And while the movie from which that line comes is admittedly less risible than Soylent Green, the belief that having a server, a set of cubicles, and a sign will create that community is every bit as fatuous as the belief that if you create a baseball diamond, the 1919 White Sox will emerge from the surrounding corn field.

I cannot think of a successful digital humanities center – anywhere in the world – that did not begin with a bunch of people who had found each other through various means and who were committed to the bold and revolutionary project of talking to one another about their common interests. Over time, that had morphed into an even bolder and more revolutionary idea: the idea that perhaps they could work on something together (a thing that humanist scholars, who are both trained to be and rewarded for being solitaries, can find terribly difficult to do).

How much money do you need to start a center? Either none, or whatever the beer costs. What sort of infrastructure do you need? The laptops you already have, and the wireless on offer at Starbucks. What sort of service and outreach should you do? The kind that goes out and finds new members for this highly informal gathering of humanists – students, staff, librarians, faculty – who like to geek out together and drink.

Does this sound like too humble a start? This is the founding narrative of some of the largest and most influential centers in the history of the field. It is true that they will publicly credit the vision of a dean or some highly-placed administrator, but in back of that narrative is something much more fundamental and necessary.

Because while the digital divide is cause for great concern – and I agree fully with my colleague Will Thomas’s call for a return to issues of access and outreach – the principle miracle of our technology is that it allows people to punch way above their weight. Once upon a time, there were two students in a dorm who decided to make a list of what was on the World Wide Web. Once upon a time, there was a guy in a cafe who thought it would be cool to organize his t-shirt collection. Once upon a time, there was a person who thought the student directory at his university was lame. We are speaking, of course, of what would later become YaHoo, Flickr, and Facebook. Call me a naive, techno-utopian, but I continue to believe with all my might that two graduate students with a laptop could change the discourse of the humanities tomorrow.

I don’t want to say that everything magically falls into place once you have have formed the basic community of people and ideas, but it’s staggering how all of the decisions which so obsess people trying to build a center follow logically and inexorably from the evolving needs and expanding vision of more-or-less informal gatherings of like-minded enthusiasts. “It would be nice if we had our own server.” “Come to think of it, it would be nice if we had a bigger table.” “I think we need a whiteboard.” “Should we go for that grant?” “Uh, I’m an English professor; how do you write a grant?” “Think of what we could do if we hired a programmer!” Before long, you’re trying to get some combination of the words “institute,” “digital,” “humanities,” “research,” “project,” “center,” “initiative,” and “scholarship” into an acronym that isn’t already taken.

At an event like this, we naturally imagine something like a “network of centers,” and while I applaud that idea, I suspect that in the short term, we probably don’t need a lot of support from deans and provosts focused on creating an “infrastructure,” because the community can create that network by itself. But once the wider network of takes hold among a group of institutions, they will want a very large table, and a galactic whiteboard, and a big sign. And at that moment, senior administrators will have a clear and obvious role to play, because it will not be engaged in the terrifying prospect of creating something new, but of facilitating that which has already happened and which is already flourishing. They will then be eager to put their name on it, and we will gladly assent. We will also know the real story. Because honestly, it started in a bar.

The Hot Thing

2012-04-09T00:00:00-05:00

[This is a talk I gave at the Debates in the Digital Humanities Book Launch and Symposium hosted by DM@P at the University of Pittsburgh in April 2012. I was joined on the panel by Matt Gold (CUNY Graduate Center), Doug Armato (University of Minnesota Press), Liz Losh (UC San Diego), Jentery Sayers (University of Victoria), and Jamie “Skye” Bianco (Director of DM@P and the organizer for the event).]

We asked the captain what course
of action he proposed to take toward
a beast so large, so terrifying, and
unpredictable. He hesitated to
answer, and then said judiciously:
“I think I shall praise it.”
– Robert Hass Praise

I find the Debates in the Digital Humanities volume terribly upsetting.

Before I go any further with this dour and possibly inappropriate thought, let me say that I find no fault with anything in the collection from a scholarly or intellectual point of view. There are many superb essays in it: provocative, fascinating meditations on digital humanities—defining it, theorizing it, critiquing it, practicing it, teaching it, and envisioning its future. I think it will endure for many years as the best testimony we have to what Matt Gold aptly calls “The Digital Humanities Moment.”

What upsets me is not any of that, but the ways in which the traces of certain deep fears and anxieties emerge from nearly every page. It is by no means confined to those authors who don’t have tenure, or to those who don’t have jobs, or to those who don’t have professorial positions, or to those who do. It underlies, with few exceptions, the words of some of the most famous people in the book as well those you may have never heard of. It is to be found in praise as well as blame, and in the most earnestly dispassionate as well as the most overtly polemical pieces in the volume.

Because behind every utterance—including, for the record, mine—lies the possibility of a terrible, soul-crushing anxiety about peoples’ place in the world.

Digital humanities is the hottest thing in the humanities. Who can deny it? We read about it in the Chronicle and the New York Times. It is “the story” of recent MLA and AHA conventions. Publishers are falling over themselves trying to create new imprints and series in the Digital Humanities. And there are jobs! Not many, of course, but many more, I would guess, than are available in any other single sub-discipline of venerable giants like English studies or History.

So it is meet and good that we talk about this hot thing. But the question is this: Are you hot?

The answer to that question is “maybe.” If you’ve devoted yourself to media studies, you might be hot. Your work is often solidly focused on the digital, after all. But when people say “digital humanities,” maybe they mean something different? And maybe they mean something that’s not what you do? Maybe you’re a theorist, in any of its ramified forms (including race and gender studies). Surely every form of discourse is capable of being theorized, and there seems to be a dearth of such theorization in digital humanities itself. But what if digital humanities isn’t a fertile, open ground for theorization, but a discipline hostile to it—or worse, the very thing that is slouching forward to supplant theory as a hot thing? Maybe you’re just an ordinary historian or a literary critic or a classicist. You use computers, of course, and you’re interested in what they might mean for the future of humanistic study. But what if this hot thing means that what you do—your work on Paradise Lost, or the French Revolution, or the writings of the late Roman Stoics—is now old fashioned, out of step, or even irrelevant?

The question likewise hangs over people who are, by all accounts, squarely doing digital humanities. You might have devoted yourself to something like data mining, or GIS, or TEI, or tool building. This, surely, is digital humanities. But then perhaps such things can’t survive the withering, highly articulate attacks of the theorists (or, for that matter, the old-fashions). Maybe this is just a passing thing. Don’t you have your own doubts about it even as you engage in it? Maybe they’re right; maybe the whole thing is subtly retrograde—even reactionary. It’s undoubtedly limited—just one piece, just one form, just one thing, in the overall task of explicating the human record. But maybe it’s not enough? And can it possibly live up to the hype?

Both forms of anxiety cross lines of seniority and position. I hear it in the words old professors as well as those newly minted, from full professors to staff. Graduate students and recent Ph.Ds, it seems to me, feel it in the most profound way. Perhaps you were trained in theory or in some more conventional (and you love hearing that word!) form of humanistic study. You probably spent the better part of a decade learning to write a certain way, engage in certain kinds of conversations, and participate in certain kinds of scholarly activities. It took you years to do this, and it wasn’t easy. Now none of that seems consonant with the hot thing. To be hot, some say, you must now learn statistics, document encoding, and C++. That should take you another ten years. And at the end of it, you’ll be suffering from the same anxieties as the blessed. But not to worry: you won’t have a job anyway, because you’re just too late.

I am aware that by drawing a line between the contents of the Debates volume and peoples’ fears and anxieties I am saying something that can be taken as extremely offensive. One implication of my observations is that whenever anyone is talking about one thing, they’re really talking about another thing—that no matter how dispassionate and scholarly, no matter how concerned with the legitimate claims of probity and justice, scholarly “debates” are really just a reflection of some deeper personal conflict and worry. That’s as likely to be well received as similar observations from one’s parents (or one’s therapist). And what’s worse, these observations come from a professor of digital humanities who has tenure. Easy for him to deliver some avuncular homily about how fearful we all are!

I can only observe that one of the obvious effects of this tension between the scholarly and the personal is good scholarship, provocative discussion, and excellent teaching. I don’t think anyone can deny that, and I think the Debates volume demonstrates it amply. But there’s another effect that we cannot deny: it can also produce bitter, angry people and broken communities. And I’m not talking here about the “DH community” (if that even exists). I’m talking about people in general, communities in general, and the uneasy lines of separation between them.

I entered graduate school (with every intention of becoming a literary theorist, incidentally) in one of the worst years for the academic job market to that point. Within a few years, I had wandered into humanities computing. I knew, almost immediately, that this was where my heart lies. I also knew that I would almost certainly not get a job in it. There weren’t any jobs in it! It wasn’t the hot thing, because it was barely a thing at all. I would love to say that despite all of this, I could clearly see that this was the future of the humanities, and that by memorizing the Java API, I was positioning myself for a promising academic future. I would also like to say that it was through several prescient acts of personal brilliance and productivity that I was able to land a high-profile academic position (with tenure) at a research institution.

The truth, is that I figured that since academia wasn’t going to work out, I might as well follow my bliss. I settled into what we now call an “alt-ac” job—with absolute joy, because that job was every bit as intellectually stimulating and exciting as the one I have now. On a lark, I applied to one of the first explicit jobs in “humanities computing” that, to my knowledge, had ever been offered in the U.S. And I got it. Within a few years, I was being recruited by another institution that was building an entire program in, of all things, digital humanities.

So yes: Easy for me to say. It all worked out. Yet it didn’t save me from crushing amounts of fear and anxiety throughout the entire process. People have asked me “how I did it.” The answer, as you can see, is not entirely satisfying. And because it is not satisfying, I have found myself asking a question that I’ve been asking for a long time, but now with greater urgency: How do you keep from becoming fearful and anxious—and possibly infecting larger communities with bitterness and anger—while going through this process, whether it works out or not?

Because we have to confront the fact that there are highly successful scholars—those who appear to have ridden the “hot thing” to the highest levels of professional achievement—who are terribly bitter and who live in constant fear that it will be taken away. There are likewise people for whom it didn’t work out at all (at least, not in the way we think of it working out) who seem happy and content. And, of course, there is the reverse of this as well.

One answer might be to be as “nice” as you can and take the world as it is. But I, personally, don’t want the people who, as I said, are arguing on behalf of the legitimate claims of probity and justice to “be nice” about it, and nothing is ever accomplished in this realm by accepting the world as it is. Another answer might be to “follow your bliss,” but it won’t be bliss if you live in a constant state of worry and anxiety that this is precisely the way to end your career.

I don’t have good answers, here, though I’m inclined to think that Levinas was right and that ethics is the first philosophy. Despite some terrible associations, the word “benevolence,” which joins the concept of the “good” with the verb “to will” or “to wish,” encapsulates what I think makes communities healthy, and what facilitates meaningful interaction among people within a community and across different communities. You don’t always have to be “nice” to be benevolent. Nor do you have to suppress the more productive forms of anxiety and frustration (because these do exist) that can lead to good and useful work. The fundamental posture of a benevolent community is that it wishes its own members—and, more importantly, the people who are not members—well. It doesn’t unduly concern itself with its own survival, or even its precise definition. And it doesn’t concern itself at all with the idea that it will one day be supplanted by something else. It wishes the people it is “supplanting” well; it wishes the people that will supplant it well. And it wishes anyone who bids participation well. It might ask that people who want to participate take some time to learn what it’s about, but it doesn’t get overly exercised when this doesn’t happen (and people acting benevolently will want to do that anyway). But most of all, it doesn’t insist that people who are not doing the hot thing do the hot thing. This is the hardest thing of all, but I honestly think that communities cannot survive without this.

I, certainly, have not always acted this way, and yet I continue to think that the will for the good in others—first in thought, but ultimately in action—is both a radical possibility of the human person, and the basis of any coherent call for tolerance, openness, and acceptance. And we all know how to bring this about, because as teachers, we implicitly acknowledge the impossibility of a pedagogy that can proceed without this fundamental disposition. We teach because we wish our students well. Even when they fail. Even when they resist. Especially when they do these things.

So really, I need to qualify my initial statement yet again. I find the Debates in the Digital Humanities volume completely uplifting, not because it shows no signs of the anxieties I’ve mentioned, but because “debate” always holds out the possibility that benevolence will be the result.

I wish it well.

Class Time

2012-03-21T00:00:00-05:00

[This is a transcript of a talk I gave at NU Technology Day on March 21st, 2012. The panel was entitled, “Teaching in the Collaborative Learning Space,” and I was joined by Brad Severa, Todd Jensen, and Heath Tuttle of UNL’s Instructional Technology Group. The Collaborative Learning Space is where I teach my course on programming and software engineering for humanists.]

Who invented the classroom?

The question sounds a bit odd, because we who work in an ancient institution like the academy are inclined to think that such bedrock notions as “the classroom” are likewise ancient. But in fact, the classroom was invented by a particular group of people at a particular moment in history, and in the scheme things, that particular moment is relatively recent.

The main person behind this invention was the German Pietist educational reformer August Hermann Francke (1663-1727), who established charity schools in the German state of Prussia around the turn of the eighteenth century. Francke’s innovations included the idea of a “roster” with which one could “take attendance,” and the idea of “recess,” which originally meant not an hour of unstructured playtime in the afternoon, but a set period in which students could work the fields. Other Pietist reformers invented the concept of raising your hand to ask a question, and, most important for our purposes, the idea of desks arranged in rows.

The purpose of these innovations was to stem the chaos that, from the standpoint of the Pietists, had governed the project of education for the previous fiteen-hundred years (Francke’s first act was to shut down the thirty-seven taverns that had been serving the local population of two hundred – a beer-to-student ratio that makes Lincoln, with its many taverns, seem like a temperance society). But the underlying idea had to do with time. For most of history, the education that happened at a school happened in an entirely free-form manner. Professors gave lectures more-or-less when (and where) the felt like it, and students likewise attended those lectures when they felt like it. Students might erupt with rude questions in the middle of an oration, or stomp out in protest. Even the temporal boundaries of “being at university” were unclear; you went to school, usually as a young man, and left when you felt educated (or never left – a situation that admittedly persists to this day). Even the word “school” itself descends ultimately from an ancient Greek word, which, in addition to denoting learned discussion and disputation, was also the word for “leisure.”

The Pietist intervention put forth the radical idea that there was a time for listening and a time for speaking – a time for being educated, and a time when that process would end. Having a roster and taking attendance was a way to ensure that time had been honored – time at your desk listening to the teacher. If you raised your hand and had the floor, you could speak. Otherwise, it was someone else’s turn to speak. Even recess was a commentary on time. Class was “in recess” in the sense that a court is in recess: you might be allowed to do something else, but “the class” was still, in some metaphysical sense, in session. This allowed you to be “in a class” or “taking a class” even when you weren’t, physically and temporally, there. Luther hadn’t included Ecclesiastes in the table of contents for his 1534 translation of the Bible, but clearly, he and his followers had read it very carefully indeed.

These ideas about education and time are so firmly ingrained in the modern academy as to seem entirely immutable. Deans and provosts are glad to entertain various sorts of innovations in the classroom, but the idea of the classroom itself as something with concrete temporal boundaries is almost never in question (even in the apparently radical notion of “distance ed.”). And if you doubt that, I suggest you try reducing the number of “contact hours” (an amazing term which unites the temporal with the physical) in your class. From the standpoint of a department chair, that is not innovation, but professional malfeasance.

We’re here today to talk about a room – a rather magnificent one, in my opinion. In fact, I would say that it does nearly everything right in terms of instantiating the idea of a “digital classroom.” Everything is on wheels, there are projectors pointing at every wall, there is a computer for every student, it has an audio system worthy of a high-end coffeehouse, and the professor can stand at a podium that recalls the bridge of the Starship Enterprise. It is wired, reconfigurable, comfortable, quiet, and intimate.

And yet that space still occupies time. It still exists within a temporal framework that has seldom been tampered with in the last two-hundred years. And what’s odd about that, is that it attempts to connect itself to a world in which time is being reconfigured in extremely radical ways. Think for a moment about “email time” or “Twitter time” or “Facebook time.” The interactions here are not in “real time” (another astonishing phrase), and yet they aren’t entirely asynchronous either. You have a certain moving window in which to “keep up with email,” and a certain window before which you have to apologize for taking so long to reply. Wait too long to respond to a tweet or a Facebook update, and the moment will have passed. None of these temporal windows is very precise, but the time in which you can respond is never “now or never.” YouTube videos? Whenever you feel like it. Though eventually, the fact that you haven’t seen Chocolate Rain, Star Wars Kid, or Numa Numa will catch up with you.

Contrast this with the temporal boundaries of the modern classroom. Class is on Tuesdays and Thursdays at 11:30. Do not be late. If you fail to show up, it might affect your grade (another innovation that dates to about the same period as Francke’s classroom). The homework is due on Friday. The class begins on January 9th and ends on April 28th. You have until January 17th to decide whether you are going to continue to waste your time. After that, you’re wasting mine. And that might be a bad idea, because this all about credit hours.

These aren’t terrible ideas. Most educational reforms are lucky to last ten years; this one has endured for over two centuries, and it has done so because, up until now, it has made a lot of sense. But does it make sense, if you’ll be pardon me, now? Does it make sense in a world in which we have the ability to create spaces like the Collaborative Learning Space? Does it make sense to take the Collaborative Learning Space and embed it in a temporal framework wholly unlike the one in which it bids participation?

Call me old fashioned, but I am hesitant to jettison the circle – that most ancient of all pedagogical formations in which people converse with one another in real time. But beyond that, everything about the “new media classroom” seems to me completely up for grabs. Must the lecture happen in real time? Must “homework” happen outside of class time? Does everyone have to show up at the same time? Does everyone have to be “present?” Should the class end? Should it start?

What do I think of the Collaborative Learning Space? I think it’s the best classroom I have ever taught in. I also suspect that we are not coming remotely close to exploiting its true power, and I think it might be time to do that.

The Journal of Digital Humanities

2012-02-15T00:00:00-06:00

I was very pleased to have a piece of mine selected for publication in Volume 1, Issue 1 of the Journal of Digital Humanities.

It’s an audio recording of a talk I gave (entitled “Textual Behavior in the Human Male”) at the inaugural symposium of The Institute of the Humanities and Global Cultures at the University of Virginia. The abstract read as follows:

Does digital humanities represent an attempt to “scientize” humanistic inquiry? Some would welcome such an move, and much work in digital humanities is closely aligned with practices and methodologies usually associated with the sciences. This talk places digital humanities within the context of a broader history involving the rise of the social sciences in the twentieth century, and suggests ways that we can think about computation and computational work without abandoning methodologies unique to humanistic study.

All of the presentations from the symposium are being reviewed for the journal, through an open peer review process, until February 19th.

I’m a bit of an anarcho-communist when it comes to scholarly publishing, as most of my readers already know. And I’m particularly excited by the idea of open peer review for scholarly work in the humanities. Often, the “open” part of open peer review means “transparent:” the identity of those commenting and the comments themselves are visible to everyone. The idea of inviting particular individuals into the review process is not incompatible with this idea, but it’s possible to conduct a fully “open” review: not only transparent, but open to anyone who wants to offer their opinion. That’s the form that JDH is using for this round. There’s an audio file of my talk, and there’s a comment thread. Have at it.

But, of course, this only works if people do, indeed, have at it. So this post is a quiet plea for people to participate in the process – with all of the work that’s being reviewed for this first issue. I think this is an opportunity for the DH community to demonstrate that we can conduct an open peer review process that has as much integrity and usefulness as the older systems of anonymous, invitation-only review. But right now, the only comment on my piece so far has been this one:

These are genuinely enormous ideas in concerning blogging. You have touched some nice points here. Any way keep up wrinting.

Certainly, I’m delighted to have my ideas described as “enormous” and to be encouraged in my wrinting, but I’m not sure this is what the editors had in mind.

The other exciting thing about JDH, of course, is their willingness to publish things in alternative formats (something they share with Digital Humanities Quarterly). Like most digital humanists, I’m really interested in such alternatives. But audio presents particular challenges. This is a recording of a live event; I can’t very well go back and change it in light of peoples’ comments.

Or can I? Maybe I’ll a create a slide show that shows some objections to what I’m saying (while I’m saying it). Maybe I’ll invite people with interesting alternative perspectives to record themselves, and then splice that into the audio stream. Maybe I’ll do something you suggest (in the comment stream, of course).

Once again, I’m very pleased to be in on this first issue. I hope you’ll help the contributors and editors to make it a really strong premier.

Conditions

2011-11-29T00:00:00-06:00

I am pleased to announce the source release for Conditions – a suite of fast command-line programs for retrieving weather information from Weather Underground.

https://github.com/sramsay/conditions

Conditions consists of six commands (more on the way):

conditions reports the current weather conditions.
forecast gives the current forecast.
alerts reports any active weather alerts.
slookup allows you to determine the codes for the various weather stations in a particular area.
astronomy reports sunrise, sunset, and lunar phase.
almanac reports average high and low temperatures, as well as record temperatures for the day.

I’ve compiled it on both Linux and OS X without incident. Since this is a source release, you’ll need a working Go compiler. I will release binaries for several platforms soon.

I wrote conditions in part because I am a weather geek and CLI nut, but partly to explore the Go programming language. Go, I’ve discovered, is basically a re-imagined C – all the low-level, high-octane joy with all the irritations removed. I’ll try to write a blog post about that sometime soon.

In the meantime, I hope you enjoy Conditions. Patches and bug reports warmly welcomed on the GitHub site.

Nebraska Cluster Hire in Digital Humanities

2011-10-19T00:00:00-05:00

In my travels of late, I’ve become acutely aware of what a big splash my institution is making with the announcement that we intend to hire six (six!) new faculty members in digital humanities. Here, once again, is the job ad for the first round:

The University of Nebraska-Lincoln (UNL) announces a cluster hire in digital humanities: over the next three years the university intends to hire six tenure-line faculty members across a number of departments (and additional staff) to further propel this signature program. In the first phase of this effort, we seek promising candidates for tenure-track appointments at the Assistant Professor level. Initial interviews will be conducted at the Modern Language Association (MLA) and American Historical Association (AHA) conventions in January 2012. Candidates should be accomplished digital humanists able to contribute to a thriving interdisciplinary initiative and to the home department. Candidates must provide evidence of successful teaching and an active research agenda. PhD required by August 2012. The participating departments seek specialists who would contribute to the UNL’s research profile and teaching capacity in digital humanities. Candidates whose work focuses on comparative or transnational literatures, histories, and cultures are especially invited to apply.

Applicants should go to http://employment.unl.edu, requisition 110758 and complete the Faculty/Academic Administrative Information form and apply online. Applicants should be prepared to attach the following to their online application: a letter of application, a curriculum vita, and a PDF or a link to one representative sample of their digital work. Please do not send paper applications. Review of applications will begin November 1, 2011, and continue until suitable candidates are found. For further information contact Kenneth Price, chair, search committee at 402-472-0293 or kprice2@unl.edu. The University of Nebraska has an active National Science Foundation ADVANCE gender equity program, and is committed to a pluralistic campus community through affirmative action, equal opportunity, work-life balance, and dual careers. Web sites: [http://cdrh.unl.edu/, http://www.unl.edu/]

People have begun to ask me what we’re looking for in a candidate. It’s a natural question, but actually, one of the most exciting things about this job ad (for me, at least) is how utterly non-specific it is. We say nothing about particular areas of interest, the research profiles of the people already here, or even what departments are involved. In fact, the reference to MLA and AHA as sites for “initial interviews” might be misinterpreted to mean that we’re mostly interested in people from History and English. In fact, we’re interested in just about anyone in digital humanities from any department or discipline whatsoever, and would be happy to conduct interviews in any venue that seems appropriate.

I realize that such open-endedness can seem slightly inscrutable, but I hope it’s interpreted as a genuine desire, on our part, to be open to any and all forms of digital humanities. When I took my first professorial job (specifically in DH), I remember asking someone what they thought DH was going to be about at this university. They responded by saying, “Well, I suppose we’re waiting for you to tell us!” That’s a good attitude to have as a junior faculty member, and it’s even better advice for a more senior one listening to such articulations. We’re very eager for you to tell us what you’re all about – and about what you might bring to DH at UNL.

I will say, though – and here I have no intention of being evasive – that UNL is an extremely exciting place in which to pursue research and teaching in digital humanities. The institutional support runs clear to the office of the President. We’re supported, as well, by faculty, department chairs, and deans who are genuinely open to what we’re doing and extremely flexible when it comes to fitting work in DH into more conventional processes of evaluation. My colleagues in DH are among the smartest, most imaginative people I’ve ever met. It’s a genuinely thrilling place to work.

And let it also be said that Lincoln is wonderful place to live. I had plenty of biases and preconceptions about the midwest before moving out here (after a life spent entirely on the east coast). Those thoughts now embarrass me thoroughly. It’s a great town in a great part of the country, and I fall more and more in love with it with each passing year.

I suppose I need to say that my thoughts on this series of hires do not necessarily reflect the opinions of the insitution, the search committee, or anyone else involved with the project. But I also need to that say we’re all looking forward to the process. It’s a very exciting time for a very exciting program, and we look forward to hearing from you.

Fr. Roberto Busa, S.J. (1913-2011)

2011-08-11T00:00:00-05:00

Last night, I learned of the passing of Roberto Busa – a man that many consider the founder of Digital Humanities.

In recent years, people have called that lofty title into question, and not without justice. It seems that Busa was one among the many who were striving to bring computer technology – then in its early infancy – to bear on humanistic problems back in the forties. Like most DH scholars today, he was part of a much wider intellectual network.

But when I was starting out in the field, it was taken more-or-less for granted that Busa had started it all, and it’s not difficult to understand why. He was a Jesuit – a member of that most troublesome of religious orders, universally renowned both for its learning and for its many provocations both theological and disciplinary. His project recalled the ancient roots of the European university itself: a massive concordance to the works of Thomas Aquinas, who was himself a scholar and an intellectual revolutionary. It’s undoubtedly the case that many at the time were thinking of ways to use computers to conduct research in the humanities, but the scale and sweep of Busa’s project stands alone. It’s a story about old becoming new, and yet about continuity with the past.

His 1980 essay “The Annals of Humanities Computing: The Index Thomisticus” used to be required reading of sorts for people starting out, and it’s still my favorite. It’s a personal essay on how the Index came to be. The beginning is unforgettable:

I entered the Jesuit order in 1933. I was then 20. Later my superior asked me: “Would you like to become a professor?”

“In no way!” My wish was to become a missionary to take care of the poor.

“Good. You’ll do it, all the same.”

The subject of Busa’s research – and the occasion for creating the Index – was detailed study of the notion of “presence” in Thomas. Perhaps the New Criticism was taking hold in some other part of the world, but for Busa, philology was the proper hermeneutical framework.

[A]ll functional or grammatical words (which in my mind are not “empty” at all but philosophically rich) manifest the deepest logic of being which generates the basic structures of human discourse. It is this basic logic that allows the transfer from what the words mean today to what they meant to the writer.

The methodology for exploring that logic was clear enough:

According to the scholarly practices, I first searched through tables and subject indexes for the word praesens and praesentia. […] My next step was to write out by hand 10,000 3” X 5” cards, each containing a sentence with the word in or a word connected with in. Grand games of solitaire followed.

Busa himself eschewed the title of founder, and goes out of his way in this essay to list the others whom he thought were far ahead of him. But how can we deny the title to someone who writes:

It was clear to me, however, that to process texts containing more than ten million words, I had to look for some kind of machinery.

(If you’re not ready to do the first ten million by hand, you’re simply not in the good Father’s philological league).

He eventually made his way to IBM. In fact, he made his way to the office of Thomas Watson himself:

I knew, the day I was to meet Thomas J. Watson, Sr., that he had on his desk a report which said that IBM machines could never do what I wanted. I had seen in the waiting room a small poster imprinted with the words, “the difficult we do right away; the impossible takes a little longer,” (IBM always loved slogans). I took it with me into Mr. Watson’s office. Sitting in front of him and sensing the tremendous power of his mind, I was inspired to say: “It is not right to say ‘no’ before you have tried.” I took out the poster and showed him his own slogan. He agreed that IBM would cooperate with my project until it was completed “provided that you do not change IBM into International Busa Machines.” I had already informed him that, because my superiors had given me time, encouragement, their blessings and much holy water, but unfortunately no money, I could recompense IBM in any way except financially. That was providential!

Is it any wonder that Busa became the patron saint of DH? John Unsworth, in a talk a few years ago, noted, “Most disciplines can’t point to a founding moment, much less a divine one.”

(I assume the non-DH-er in that photograph is Pope Paul VI)

And then there’s this:

I feel like a tight-rope walker who has reached the other end. It seems to me like Providence. Since man is a child of God and the technology is a child of man, I think that God regards technology the way a grandfather regards his grandchild. And for me personally, it is satisfying to realize that I have taken seriously my service to linguistic research.

Those words, written thirty years ago, are of a man who intends to live long and well.

And he did.

The Man-Finger Aftermath

2011-08-05T00:00:00-05:00

There was a spirited discussion about The Mythical Man-Finger yesterday in the comment thread and on Hacker News, and I want to thank everyone for some very thoughtful insights.

A couple themes emerged that I want to touch on.

In my view, the power of textual interfaces has been neglected, because we’ve all more-or-less accepted the GUI as the best way to do things – especially for “non-expert” users. One of the things that’s potentially confusing in this conversation is that we tend to conflate the UNIX command line with textual interfaces in general. It’s a defect in my own treatment of the subject, and I probably should have done a better job separating the two. I think there are many excellent textual interfaces in the UNIX environment, but taken as a whole, it’s probably not cogent to suggest that the UNIX CLI, as currently conceived, is a model interface for ordinary computing. I still insist that some very routine, userland things are considerably easier to do on the command line than with a GUI, but that’s not the same as saying that we would all be better off in Bash.

For me, though, the most fascinating part of the discussion thread involved trying to tease out what is lacking in the UNIX CLI. Amanda French began by noting (and her thoughts were widely echoed) that it’s easier to “figure it out” with a GUI. If you want to do something, you can usually poke around the menus and get something going (even if you’ve never used the program before). I think there are limits to this. Very complicated graphical systems like PhotoShop can tie you in knots just as efficiently as any complicated textual interface; the thing you want to do is greyed-out, because you didn’t open the dialogue to reset set the alpha-channel … But I take the main point. GUIs are a lot easier to approach if you’re a new user. Many noted the fact that the “play” icon on a desktop will often display a musical note, a speaker, or the standard transport control symbol for “play;” the blinking cursor gives no indication whatsoever of how to proceed with anything.

On the other hand, that same approachability may become a liability when you get used to the program. Once you know how to do it, the endless mousing around can feel unduly laborious. Many complicated systems have “macro” facilities (a textual interface) for automating tasks. They also often have some kind of “record action” facility, which I (and, I suspect, many others) find frustratingly difficult – not because they don’t work, but because it’s hard to get through a complete mouse-click sequence without making a mistake. I suspect such systems are not used as much as they might be, because not a lot of thought has been devoted to thinking about the usability of such interfaces (they’re for “experts,” after all).

Some noted that it is precisely the sense of interface affordance that is lacking, and this seems to me one of the most important points. How do I know what is possible? Several mentioned autocompletion as a partial solution, and noted that such systems are not nearly as deeply implemented as they might be. Is it possible to imagine systems that look at your commands and show you options that are relevant to the particular thing you’re trying to do (based on analysis of the current state of the command)? What about hybrid systems that combine text with some visualization of context-sensitive possibilities?

I suppose my main point here (now offered with the benefit of everyone else’s reflections) is that we would do well to approach these limitations as research problems, and not as settled truths about HCI. No one denies (I think) that that there are many advantages to textual interfaces along with various deficiencies. The problem, as I see it, is that we’ve largely consigned this entire method of interaction to the dustbin of history (and to the workstations of so-called “power users”).

Several mentioned Ubiquity – a system that I greatly admire, and that has inspired me to think about different ways to interact with systems that are right now “GUI-only.” I’ve also been inspired by Quicksilver (Gnome DO and others on Linux) – a hybrid text-graphical app launcher that is very high on the list of things I wish I’d thought of.

But actually, the application that got me on this jag in the first place is, of all things, Xtranormal. Xtranormal is extremely clever, of course, and many people have done extremely clever (not to mention hilarious) things with it. Not many, though, have remarked on its quite radical approach to interface. “If you can type, you can make movies” (as it says on the home page), and it’s really true. I doubt that people spend a lot of time trying to figure out how to use it, and yet it is at some basic level a “scripting” language that uses batch-execution.

When I first saw that – and then saw a group of technologically skittish K-12 teachers use it to great effect – it really changed the way I think about HCI. Granted, it’s not a command line. But it also doesn’t do the usual thing by trying to make sure that the entire system is picture-and-index-finger. Some people in the thread noted that some systems are just impossible without GUIs (presentation software, spreadsheets, video editing, 3D modeling), but I have to admit that I’m not sure that’s the case. I, for one, would like to see a “script”-based equivalent to PowerPoint (or even iMovie) that works like Xtranormal; or a 3D system that uses a simplified DSL; or an alternative to spreadsheets (an already pretty textual interface) that tries to incorporate natural language awareness. In fact, I’d like to devote the rest of my life to building systems like that.

And so it has been bracing to read these comments, which seem to me very prescient in the way they crystallize both the power and the remaining challenges of textual interfaces.

The Mythical Man-Finger

2011-07-25T00:00:00-05:00

A few weeks ago, I wrote a post called life on the command line, in which I noted that I have almost completely stopped using graphical tools on my computer. Since it was a blog post, I went further and made the observation that the command line is:

faster, easier to understand, easier to integrate, more scalable, more portable, more sustainable, more consistent, and many, many times more flexible than even the most well-thought-out graphical apps.

I also suggested that this is a “wonderful way to work” – and implied that most people would find their computational lives immeasurably improved if they would switch. I tried to explain that in most respects, I am an ordinary user (in that ninety percent of what I do on the computer is the same as what everyone else does).

The comments that followed were mostly as I imagined they’d be. Most began by offering some appreciation for what I was trying to do, but in the end, accused me of gravely misunderstanding peoples’ relationships with computers. Aimée Morrison wrote:

I’ve just read (yet) a(nother) book on design, and you, my friend, are the elite user. The expert. The most hardcore of the hardcore. I might be (well, I am) an explore, the next category of user. Together, your people and my people make up a tiny fraction of all people. […] The vast majority of people just want things to work, and to not harass them with too many options or require too much learning. I admire that kind of pragmatism, actually.

Nathan Kelber:

Most people see computers like appliances. You might use an oven to bake a cake or a toaster to make toast. You use a computer to check email or write documents (not files!). They want a toaster that toasts to the right color of brown. They don’t care if it could make waffles, because they want to make toast. The easier that is, the better. This is the philosophy of Steve jobs: “It just works” or it works “automatically.” Why would you want to know how it works? It’s doing that work so you don’t have to waste time doing it yourself.

This is the common liturgy of user interface design. “Most people” want it to “just work.”

I don’t disagree with that at all. But there’s a logical leap being made here that I think is dead wrong – namely, that graphical user interfaces, as such, are in a better position to make things “just work” than textual interfaces of the sort typified by the command line.

The GUI revolution entailed a radical shift in the “haptic” characteristics of human-computer interaction. Before the GUI, you interacted with a given application by learning its textual language. Electronic card catalogs worked this way, accounting applications worked this way, games worked this way. The application would have a domain-specific language you needed to learn in order to use it, and so you would learn that “language.” This nearly always meant learning some vocabulary and some syntax, though it usually didn’t amount to anything like programming (let alone learning a natural language). At the same time, it often inherited some of the features of both coding and natural language—namely, the ability to combine things in novel ways in order to accomplish some specialized task. Of course, there were bad textual languages and good ones, “intuitive” interfaces and non-intuitive interfaces, just as there are today.

The GUI was, of course, about graphical applications, but it was more fundamentally about the mouse. The mouse essentially replaced language with the index finger. If you wanted to do something, you pointed at it. To this day, there are some applications that are hard to imagine under any other regime. If I want my cell phone to tell me the weather, I tap my index finger on the icon with the cloud on it, and up pops the weather. It just works.

This is, without any doubt, one of the most elegant ideas in the history of computing. Most of us, on encountering it for the first time, understood its power immediately. In fact, I remember the very first time I saw one. The person demoing it for me kept saying, “Look, all you do is point and click!”

But of course, very few applications on a computer system are so simple. If I want to a listen to a song, I presumably just click on it. But the song is in my music folder, which is in my home directory, which is on a drive labeled “Computer.” Easy enough, I suppose.

But really, not very easy at all. In order to do that, I have to already understand a “language” with a quite involved syntax. Folders are “nested,” and they reside on “drives” (which are like folders, but different). Folders will remain open until you close them. And the language of folders has different dialects—the way you move through folders when you are using a menu is different from the language you use when you click on them directly. Sometimes you go down, but sometimes sideways. It’s all just point and click. It’s all just point and click. And some sliding. And some selecting.

Now, we could design a system that allows you to type:

play "Teenage Dream"

and it would go find that song and play it.

What is most interesting about such a system, however, is that it almost immediately suggests several fairly trivial improvements. For example, we could give “play” some additional commands that would make it easy to do common things:

play last

(would play the last song “play” played)

play random

(would choose a random song among a list of music files on the system)

In fact, dozens suggest themselves:

play repeat

play 10 random

play softer

play random country

...

Of course, the invocation of the “play” command might open some kind of environment in which you can just say things directly:

repeat last, softer

10 random country, then "Teenage Dream"

pause

show artist

I’m typing off the top of my head, here, but it seems to me that a system like this is simpler in every way (many, many UNIX commands work more-or-less like this, though that is not really my point here). There is a language – and that language has to be learned – but it’s able to leverage our ordinary experience of language in ways that make things considerably less unintuitive for the uninitiated.

The power of this representation, though, goes much further. More difficult things can build upon the general pattern that evolves from the syntax:

create playlist "country plus katy" from last 11

show playlists

Harder, but are we really ramping up the difficulty considerably over what we can achieve with a GUI? The GUI version of that last command isn’t hard, but it’s … fussier. It no longer “just works.” It’s pointing, and clicking, and pointing, and clicking. And it’s probably not quite like the other operations. The language version adds a couple of flourishes to the general pattern, but does so in a way that is easily learned (and can now be used in dozens of syntactically similar contexts).

Now, perhaps you’ve gotten this far and you have a dozen objections to what I’m saying. “Now I have to learn all these commands!” is one, though I would point out that you have to learn all these clicking and selection patterns (often with meta keys) to do it with the GUI. “Yeah, but really complicated things are going to require searching through manuals.” Maybe, but you already do that in the GUI, and very often you have to do that to accomplish some of the simpler tasks above. “This is just dull looking!” A matter of taste, perhaps, though nothing about my system precludes graphics. “show album cover” might display the album cover in all its glory. “show lava-lamp” might amuse you for a few moments.

But here’s one thing that I think is a truly nonsensical objection: “Systems like this are for power users.” How? Why?

Ever play Pictionary? Pictionary is a brilliant game. You get a card that describes some concept—say, “return address.” You have to communicate that idea to other people, but here’s the thing: you can only use your index finger (extended, McLuhan-style, with a pencil). Before long, people are laughing. “That’s not an envelope!” “Yes! Look, that’s a house, and that’s a letter, and that’s an arrow!” Much laughter ensues.

In the real world, we’d say, ”I’m thinking of a return envelope.”

I realize the analogy is a bit strained, but my point is simply this: the idea that language is for power users and pictures and index fingers are for those poor besotted fools who just want toast in the morning is an extremely retrograde idea from which we should strive to emancipate ourselves.

The problem with the user categorization narrative, is that it uses “it just works” as a cover for saying “people aren’t capable” – for implying that millions of natural language speakers would be too intimidated by languages thousands of orders of magnitude smaller than the ones they use effortlessly every single day. It imagines that if we can find the right user-interface “metaphor,” everything will click.

I think such metaphors are rare with computing. The much-vaunted mouse is often celebrated as an “intuitive” device, despite the fact that not one single object in the entire natural world behaves the same way. The blur of nonsensical metaphors (desktops with wallpaper, control panels with hammers, etc.) has been amply discussed by others. Much research in human-computer interface design has been devoted to getting the metaphors right. But after decades, we seem to have made very little progress on this front (choosing, instead, to naturalize the “language” of these things as if they were the most natural things in the world). Perhaps it is time to reconsider whether the tools we’ve chosen (pictures and index fingers) just simply don’t lend themselves to easy metaphorization in many, if not most, domains.

What I find distressing about modern user interface design, is not that it strives to create better metaphors, but that it has radically limited itself to a very constrained set of ideas about what is possible. Whatever system we’re designing, we design within the realm of pictures and index fingers. We argue endlessly over color, and screen regions, and steps, and flow, but the ground truth of our efforts doesn’t change. Ideas about using more than one finger (“gestures!”) or using your whole body (“Kinect!”) are greeted as thunderous breakthroughs. Think of the possibilities!

Well, we should think of the possibilities. But we should also question whether our irrefragable ground assumptions are correct: commands are for geeks, mice are for moms.

Because if we can do that – if we can just open ourselves once again to the idea of language-based interfaces – we just might make meaningful progress on designing command languages that leverage all the things that language is good at (and that pictures are distressingly bad at): speed, “cross-app” integration, scale, portability, sustainability, consistency, flexibility. Right now, anyone who even proposes to work in this area is just an expert that lacks the self-awareness to realize their expertise – a hard-core geek who only knows how to design things for other hard-core geeks.

I suppose I am a hard-core geek. But I do know one thing: All of my users speak and write. And when language fails them, they start pointing fingers.

[UPDATE: I summarize and respond to some of the many excellent comments in The Man-Finger Aftermath]

Back to the Roots Web with Jekyll

2011-06-13T00:00:00-05:00

A few weeks ago, I wrote a post about how I had more-or-less stopped using graphical applications. In that post, I championed the command-line as a user interface that is superior, in many cases, to the ones to which we have grown accustomed. This, of course, was met with a storm of derision and ridicule. The mere mention of that post during THATCamp last week – THATCamp! – sent an entire table full of geeks at the Auld Shebeen into hysterics. Even some of the people who agree with me on the primacy of building in DH felt it may have been bad for the revolution. Everyone should build? Fine. Everyone should “code?” Okay, maybe. Everyone should use Bash? Well, that was a Forth Bridge too far for many.

Now normally I’d deal with this kind of public humiliation through a combination of childhood regression therapy and unfollowing people on Twitter. But one of the respondents to that post, Chad Black provided another outlet. “So, when do you ditch WordPress for something like Jekyll?”

And what, pray tell, is Jekyll?

Jekyll, my gui-besotten unfriends, is the best blogging platform I have ever seen. You run it, predictably, on the command line. ¹

To understand what Jekyll is all about, it’s useful to understand a bit of the history of web application development.

Back in the mid-to-late nineties, most sites on the web were “static.” That is to say, most websites consisted of HTML files sitting on a file system. It’s not that there weren’t any dynamic elements to these websites. We had lots of CGI-scripts for generating dynamic things, and we had (an inconsistently implemented) Javascript. We would also build lots of filters and ad-hoc templating engines (often in Perl) for reducing redundancy. Our sites obviously weren’t as sophisticated as they are now, but they had one distinct advantage: the “website” was something you could poke around in by moving around the filesystem and looking at the various files. Static HTML in one directory, CSS in another, CGI scripts over there, etc.

Now, there were some problems with this. Good software engineering suggests that one shouldn’t mingle the content, the control/rendering logic, and the display layer of a software system. These different layers should, indeed, be so radically decoupled from one another that, ideally, you could pull one component out and replace it with another. This seemed very good to all of us who were growing up as web developers, because we were all learning Java at the same time. And Java was all about Good Engineering. At least, we thought it was at the time.

There was nothing about the static site that actively prevented SoC (Separation of Concerns) or MVC (Model-View-Controller) or the deployment of any other three-letter acronym, but it was easy to violate these principles, and beginners – which meant just about all of us – had a hard time getting it right.

Some time around the turn of the decade, it became absolutely de rigueur to move the content of your site off the filesystem and into a relational database. This was how serious websites were put together, and if you didn’t know what third normal form was, it meant you were an amateur.

Web development became – overnight – a much more complicated affair. In fact, that was precisely the moment when you could no longer put “HTML” on your resume and expect to be taken seriously. Website development was starting to become an engineering problem for engineers, and the much-vaunted Separation of Concerns began to be more fully extended to the team itself. Designers would now design, RDBMS-ers would M, and middleware programmers would keep the whole thing glued together.

But just as, in a capitalist society, a market will emerge wherever value is assigned, so, in a technological society, a Framework will emerge wherever complexity develops. Before long, separating concerns became a complicated enough problem in itself that it required entire systems for managing it. We’ve been there ever since. If you’re building a Serious Website, you’re supposed to be doing it with Rails, or Django, or Cocoon, or Zope, or any one of dozens of Web Application Frameworks, some of which date back to this period.

It would be hard to lament any of this too strongly. Web development is a complicated affair these days because we want to do much more sophisticated things, and it’s hard to imagine doing it without some kind of framework. But even back when everyone (including me) was moving to databases on the back end, there was a small voice in the back of our heads – an embarrassing one, really, because what did we know? – that kept saying it over and over: This is too fucking complicated.

That voice is usually suppressed by the undeniable fact that you can throw one of these heavy-duty SoC-ed and MVC-ed websites together in minutes using any one of these frameworks. But the voice will return at some point, because (and I’m hardly first to note this) web application frameworks tend to make the standard case simple and the edge case damn near impossible.

The latter situation emerges, I think, because of what was lost so many years ago. You just can’t walk around your own website and figure out what is going on. For me, this is most frustrating with things like blogs. “Where are my posts?” I ask WordPress. “Here they are, sir!” is the reply. But where is that, exactly? I’m well able to move around a MySQL database, but the whole purpose of this framework – of any framework – is to make it so you don’t have to do that. And you don’t, until you have to. And then you find yourself in a terrible, horrible, no good, very bad place.

Tom Preston-Werner, the designer of Jekyll, describes it as follows:

Jekyll is a simple, blog aware, static site generator. It takes a template directory (representing the raw form of a website), runs it through Textile or Markdown and Liquid converters, and spits out a complete, static website suitable for serving with Apache or your favorite web server.

That almost makes it sound like the next big thing. In a rational universe, it would be (at least for some use cases). But actually, it’s a quite old thing. If there was such a thing as “roots web” (on analogy with “roots music”), this would be it.

Before I go any further, let me say that I think Wordpress is a fantastic piece of software (I am, after all, helping to develop a system that is entirely dependent on the Wordpress platform). “Jekyll vs. Wordpress” and “static vs. dynamic” bear all the marks of the beast in terms of potential for religious warfare, and I have no interest in this at all. But it is worthwhile noting what’s good about a system like Jekyll.

First, it brings us back to Total Information Awareness (if you don’t remember that term, you weren’t developing websites ten years ago). The content is in this directory, the stylesheets are in this one, images are over here, and so forth. If an image is broken or the styling is wonky, you don’t use the dashboard to find the tool menu (?) in the hopes that you can figure out which source to view. You go pretty much where you’d expect to find the problem.

Second, you can work in your own environment. Now, it’s true that my environment tends to resemble those used during the Carter administration, but it need not be this way. It is important, though, that you be able to use your own tools. I am a passionate believer in a piece of advice that I learned from the Pragmatic Programmers: “Use a Single Editor Well”

[M]ake sure your editor is configurable, extensible, and programmable. […] If you use a single editor (or set of keybindings) across all text editing activities, you don’t have to stop and think to accomplish text manipulation; the necessary keystrokes will be a reflex. The editor will be an extension of your hand; the keys will sing as they slice their way through text and thought.

TinyMCE is a lovely little thing, but if I had to do everything with it, I would shoot myself immediately.

Another extremely useful thing about Jekyll is that everything is in plain text. This doesn’t sound like a big deal, but it’s one of the cornerstones of the UNIX philosophy and a damn good idea for just about any kind of data you actually care about.

Plain text is the only digital format that has persisted for decades without serious challenge. It runs on literally every computational platform in existence and can be munged into any other format that comes along. It can also be manipulated using more tools than any other kind of data. Vaunted claims are made for the ways in which things like XML facilitate long-term preservation and access, but nearly all of that benefit arises from the fact that it’s plain old text. Switch to text (which includes things like XML, LaTeX, and CSV), and you’ll never again have the problem of migrating data from one spreadsheet, word processor, or data analysis system to another. You’ll also find it easier to backup, easier to put under version control, and easier to sync. I can open anything I’ve written since 1999 right now without the slightest bit of ceremony, and I can generate any other format that might be needed relatively quickly. That is not possible even with the most popular formats in common use.

Jekyll even takes that one step further by embracing Markdown as its markup language for posts. Markdown not only uses plain text, but uses the kind of highly intuitive markup system that people tend to invent spontaneously when writing things in a plain-text editor. With the right tools, you can translate the Markdown texts into HTML, LaTeX, or PDF. More importantly, you can do that even if you don’t have such tools (which will be the case for your data some years hence when platforms and formats that have yet to be conceived will suddenly exist).

The greatest thing about Jekyll, though, is that it makes things only as complicated as they need to be. It used to be said of Perl that it makes easy things easy and hard things possible. It don’t know if that was really true of Perl, but it’s certainly true of Jekyll. It’s just enough scaffolding to prevent website development from becoming a tedious chore, but not so much that the implementation of some genuinely complicated feature requires comprehensive understanding of the deep recesses of the platform.

Needless to say, I’ve migrated my entire blog from WordPress to Jekyll, including all comments (now hosted on Disqus). In fact, this site does everything the old one did, and also functions as a more traditional home page (a thing that I always found irritatingly difficult with WordPress).

Right now, Jekyll and its relatives are geek territory, but soon I think we’ll start to see “out-of-the box” versions of static site generators that make it “trivially easy for anyone to generate a complex website” using a brilliantly architected framework. If you’re a web developer, my advice would be to enjoy the moment before the cycle begins again.

That’s not strictly necessary. It would be pretty easy to run Jekyll (or one of a dozen similar systems) entirely from, say, a capable editor like NoteTab or TextEdit using some simple launching scripts.
↩

Prison Art

2011-06-10T00:00:00-05:00

[This paper was presented at the Digging into Data Conference in June, 2011. It was a response to Data Mining with Criminal Intent – one of eight projects developed under the auspices of the Digging into Data Challenge (funded by NEH, NSF, SSHRC, and JISC). “Data Mining with Criminal Intent” worked with data from The Proceedings of the Old Bailey, combining Zotero (for data management) with TAPoR tools (like Voyeur). The project was the work of a group of scholars from Canada, the UK, and the US, including Dan Cohen (US Lead), Tim Hitchcock (UK Lead), Geoffrey Rockwell (Canadian Lead), Cyril Briquet, Frederick Gibbs, Jamie McLaughlin, Joerg Sander, Robert Shoemaker, John Simpson, Stéfan Sinclair, Sean Takats, and Bill Turkel.]

I think this work is completely brilliant. I am compelled to say that, of course, because I’m friends with many of the people on the team, and I don’t know that they’d keep working with me if I got up and said it was terrible.

I go way back with a few of them – back far enough to remember a time when an event like this would have seemed completely unimaginable. We did imagine conferences in which classically-trained humanists got together to geek out with maps, graphs, trees, and code. We also imagined that there would be no more than eight of us in attendance. An international grant competition funded by four major agencies, that would culminate in a conference attended by members of the media? I’ve been suppressing the urge to laugh since we began.

I recall a particular moment, in 2002 or so, when I gave a talk with Stéfan Sinclair, Geoff Rockwell, and a few others on a panel entitled “New Directions in Text Analysis.” You must understand, 2002 was eons ago. TAPoR had just been funded, Stéfan was demoing Voyeur’s great grandfather, Zotero did not exist (the world was condemned to EndNote), the Proceedings of the Old Bailey did not exist (though it was about to), and I was showing off visualizations of the Moby Shakespeare collection. Text analysis was a minor act in DH (most people were busy creating the data that we are just now beginning to dig). But the “age of tools” was starting to emerge, and revolution was in the air. So we all got up and made the following points (aimed squarely at the older guard):

Text analysis is a hidebound backwater.
It’s a backwater, because the people who do it are trying to escape the complexities of humanistic inquiry by trying to be scientists.
This will never lead anywhere, because the questions that interest humanists are not tractable through purely scientific methods.
The way out is to embrace a spirit of play, to recover the rhetorical posture of inventio, and to place subjective engagement at the center of digital humanities.
You guys suck at science.

We were a little more polite than that, but you get the idea.

Our words were variously received. Some said that we had said what needed to be said. On the other hand, I remember one aged member of the text analysis community magisterially declaring that we could play with ourselves all we want. I will never forget one comment, though. A neither aged nor particularly cantankerous member of the text analysis community surveyed our graphs and visualizations, stood up, and said, “Isn’t this just art?”

He didn’t mean it as a compliment. What he meant was that data visualization informed by humanistic values is neither fish nor fowl. It neither provides the facts upon which science thrives, nor the themes and patterns that sustain humanistic inquiry. It is, at best, a kind of amusement. Beautiful, perhaps – maybe even profound in its own way. But not to be confused with serious academic scholarship.

The work presented here seems to me impeccable on at least two vectors. First, it’s built with well-architected, well-engineered code by people who know what they’re doing. And that’s a phenomenon that extends all the way from the unseen spheres of the backend datastore to the glorious glamour shots up front. I’m not sure the DH community knew how to build software when the revolution started. We do now. Or, at least, these guys do.

The second vector that impresses me is the “sciencey” part of it. Because part of what these guys are doing is, assuredly, based in the customs and methods of science. That was perhaps the point upon which we protested too much ten years ago. The truth is that digging into data is about numbers, statistics, curves, ratios, control groups, and experiments. This project’s indebtedness to science is everywhere apparent, and there’s no reason they should deny it, even if there perhaps was a reason to deny it ten years ago.

But what really impresses me about this project – what, for me, injects a sense of actual joy into it – is a line offered on the very first page of their whitepaper: “Given that the Old Bailey contains about 127 million words of text related to past crimes, we knew that there would be unusual and compelling stories to be told.” Perhaps it’s just the disarming folksiness of that phrase that I find so charming (it’s hard to imagine the scientists and engineers who built the Large Hadron Collider telling their funders that they expect “good stories” to emerge from their efforts). But actually, I think there’s something serious being put forth with that line – something that represents an important moment of maturity for digital humanities, and for the project of large-scale data analysis in general.

If the creators of this project are unabashed in their use of scientific tools and methods, they are likewise unapologetic in their description of why they are doing so. The Old Bailey, like the Naked City, has eight million stories. Accessing those stories involves understanding trial length, numbers of instances of poisoning, and rates of bigamy. But being stories, they find their more salient expression in the weightier motifs of the human condition: justice, revenge, dishonor, loss, trial. This is what the humanities are about. This is the only reason for an historian to fire up Mathematica or for a student trained in French literature to get into Java. The authors express some worry about the fate of what they call “Ordinary Working Historians” or OWHs (an acronym that, when pronounced, makes the sound of exasperation) – and they are right to have this concern. But I think we can feel completely confident that they will eventually reach that audience. Because if there’s one thing that’s better than theorizing about interface usability and intuitiveness and transparency, it’s sharing the concerns of your users. And they do.

Perhaps we should ask of this project (and of all the projects we’ve looked at thus far): Is it just art? I, for one, am ready to say “yes.” You come to it to be changed, but also to be reaffirmed. You struggle with its novel logics and modes. You sometimes marvel at it. Often, you don’t understand it at all. It rewards patience. It values adaptation. It speaks to the individual and to the group. It lies to you. It tells you the truth. It makes you look good.

Reading Machines: Toward an Actual Publication Date

2011-05-05T00:00:00-05:00

I am very flattered by the number of congratulations I’ve received on and offline for the publication of my book, Reading Machines: Toward an Algorithmic Criticism. (University of Illinois Press). Many have even pre-ordered it, and I fully intend to reimburse anyone who does that by buying them beer. But I must point out that the book is not actually out. When I try to click through and order a copy, it tells me that it won’t be available until the first week of December.

I don’t know how accurate that is (it’s the first time I’ve read an actual release date). I can say that the book is very close to being ready for the printer.

But now that it has been revealed, I want to take this opportunity to point out how amazing the cover is. I didn’t have any brilliant suggestions to make about cover art (I’m kind of a text guy), and so I just left it to the design department at Illinois. They hired a brilliant designer named Alex de Armond (http://www.alexdearmond.com/) who created the image by layering blank pages from Google Books, thus creating a texture somewhat like the layers of an onion skin. The thumb, of course, is one of the infamous artifacts from the Google Books scanning process. I am so very, very glad that I left this decision to others. I think it’s fantastic.

And really, why not judge a book by its cover?

Life on the Command Line

2011-04-09T00:00:00-05:00

A few weeks ago, I realized that I no longer use graphical applications.

That’s right. I don’t do anything with GUI apps anymore, except surf the Web. And what’s interesting about that, is that I rarely use cloudy, AJAXy replacements for desktop applications. Just about everything I do, I do exclusively on the command line. And I do what everyone else does: manage email, write things, listen to music, manage my todo list, keep track of my schedule, and chat with people. I also do a few things that most people don’t do: including write software, analyze data, and keep track of students and their grades. But whatever the case, I do all of it on the lowly command line. I literally go for months without opening a single graphical desktop application. In fact, I don’t – strictly speaking – have a desktop on my computer.

I think this is a wonderful way to work. I won’t say that everything can be done on the command line, but most things can, and in general, I find the CLI to be faster, easier to understand, easier to integrate, more scalable, more portable, more sustainable, more consistent, and many, many times more flexible than even the most well-thought-out graphical apps.

I realize that’s a bold series of claims. I also realize that such matters are always open to the charge that it’s “just me” and the way I work, think, and view the world. That might be true, but I’ve seldom heard a usability expert end a discourse on human factors by acknowledging that graphical systems are only really the “best” solution for a certain group of people or a particular set of tasks. Most take the graphical desktop as ground truth – it’s just the way we do things.

I also don’t do this out of some perverse hipster desire for retro-computing. I have work to do. If my system didn’t work, I’d abandon it tomorrow. In a way, the CLI reminds me of a bike courier’s bicycle. Some might think there’s something “hardcore” and cool about a bike that has one gear, no logos, and looks like it flew with the Luftwaffe, but the bike is not that way for style. It’s that way because the bells and whistles (i.e. “features”) that make a bike attractive in the store get in the way when you have to use it for work. I find it interesting that after bike couriers started paring down their rides years ago, we soon after witnessed a revival of the fixed-gear, fat-tire, coaster-break bike for adults. It’s tempting to say that that was a good thing because “people didn’t need” bikes inspired by lightweight racing bikes for what they wanted to do. But I think you could go further and say that lightweight racing bikes were getting in the way. Ironically, they were slowing people down.

I’ve spent plenty of time with graphical systems. I’m just barely old enough to remember computers without graphical desktops, and like most people, I spent years taking it for granted that for a computer to be usable, it had to have windows, and icons, and wallpapers, and toolbars, and dancing paper clips, and whatever else. Over the course of the last ten years, all of that has fallen away. Now, when I try to go back, I feel as if I’m swimming through a syrupy sea of eye candy in which all the fish speak in incommensurable metaphors.

I should say right away that I am talking about Linux/Unix. I don’t know that I could have made the change successfully on a different platform. It’s undoubtedly the case that what makes the CLI work is very much about the way Unix works. So perhaps this is a plea not for the CLI so much as for the CLI as it has been imagined by Unix and its descendants. So be it.

I’d like this to be the first of a series of short essays about my system. Essentially, I’d like to run through the things I (and most people) do, and show what it’s like to run your life on the command line.

First up …

Email

I think most email programs really suck. And that’s a problem, because most people spend insane amounts of time in their email programs. Why, for starters, do they:

Take so long to load

Unless you keep the app open all the time (I’m assuming you do that because you have the focus of a guided missile), this is a program that you open and close several times a day. So why, oh why, does it take so much time to load?

What? It’s only a few seconds? Brothers and sisters, this is a computer. It should open instantaneously. You should be able to flit in and out of it with no delay at all. Boom, it’s here. Boom, it’s gone. Not, “Switch to the workplace that has the Web browser running, open a new tab, go to gmail, and watch a company with more programming power than any other organization on planet earth give you a … progress bar.” And we won’t even discuss Apple Mail, Outlook, or (people …) Lotus Notes.

Integrate so poorly with the rest of the system?

We want to organize our email messages, and most apps do a passable job of that with folders and whatnot. But they suck when it comes to organizing the content of email messages within the larger organizational scheme of your system.

Some email messages contain things that other people want you to do. Some email messages have pictures that someone sent you from their vacation. Some email messages contain relevant information for performing some task. Some email messages have documents that need to be placed in particular project folders. Some messages are read-it-later.

Nearly every email app tries to help you with this, but they do so in an extremely inconsistent and inflexible manner. Gmail gives you “Tasks,” but it’s a threadbare parody of the kind of todo lists most people actually need. Apple mail tries to integrate things with their Calendar app, but now you’re tied to that calendar. So people sign up for Evernote, or Remember the Milk, or they buy OmniFocus (maybe all three). Or they go add a bump to the forum for company X in the hope that they’ll write whatever glue is necessary to connect x email program with y task list manager.

I think that you should be able to use any app with any other app in the context of any organizational system. Go to any LifeHacker-style board and you’ll see the same conversation over and over: “I tried OmniOrgMe, but it just seemed too complicated. I love EternalTask, but it isn’t integrated with FragMail …” The idea that the “cloud” solves this is probably one of the bigger cons in modern computing.

Problem 1 is immediately solved when you switch to a console-based email program. Pick any one of them. Type pine or mutt (for example), and your mail is before your eyes in the time it takes a graphical user to move their mouse to the envelope icon. Type q, and it’s gone.

Such programs tend to integrate well with the general command-line ecosystem, but I will admit that I didn’t have problem 2 completely cracked until I switched to an email program that is now over twenty years old: nmh.

I’ve written elsewhere about nmh, so allow me to excerpt (a slightly modified) version of that:

The “n” in nmh stands for “new,” but there’s really nothing new about the program at all. In fact, it was originally developed at the RAND Corporation decades ago.

We’re talking old school. Type “inc” and it sends a numbered list of email subject lines to the screen, and returns you to the prompt. Type “show” and it will display the first message (in any editor you like). You could then refile the message (with “refile”) to another mailbox, or archive it, or forward it, and so on. There are thirty-nine separate commands in the nmh toolset, with names like “scan,” “show,” “mark,” “sort,” and “repl.” On a day-to-day basis, you use maybe three or four.

I’ve been using it for over a year. It is – hands down – the best email program I have ever used.

Why? Because the dead simple things you need to do with mail are dead simple. Because there is no mail client in the world that is as fast. Because it never takes over your life (every time you do something, you’re immediately back at the command prompt ready to do something else). Because everything – from the mailboxes to the mail itself – is just an ordinary plain text file ready to be munged. But most of all, because you can combine the nmh commands with ordinary UNIX commands to create things that would be difficult if not impossible to do with the GUI clients.

I now have a dozen little scripts that do nifty things with mail. I have scripts that archive old mail based on highly idiosyncratic aspects of my email usage. I have scripts that perform dynamic search queries based on analysis of past subject lines. I have scripts that mail todo list items and logs based on cron strings. I have scripts that save attachments to various places based on what’s in my build files. None of these things are “features” of nmh. They’re just little scripts that I hacked together with grep, sed, awk, and the shell. And every time I write one, I feel like a genius. The whole system just delights me. I want everything in my life to work like this program.

Okay, I know what you’re thinking: “Scripting. Isn’t that, like, programming? I don’t want/know how to do that.” This objection is going to keep re-appearing, so let me say something about it right away.

The programming we’re talking about for this kind of thing is very simple – so simple, that the skills necessary to carry it off could easily be part of the ordinary skillset of anyone who uses a computer on a regular basis. An entire industry has risen up around the notion that no user should ever do anything that looks remotely like giving coded instructions to a machine. I think that’s another big con, and some day, I’ll prove it to you by writing a tutorial that will turn you into a fearsome shell hacker. You’ll be stunned at how easy it is.

For now, I just want to make the point that once you move to the command line, everything is trivially connected to everything else, and so you are mostly freed from being locked in to any particular type of tool. You can use a todo list program that makes Omnifocus look like Notepad. You can use one that makes Gmail Tasks look like the U.N. Charter. Once we’re in text land, the output of any program can in principle become the input to any other, and that changes everything.

In the next installment, I’ll demonstrate.

[Greetings ProfHacker fans. Yes, this post is a little rantish; the conversation continues in a more sober, expansive vein with The Mythical Man-Finger and The Man-Finger Aftermath. Thanks to one and all for the many comments, which have deepened my thinking on all of this considerably.]

Day of DH 2011

2011-03-18T00:00:00-05:00

Today, I’m blogging over here for this year’s Day of DH.

Oh, and so is everybody else.

On Building

2011-01-11T00:00:00-06:00

I’ve said a few controversial things over the course of my career, and it seems to me that if you are so honored as to have other people talking about what you said, you should probably sit back and let people respond without trying to defend yourself against every countercharge.

But I’m worried that my late remarks at MLA 11 are touching a nerve in a way that is not provocative (in the good sense), but blithely exclusionary. The particular remarks are as follows:

“Do you have to know how to code? I’m a tenured professor of Digital Humanities and I say ‘yes.’”

“Personally, I think Digital Humanities is about building things. […] If you are not making anything, you are not … a digital humanist.”

I suppose I could say that both of those quotes are taken out of context, but given that all quotes are by nature taken out of context, it doesn’t seem exactly fair to protest. But just stating things like this (as I soon discovered) really does touch upon a number of anxieties both in DH and among those who bid participation. I don’t know if I can alleviate that anxiety. I’m not even sure that I want to, insofar as some anxieties can be oddly productive. But there’s a lot more to be said here.

I’ve had the pleasure of talking with lots and lots of people in Digital Humanities from among a wide range of disciplines. And I’ve been having that conversation since the mid-nineties. I’ve discovered that there are lots of things that distinguish an historian from, say, a literary critic or a philosopher, and there are a lot of differences between 1995 and 2011. But to me, there’s always been a profound – and profoundly exciting and enabling – commonality to everyone who finds their way to DH. And that commonality, I think, involves moving from reading and critiquing to building and making.

As humanists, we are inclined to read maps (to pick one example) as texts, as instruments of cultural desire, as visualizations of imperial ideology, as records of the emergence of national identity, and so forth. This is all very good. In fact, I would say it’s at the root of what it means to engage in humanistic inquiry. Almost everyone in Digital Humanities was taught to do this and loves to do this. But making a map (with a GIS system, say) is an entirely different experience. DH-ers insist – again and again – that this process of creation yields insights that are difficult to acquire otherwise. It’s the thing I’ve been hearing for as I long as I’ve been in this. People who mark up texts say it, as do those who build software, hack social networks, create visualizations, and pursue the dozens of other forms of haptic engagement that bring DH-ers to the same table. Building is, for us, a new kind of hermeneutic – one that is quite a bit more radical than taking the traditional methods of humanistic inquiry and applying them to digital objects. Media studies, game studies, critical code studies, and various other disciplines have brought wonderful new things to humanistic study, but I will say (at my peril) that none of these represent as radical a shift as the move from reading to making.

This partially explains why we have so long been accused of being “undertheorized.” At its most sneering, this is a charge of willful exogamy: we’re not quoting the usual people when we speak. But there’s frankly some truth to it. As Geoffrey Rockwell wisely noted:

[DH] is undertheorized the way any craft field that developed to share knowledge that can’t be adequately captured in discourse is. It is undertheorized the way carpentry or computer science are. To new researchers who have struggled to master the baroque discourses associated with the postmodern theoretical turn there appears to be something naive and secretive about the digital humanities when it mindlessly ignores the rich emerging field of new media theory. It shouldn’t be so. We should be able to be clear about the importance of project management and thing knowledge – the tacit knowledge of fabrication and its cultures – even if the very nature of that poiesis (knowledge of making) itself cannot easily (and shouldn’t have to) be put into words. We should be able to welcome theoretical perspectives without fear of being swallowed in postmodernisms that are exclusive as our craft knowledge.

Now that this scrappy band of naive gear-heads are becoming the “cool kids,” an anxiety that has also been around for a long time re-emerges with new vigor: Do I have to know how to X?

Most readers of this blog know that I have devoted my life as a teacher to teaching other humanists how to code. I do that for the exact same reason that others devote their lives to the study of Shakespeare or the American Civil War: because it’s fascinating and soul charging. Like any passionate enthusiast – indeed, like any teacher worth their salt – I’m inclined to say that everyone should do as I do. But really, that’s as far is it goes. Learn to code because it’s fun and because it will change the way you look at the world. Then notice that we could substitute any other subject for “learn to code” in that sentence.

“Build,” though, casts a wider net (and is, I think, a more useful candidate for X above). All the technai of Digital Humanities – data mining, XML encoding, text analysis, GIS, Web design, visualization, programming, tool design, database design, etc – involve building; only a few of them require programming, per se. Only a radical subset of the DH community knows how to code; nearly all are engaged in building something. “Procedural literacy” has been suggested as a substitute, and I like that term. Still, I think some of the people who use it are trying to answer the question, “How much tech do I need to know to do cultural studies?” not “What is distinctive about DH?”

In the panel that set this off, Alan Liu tried to describe himself as not being a builder, but those of us with long memories know better. Because truly, we can date Alan’s entry into the field (literally, as well as spiritually) to a very precise moment; namely, the day he started building Voice of the Shuttle. Being a man of great range, he has gone on to do other very brilliant things (most significantly, in media studies), but I doubt very much if he’d be associated with DH at all had he not found his way to shop class with the rest of us bumbling hackers in the early nineties. He’s one of many crossover acts in DH, and those of us with less talent are surely more honored by the association. One of the reasons the DH community is so fond of Alan is because we feel like he gets it/us. He can talk all he wants about being a bricoleur, but we can see the grease under his fingernails. That is true of every “big name” I can think of in DH. Every single one.

Now, some of my closest friends in the community bailed about five paragraphs ago, because they’re sick to the teeth of this endless meta-discussion that another crossover DH-er once described as the “DH whine.” They’re especially tired of the “who’s in who’s out” discussion, and being generous folks, they’re much more inclined to say that anyone can join. I feel their pain. And anyone can join (the “cool kids” metaphor, honestly, makes me worry about my career). If I had been less prone to provocation, I might have found a way to put things more positively. But in the end, I feel obliged to say that there is something different about DH, and that it’s okay to say what that something is, even if to do so is indirectly to say that some are doing it and some are not.

[UPDATE: Irena Marinski of the Belrade Center for Digital Humanities has kindly translated this essay into Serbian.]

Who's In and Who's Out

2011-01-08T00:00:00-06:00

[I’m pleased to offer a transcript of my pithy, underdeveloped position paper at the “History and Future of Digital Humanities” panel at the 2011 MLA. The panel, which was organized and expertly chaired by Kathleen Fitzpatrick from Pomona, included Alan Liu from UC Santa Barbara, Tara McPherson from USC, Kathy Harris from San Jose State, Beth Nowviskie (in absentia) from the University of Virginia, and Brett Bobley from the NEH. Beth Nowviskie’s important (not to mention hilarious) intervention is online, as are Alan Liu’s remarks on the role of cultural criticism in DH and Kathy Harris’s on teaching (and learning) in DH.]

Kathleen has asked that we spend exactly three minutes giving our thoughts on this subject, and I like that a lot. With only three minutes, there’s no way you can get your point across while at the same time defining your terms, allowing for alternative viewpoints, or making obsequious noises about the prior work of your esteemed colleagues. Really, you can’t do much of anything except piss off half the people in the room. As I said, I like it a lot. Here goes:

“Digital Humanities” sounds for all the world like a revolutionary attitude – digital humanities, as opposed to old-school analogue humanities. As such, it has most recently tended to welcome anyone and anything exemplifying a certain wired fervor. Nowadays, the term can mean anything from media studies to electronic art, from data mining to edutech, from scholarly editing to anarchic blogging, while inviting code junkies, digital artists, standards wonks, transhumanists, game theorists, free culture advocates, archivists, librarians, and edupunks under its capacious canvas.

Over the last year or so, I’ve heard lots of discussions – both on and offline – about who’s in and who’s out. For the most part, people agree that having a blog does not make you a digital humanist. But beyond that, things are a bit fuzzy. Do you have to know how to code? Does it have to be about text? Can you be a digital humanist if you’ve never been to a THATCamp?

“No, no, no,” we all say. But we go further, and say that it doesn’t really matter. Everyone is included. It’s all about community and comity, collaboration and cooperation.

But this, of course, is complete nonsense. Community and collaboration are undoubtedly signs of the spirit, but to say that disciplinary definition doesn’t really matter is to eschew the hard reality of life in the modern academy. Digital Humanities is not some airy Lyceum. It is a series of concrete instantiations involving money, students, funding agencies, big schools, little schools, programs, curricula, old guards, new guards, gatekeepers, and prestige. It might be more than these things, but it cannot not be these things.

Do you have to know how to code? I’m a tenured professor of digital humanities and I say “yes.” So if you come to my program, you’re going to have to learn to do that eventually. Does it have to be about text? If you go to, say, the University of Alberta, I suspect the answer might be “no” – a reflection, again, of the faculty, many of whom have been in the field for a long time. But what if Duke or Yale were to offer a degree in Digital Humanities and they said “no” to code and “yes” to text? Or “no” to building and “yes” to theorizing? Or decided that Digital Humanities is what we used to call New Media Studies (which is the precise condition, as far as I can tell, at Dartmouth)? You might need to know how to code in order to be competitive for relevant grants with the ODH, NSF, or Mellon. Maybe that means Yale’s DH ambitions will never get off the ground. Or maybe Yale is powerful enough to redefine the mission of those institutions with respect to the Humanities. Most institutions, for the record, are not.

Now, I’ve been in this game long enough to understand a few things about how disciplines develop. First, they really can destroy themselves through overprecise definition. That has already happened in Classics, and Philosophy may be next. You can also successfully create a polyglot discipline without schism (the average psych department successfully incorporates the “Tell me about your childhood” psychologists and the “slicing-open-rat-brain” psychologists). You can also have a schism and have it not result in bloodshed (computational linguistics, a community now mostly separate from linguistics, comes to mind). But no discipline can survive without actively engaging with disciplinary questions. Not because there are definitive answers. Least of all because it’s important to alienate people. But simply because without those questions, we cede the answers to institutions eager to oblige people who are paying attention.

Personally, I think Digital Humanities is about building things. I’m willing to entertain highly expansive definitions of what it means to build something. I also think the discipline includes and should include people who theorize about building, people who design so that others might build, and those who supervise building (the coding question is, for me, a canard, insofar as many people build without knowing how to program). I’d even include people who are working to rebuild systems like our present, irretrievably broken system of scholarly publishing. But if you are not making anything, you are not – in my less-than-three-minute opinion – a digital humanist. You might be something else that is good and worthy – maybe you’re a scholar of new media, or maybe a game theorist, or maybe a classicist with a blog (the latter being very good thing indeed) – but if you aren’t building, you are not engaged in the “methodologization” of the humanities, which, to me, is the hallmark of the discipline that was already decades old when I came to it.

Am I right about this? With less that three minutes, of course not. But ask yourself this: Does having an opinion like this move us forward or backward? Is this a good fight or a bad one? Or is it better to let the whole thing emerge as it will? I say that the institutional structures in which we work have already decided in favor of having this discussion, and that we can have it while still retaining our well-earned reputation for collaboration, cooperation, and good will.

[Boy, did this get me in trouble. But I made it all better (well, sort of) with “On Building”.]

The Meandering through Textuality Challenge

2011-01-06T00:00:00-06:00

[This is a talk I gave as part of panel entitled “Digging into Data” at the 2011 MLA. I was joined by Glenn Roe (of ARTFL) and Ray Siemens of the University of Victoria. My talk was called, “The Meandering through Textuality Challenge: Reflections on the Humane Archive.”]

Digging into literature? Really? The word evokes images of pickaxes and front-end loaders, or else rakish Indiana-Jones types gamely hefting golden treasures from the otherwise unremarkable sands. The literary equivalent, one presumes, involves making similar excavations into the undifferentiated fields of textuality – the “words, words, words” of the burdened and overwhelmed reader – in the hope of finding …

Well, what exactly? I have many times suggested “pattern” as the treasure sought by humanistic inquiry: which is to say, an order, a regularity, a connection, a resonance. I continue to insist that this is, in the end, what humanists in general, and literary critics in particular, are always looking for, whether they’re new critics, new historicists, new atheists, new faculty, or New Englanders. Pattern is the linchpin of all humanistic argumentation from the Platonic dialogues to the Dialogic Imagination. Whether conceived as metaphysical reality or as desiring machine, pattern is the raw material of the hermeneutics of our discipline.

This would be a banal observation – as unenlightening and philosophically indefensible as saying “Everything is interpretation” or “Everything is text” – were it not for the fact that (like these worn phrases, once upon a time) it encourages us see a connection that might otherwise be obscured. For if humanistic inquiry is about pattern, then it isn’t completely crazy to suggest that computers might be useful tools for humanistic inquiry. Because long before computation is about YouTube or Twitter or Google, it is about pattern transduction.

The words we use to describe what we’re doing reinforce this connection. Woolf reconceives gender identity; Hurston reimagines the interplay of race and place; Moretti usefully reconfigures the English novel. We likewise ask our students to notice, to see, to find, and ultimately (we hope) to “re-” as we do.

But not to dig, precisely. We dig Hamlet, naturally, and we’d of course like them to dig it as well, but we do not present the task of literary criticism or historiography as the process of finding some intact, but buried object beneath the surface. That’s because we have for a very long time now conceived of the patterns we’re looking for not as “out there,” but as “in here” – not as preexisting ontological formations, but as emergent textual epiphenomena. Someone might discover a new planet, but anyone who says they have “discovered” the origins of the Atlantic slave trade is (we hope) speaking metaphorically.

My purpose in saying all of this is not to criticize the eponymous title of our panel and the grant program that threatens to make it the natural term. As one of the people called in by the NEH as an adviser during the creation of that program, I have less right than most to lodge a complaint. But I would like to suggest that the terminology we are increasingly adopting to describe text analysis in literary study – or, for that matter, any “big data” project in the humanities – is threatened with metaphor shear.

“Metaphor shear,” you’ll recall, is that incomparable term coined by Neal Stephenson to describe the experience of using Microsoft Word:

Anyone who uses a word processor for very long inevitably has the experience of putting hours of work into a long document and then losing it because the computer crashes or the power goes out. Until the moment that it disappears from the screen, the document seems every bit as solid and real as if it had been typed out in ink on paper. But in the next moment, without warning, it is completely and irretrievably gone, as if it had never existed. The user is left with a feeling of disorientation (to say nothing of annoyance) stemming from a kind of metaphor shear – you realize that you’ve been living and thinking inside of a metaphor that is essentially bogus. (Stephenson 63-64)

Metaphor shear, we should notice, is not the dispiriting revelation of the man behind the curtain. Neither is it that sudden release from a trance one experiences when the fire alarm goes off in a theater or we miss our stop because of a novel. Metaphor shear is a moment of exasperated surprise borne of an entirely incorrect notion about what is actually happening. Not “It’s only a movie?” but rather, “Wait. This isn’t a movie?”

And so it is with the idea of digging. When I started in text analysis – and in Internet time, we’re talking eons ago – being a text analysis practitioner was something like being a devoted student of Coptic paleography or of the Monophysite heresy. No one really cared (or, for that matter, understood what we were doing) but we loved what we were doing, and the small, but solidly international group of practitioners was enthusiastic and supportive. None of us could have imagined jobs in the area, articles in The New York Times about what we were doing, buzz at the MLA about data mining, or “n-gram” as a trending topic on Twitter. None of us would have dared to dream of an Office of Digital Humanities at the NEH giving actual money to people like us.

But now we’ve sort of arrived. That came about in part because of the general rise of the Internet, the creation of large-scale text archives like Google Books, and the rebranding of artificial intelligence as the provably useful and occasionally astonishing task of “data mining and machine learning.” Could the marvels of the latter have implications for humanistic study? People began reading our articles, inviting us to give talks, asking us to write books. Really, life could not be better for someone like me who would rather write software and stare at columns of words and numbers all day than do just about anything else. But people are asking us a question that we never really thought to ask ourselves: Where are the results?

It’s not that we haven’t ever used that term; we use it all the time. We also use terms like “hypothesis” and “control group” and “data point” and “method” and “success” and “fail.” Many of us are even guilty of describing ourselves as “digging.” But as with Microsoft Word, the metaphor is essentially bogus. It’s bogus even when we say it’s not. And that’s because we’re still are engaged in humanistic inquiry.

To work with text is not automatically to be so engaged. Scientists studying the human genome are working with lots of text, as are marketers looking for ways to sell motor oil. We might even say that they are looking for pattern, but, to radically abuse Bateson’s phrase, therein lies the difference that makes a difference. To search the human genome for a pattern that might indicate a genetic component to type 2 diabetes is to search for a specific thing that we would very much like to find. The marketers are looking for something that correlates with purchases of motor oil. When they find it (it being anything from potato chips to bath towels), they’ll tell us.

What are the humanistic diggers looking for?

One project is called, “Digging into Image Data to Answer Authorship-Related Questions.” What do “authorship-related questions” involve? You know: “finding salient characteristics of artists” (ibid.). Another, called “Digging into the Enlightenment,” proposes to discover “how the spread of ideas at the global scale relates to the dynamical processes that operate at the local scale.” Yet another, the laconically entitled, “Harvesting Speech Datasets for Linguistic Research on the Web” proposes to “evaluate theories about the form and meaning of prosody.” No one working on the human genome – or, for that matter, the motor oil-ome – would tolerate the vague and imprecise language here employed. How will they know that the characteristic is “salient?” And where is the null hypothesis in their search for the interactions between the global and the local? How many “theories about the meaning of prosody” do you suppose they’ll discover to be irrefutably false?

Perhaps I seem to ridicule these projects. I don’t mean to. If anything, I mean to suggest their clear alliance with the grandest traditions of humanistic inquiry. Every project gleefully proclaims itself to be “digging into data,” but on closer inspection, it becomes clear that they aren’t digging even in the metaphorical sense. They are, instead, doing something more akin to the meandering parole of the English or history classroom: asking questions, suggesting answers, reading, pondering. The astonishing thing isn’t, in the end, the ways in which high-performance computing and mega-scale datasets transforms the humanities; rather, it’s how much of the hermeneutical basis of humanistic inquiry – the character of its discourse and the eternal tentativeness of its “results” – remains invariant. The revolution is not hermeneutical so much as methodological.

Which is not to say that it is any less of a revolution. In fact, it might be more revolutionary than anything that has happened in literary study in fifty years, precisely because the traditional humanities disciplines are so radically (if you’ll pardon me) undermethodologized. And that’s precisely why we need to get our metaphors right.

This is made harder than it should be by the fact that disciplines (and, just as often, companies) unconcerned and in some cases unfamiliar with the terms of humanistic discourse had the privilege of naming the animals. It’s hard to imagine even the most positivistic of the old nineteenth-century philologists referring to what they did as “mining,” and yet what could be more natural to an engineer? But even if we are unable to change the language of what we do, we can remind ourselves that just because the language is borrowed from another discourse does not mean that it now has the same meaning it once did. Indeed, the still-nascent discourse we call “Digital Humanities” might be most precisely defined as the attempt to figure out what that new meaning is.

For the Record

2010-10-29T00:00:00-05:00

There’s an xtranormal video making the rounds in which an English professor has a rather brutal conversation with an undergraduate student. In it, the student requests a letter of recommendation from the professor with the kind of wide-eyed naivete usually reserved for characters in musical comedies, while the battle-weary prof tells her, in so many words, that she’s an idiot.

At one point, the professor wearily forecasts an academic future in “Nowhere, Nebraska.” And that seems to have gotten a few of my friends thinking: “Hmm. An English professor with a fondness for xtranormal, short expository films, digital things, and snark creates a video highly critical of the current system that mentions Nebraska. This is totally Steve.”

For the record, no. It isn’t. And I don’t know who did it.

I’ll admit it’s the kind of thing I might do (though I draw the line at making students–even fictional ones–look ridiculous), but it wasn’t me. And there are two ways you can tell:

Nebraska is hardly “nowhere.” And any professor who thinks an appointment at a major midwestern research university is some kind failure, probably needs their head examined.
I do not ever release work without my name on it. Ever. If a professor did create that video, I would encourage them to consider whether it’s appropriate for someone who is paid to be a teacher and an intellectual to behave like an Anonymous Coward on Slashdot, and to ask themselves what kind of precedent that sets for students. If these are ideas that need to be a part of our public discourse, then we need to know to whom we can direct our disagreements. And no, you are not a political dissident fearing reprisals from a hostile government.

I rather like the video, as I like most things that try to make us examine our practices in the academy. But this one isn’t mine.

The Beautiful Thing

2010-10-28T00:00:00-05:00

I’ve been teaching English and History majors how to program for several years now. During that time, I think I’ve figured out how to present this material in a way that countenances its complexity and power while still being accessible to people without technical backgrounds. The result is a course that I’m really very proud of, and that I expect to teach, in some form, for the rest of my career.

Every time I start the process of teaching people how to write software, there’s always something on the tip of my tongue. Programming has its elementary katas – “Hello, world!”, this is a variable – and it’s fun to gradually build up complicated programs from these first steps over the course of a semester. But I’m always seized with the desire to start teaching programming at a far more fundamental level. The thing I want to say to my students, right at the start, is something like this:

“Down at the very bottom of a computer is something so simple, so elemental, so primitive, that it almost makes you want to laugh. The most complicated software systems ever written are built upon a chain of abstractions that starts with this very simple mechanism. Computation is one of the most elegant ideas in the history of the world, because a child can grok a NAND-gate. Everyone should see this for the same reason that everyone should see the moon through a telescope. It’s just a beautiful thing.”

Of course, we just can’t go there. The “beautiful thing” would get us into circuit logic. And once that was explained, the students would naturally want to know how this somehow gets us all the way to Facebook and Tetris. And that would require explanation of sequential logic, the design of an ALU, the fundamentals of computer architecture, machine language, assemblers, VMs, compilers … The beautiful thing ends up being the entire curriculum of computer science.

Except that even people who have been through that curriculum can fail to see the beautiful thing, even after taking courses in most of those areas. I was programming for years before I saw the beautiful thing.

The Elements of Computing Systems: Building a Modern Computer from First Principles by Noam Nisan and Shimon Schocken is the only book I’ve ever read that explains the beautiful thing all the way from top to bottom. And it does it in about 350 pages.

Nisan and Schocken aren’t content to give you a rolling narrative about the chain of abstractions upon which modern computing rests. They want you to build a computer yourself, starting with primitive gates and going all the way up to application programming. On the book’s website, there are a series of simulators (strongly reminiscent of the simulators used by actual engineers) that you can download and use to create the entire platform. The first exercise for the reader asks you to use the hardware simulator and its own Hardware Description Language (HDL) to create the logic gates for NOT, OR, AND, NAND, XOR, the multiplexor … There’s very little hand waving going on here. The HDL is not Verilog, but it’s not a toy language either. You’re building a real computer. In later chapters, you implement an assembler, write an OS, create a programming language, and build applications. Really.

My list of the greatest books ever written on programming – the enduring classics of computer science – is just like everyone else’s, and it’s a short list. Structure and Interpretation of Computer Programs by Abelson and Sussman. The Art of Computer Programming by Knuth. Friedman’s The Little Lisper (and subsequent volumes). The C Programming Language by Kernighan and Ritchie. This book is on that list. It’s a genuine modern masterpiece.

Every year, I have students who, at the end of the semester, say something like, “I had no idea how fascinating computers are.” I now plan to hand them this book and say, “It gets even better.”

UPDATE: I should mention that the book does assume you know how to program, though literally any language will do. The book would be fully accessible to anyone who has taken a programming course of any kind, or managed to learn any of the major languages on their own. I don’t think beginners would find it an easy read, but it’s not a unduly hard one either. It’s on my short list in part because of its lucid, graceful explanations of difficult matters.

Care of the Soul

2010-10-08T00:00:00-05:00

[Here’s the talk I gave at Emory University this morning. This is all in reference to DiSC (Digital Scholarly Commons) – a really exciting initiative being undertaken by the Emory University libraries. I’ve been serving on the DiSC Advisory Board for a year or so, and I gave this talk as part of a panel that included Laurie Patton from the Department of Religion at Emory, Richard Faruta from Texas A&M, and Geneva Henry from Rice University.]

[UPDATE: Stewart Varner (of DiSC) kindly sent me an mp3 of the talk.]

How do you tell when the person addressing a group of librarians is not a librarian? Easy. He or she will, as surely as day follows night, make a reference to the Library of Alexandria.

It’s easy to understand why that might be a good move. Alexandria, after all, is part of the genesis narrative of Western culture. In the beginning, there was a library. Not only that, but it apparently had all the features of a modern library (including, as far as we can tell, cataloguing and acquisitions departments, thus indicating the eternal nature of these units). It was, from all accounts, extremely well funded. An ancient rumor claims that the library bore a Greek inscription – psycheis therapeia, which translates to something like “place for the care of the soul” or even “soul hospital.” (It’s possible that the inscription belongs to the library at Memphis built by my ancestor Ramses II, but that’s another subject).

It’s also a cautionary tale. We actually aren’t at all sure when or how it was destroyed; ancient sources place that event somewhere within a nearly six-hundred-year period. It’s possible that Julius Caesar accidently set fire to the library during a visit. It’s also possible that a Muslim caliph ordered its destruction. No matter. Fire and religious fanaticism, being both bad for libraries, serve to remind us all how fragile the whole thing is.

There is one thing, though, that is lost in all of this. And that is that the library at Alexandria, as far as we can tell, did not have any actual librarians. Not, at least, in the modern sense. It’s not that the people there weren’t concerned with the organization of information – access and preservation, as we would say today. They surely were. It’s that every single person we’ve ever been able to tie to the library was either a poet, a literary critic, an historian, an editor, an astronomer, a grammarian, a mathematician, a translator, or some other kind of scholar – including the people who are known to have held the title of head librarian. Being a “librarian” meant studying and interpreting the contents of the library.

They did, of course, have people there to help librarians do that – people who looked after the scrolls, kept the lamps burning, fetched things, pointed out the bathrooms, and so on. They were called slaves.

Nowadays, it is taken quite for granted that librarians and scholars occupy completely separate spheres in a modern university. It’s not that librarianship has no element of scholarship to it, or that scholarly research can proceed without a close dependency on librarianship. The deep interdependence of the two roles is another thing that outsiders are obliged to mention. Still, at some level, they remain sharply separate. And no matter what sort of pious noises the outsider might make, the idea persists. Scholars create scholarship. Librarians assist them.

What is most remarkable about this, though, is how recent a development it really is. You have to go forward many centuries – really, to the nineteenth century – before you find the kind of strict compartmentalization we see today. We can go on and on about the importance of libraries to the contemporary university, but in the end, the library is considered a “service unit.”

And that’s a problem.

I was invited to come to Emory a year or so ago to serve as a consultant for the creation of a Center. It’s not the first time I’ve done this. In fact, I’ve probably done it half-a-dozen times or more in the last fifteen years. Not once have I have ever been asked where this center-initiative-thingy we’re sort of imagining should be. It is always, always in the library.

How fitting! Because of all scholarly pursuits, Digital Humanties most clearly represents the spirit that animated the ancient foundations at Alexandria, Pergamum, and Memphis, the great monastic libraries of the Middle Ages, and even the first research libraries of the German Enlightenment. It is obsessed with varieties of representation, the organization of knowledge, the technology of communication and dissemination, and the production of useful tools for scholarly inquiry. But DH is also, itself, a scholarly activity – concerned not just with presenting knowledge or helping to locate it, but with creating it. And it is here that the conventional, if relatively recent configuraton of the library as an assistive technology becomes a serious liability. Allow me to put it boldly: Emory will become a great center for Digital Humanities to the degree that it allows its scholars to act more like librarians, and allows its librarians to act more like scholars.

The alternative – a “center” that is really nothing more than another service point in the library for scholars interested in setting up blogs or creating web sites – might curry some local favor. The President of the University Libraries can present that to the powers above as another way that the library serves the Emory community. And it’s not a bad thing, certainly, to engage in such service. But Emory will never do serious cutting-edge research in Digital Humanities with this model. It will, at best, become a place that is not falling too far behind.

During the year or so I’ve been involved with this project, I’ve tried to offer the best advice I can. But in the end, I’ve just repeated the secret formula for becoming a place for the care of the soul: create a space in which the conventional separations among faculty, librarians, students, and staff become malleable – even, to use a term popular among hackers, fungible. The good news is that computers – those wicked instruments that so deftly serve to make us all feel slightly stupid – can help with this simply by making us all a bit more humble in the face of the unknown. But in the end, it requires nothing more or less than imagination and leadership from academic department chairs and senior library administrators.

So here’s some advice for the four stake holders I just mentioned:

Library Administrators Let anyone among your staff who is remotely interested in this Center be part of it in some way. If someone knows how to program, or how to build Web pages, or how create databases, or how to make smartphones do miraculous things with GPS; if one of these people is way into some particular collection or some subject (and it can be anything from railroads to race relations); if any of these people have a crazy idea for something digital: make some space for them to pursue that as part of the Center’s activity. Think of it as your skunk works. Think of it also as a way to let the extremely creative people who work for you be extremely creative.
Library Staff Be persistent with your crazy ideas. Given the million things that have to happen in order to keep a library running, it’s at least sensible that an administrator would not want to let you get involved with something “extra.” Of course, it’s only “extra” until people realize just how brilliant it is. Then it becomes Proudly Sponsored by the Emory University Libraries. Be patient. Alexandria wasn’t built in a day.
Students Digital Humanities centers afford students – and especially graduate students – one of the few genuine apprenticeships in humanities education. They’re a place to learn skills and methodologies, but perhaps more importantly, a place to learn how to become a professional scholar and researcher. If you’re interested in this stuff, you should plan to do just about anything to be involved with one.
Faculty Be prepared to be the dumbest person in the room. Know, also, that being the dumbest person in the room might be the best experience of your professional life. The greatest scholarly practitioners I have known in Digital Humanities were the ones who came prepared to learn, were willing to roll up their sleeves, who respected the people around them, and who were committed to genuine collaboration. You can pull together a digital project by thinking great thoughts and then ordering people to “implement” them, but you’ll never get a serious work of scholarship that way. Be part of it, and everyone around you will make you look good.

There’s another way you can tell when an outsider is addressing librarians. They say some inspirational things, they say things that are hard to hear, and then they go home. Thank you for having me!

Anthologize It

2010-08-12T00:00:00-05:00

As most readers of this blog know, I was one of the people involved with One Week | One Tool and (therefore) one of the people responsible for Anthologize.

There’s a lot to say about this. Even if the team hadn’t produced anything worthy, I would still consider my experience at OneWeek to be among the most exciting of my career. I have no doubt that software development under these extraordinary conditions provides some useful information about how to do it under normal conditions. But the truth is, the people I worked with were in every sense extraordinary. I’ve been writing software for a long time. I seldom encounter people who so perfectly combine ferocious talent with bonhomie. It was a total blast from beginning to end.

But I do want to say a few things about what we built.

Anthologize was designed by committee, so my sense of what it’s about doesn’t necessarily reflect that of the wider group. To be honest, I spent most of OneWeek thinking about code, since I was (and continue to be) one of the developers for the project. But since we just had a point release, I’ve found myself thinking about the bigger picture.

The reaction to Anthologize has been overwhelming – really beyond what I could have imagined. This tool clearly fulfills a need that people have, but I honestly don’t think I was fully in touch with the depth of that need even as I enthusiastically voted to go forward with the project. In the midst of all the enthusiasm and well-wishing that followed the official launch, though, I noticed a couple of detractions. To me, these were some of the most thought-provoking comments. Two struck me in particular:

What’s with the book fetish?

Bloggers have had to contend with a lot of sneering opposition from other parties (publishers, professional journalists, academics), who consider the “blogosphere” a faddish, pseudo-populist version of what they do both professionally and very well, thank you. By creating and promoting a “blog-to-book” framework, aren’t we just bolstering the dubious idea that “books” – even digital ones – are more legitimate than things like blogs, YouTube videos, and podcasts? What’s wrong with blogs? Why do blogs need to be something else? Especially something that looks for all the world like a non-digital, old school codex?

Why would anyone want to use a blog to write books?

The WordPress editor is great for typing up blog posts. But do we really want to use it as the basis for a publishing platform? Do we seriously imagine that any serious writer will want to move from Word to WordPress for the creation of books?

I’m glomming together a number of different voices here for the sake of argument. But these two struck me as the most significant threads.

It’s striking that neither of these critiques is in any way hostile toward technology in general or eBooks in particular. The first wonders whether there’s a secret conservatism to what we’re doing; the second poses a mostly utilitarian question about which tool is best for the job. So the usual screed we hear (the one I, at any rate, hear all the time from people I assume should know better) won’t work:

People who move in tech circles – particularly in “edutech” – will recognize how little exaggeration there is in the above paragraph. I’ve sat through entire talks where the basic rhetorical posture amounted to “kids these days” and the way they’re lapping us with their canny, transhuman tastes. But in the end, there’s never any explanation as to why such a change might be good or bad – why we might, as a culture, want to intervene or not. Generally, such pronouncements come with all the portentous inevitability of prophecy. You can get with the program or go off the grid, but the program is running and the grid is permanently woven into the fabric of contemporary reality.

Yet it’s tempting to say something like this with respect to Anthologize. Many segments of conventional book publishing are, for a variety of reasons both practical and philosophical, in serious trouble. It is the case that more and more writing is moving online, and that the line between draft and finished, “published” product is becoming less and less clear. It is also the case that a world in which written words are conveyed in a sharply limited number of hard-to-produce formats (hardback/paperback, newspaper/magazine) is giving way to one in which “format” indicates literally dozens of devices, layouts, and contexts.

I think Anthologize is a tool that not only countenances this new way of doing things, but declares that it is a good way of doing things.

It’s a rare writer that doesn’t dream of being published, because publishing means legitimacy. You might be planning a novel, or writing a novel, or even printing out your finished novel, but we reserve the title “novelist” for those who have published. In academia, publishing stands as the final warrant of your expertise – a certification that is even more powerful than holding an advanced degree in the subject. In fact, any expert on any subject appearing on any television program you might see “is the author of” something. That’s why they’re experts. They’re published.

Many people involved in the business of publishing – including authors – like to defend publishing-as-legitimacy on philosophical grounds. At times, the contours of that defense are indistinguishable from those used to defend Petrine succession or the establishment of coequal branches of government – either as a sacred trust that is self-evidently good, or as a rational principle that is now part of the stewardship necessary for a well-ordered society.

The reality is that much of what legitimizes publishing arises from the fact that only a few people get to do it. Resource constraints prohibit just anyone from publishing, and so we have to choose a subset of the people who are interested in and capable of doing so. If you’re published, you automatically belong to a pretty exclusive club. You can view that cynically (as I am wont to do with segments like university press publishing) or as a mostly neutral, if hard-edged reality. But the idea that resource constraints somehow ensure or logically entail the validity of systems designed to limit the number of people who can publish seems to me pretty ridiculous.

And that is, more or less, the argument that is made. In most sectors – and especially in academia – online publishing removes most of the resource constraints that limit the dissemination of information. Leaving aside the (very real) problems of the digital divide, we now live in a world in which pretty much anyone can put pretty much anything online. Yet even in the absence of the old constraints, the communities with a stake in publishing rush in to try to re-establish the old methods of selection.

I am not so naive as to think that everything that appears on a blog is of world-historical moment, or that every site devoted to the advancement of knowledge meets the standards of scholarly excellence. But it strikes me as obtuse and mildly elitist to think that our present system successfully separates the sheep from the goats even most of the time. The question is not “How do we ensure that only good stuff appears?” The question is, “How do we know what’s good in a world where everything appears?”

Except that that’s not the question either. The real question is whether we think that the traditional systems – which were designed for scarcity – represent the best way of figuring that out. Is it really the case that acquisitions editors, editorial boards, and “outside” reviewers remain the best way to manage what some have called the “Age of Abundance?” Is it really better to have a restricted set of “journals” that present carefully chosen subsets of ideas, when all the rest of the ideas are a click away? Do our choices really lie between the sage judgments of experts and the fickle whims of the unwashed masses?

Anthologize is a piece of software designed to manage some very practical matters related to the way we move text around on the Web. But I also think it’s an intervention in this debate. I think it says the following:

The Age of Abundance is good. It is good to have lots and lots of flowers blooming. It is also good to have crabgrass and weeds. The emergent processes that guide us toward some ideas and not others are not inherently inferior to the traditional, highly intentional processes that try to contend with scarcity. Blogs exemplify these values. Anthologize is one of the tools you can use to decide which (of your own or others’) ideas are good and which aren’t, but it imagines that judgment as inherently non-exclusive.
Formats are good. It is good to present your ideas in as many functional contexts as possible. You should therefore be able to recast your work in other formats effortlessly – including printing your work in a bound codex. Anthologize has a few export formats in place. We intend for there to be lots and lots of them.
Drafts are good. It is good to imagine writing as occurring on a broad continuum in which the distinctions between drafts and finished products are obscured. Blogs can be staging grounds for other formations, without the staging ground itself disappearing from the process. Anthologize can be a way of declaring something “final.” It can also be a way of organizing drafts. And blogs, too, can be “final.”
Simple editing frameworks are good for writers. People work the way they like to work, but WordPress at least tries to imagine a world in which the mammoth, lumbering word processor – which repeatedly confuses the creation of prose with the process of generating formats – is not obligatory for anyone who wants to get their ideas out there. Anthologize rigorously separates the act of writing, which usually requires only simple tools, from the act of making it “presentable” (which often requires a lot of code and carefully designed UIs)
Mashups are good. It is good to have as many new arrangements (“anthologies,” one might say) as possible. Just as there are few practical restrictions on how many ideas we can have out there, there are now few practical restrictions on how many arrangements of those ideas are possible. Anthologize not only lets you arrange your own work, but allows you to arrange other people’s work into new collections.

Anthologize isn’t the last word on all of this. Given the “this,” I’m not sure that we would want it to be. But I think if there’s one lesson to be gleaned from One Week | One Tool, it’s that tools can embody arguments and viewpoints – that building is itself a rhetorical act. To me, Anthologize embodies a lot of my beliefs about the past and future of publishing.

Others may differ, of course. Fortunately for you, they also have blogs.

Open Access Publishing and Scholarly Values (part two)

2010-05-28T00:00:00-05:00

[The following is a response to Dan Cohen’s post entitled, ”Open Access Publishing and Scholarly Values.” I originally submitted it as a comment, but it’s almost as long as the original article itself. I’m posting it over here so I can edit it more easily, but it’s meant to follow on the earlier piece. You should certainly go read Dan’s piece first.]

“Writing is writing and good is good, no matter the venue of publication or what the crowd thinks. Scholars surely understand that on a deep level, yet many persist in the valuing venue and medium over the content itself.”

Dan, I agree with everything you’re saying here. But I do think you might be missing the underlying reality of this apparently elitist disposition, which I think is this:

Few of the people who are actually responsible for evaluating your work actually read your books and articles.

That’s probably an astounding revelation for many people who are coming up for tenure or who otherwise haven’t had the opportunity to sit on a merit review panel, but it’s absolutely true. Your colleagues are not reading your work. Period.

There’s no time! “Steve, why don’t you look at Dan’s file for Wednesday. Oh, and why don’t you take Sheila, Tom, and Sue’s as well.” Great! That’s three monographs, a prospectus, eight articles, plus a couple hundred student evals … No problem! I’ll get right on it.

Like most junior academics, I spent years agonizing over what my colleagues might think of my work. Imagine the mixture of shock and awe that overtook me when I realized that I had nothing to worry about. No one was going to read it.

How can this be? How can we make momentous decisions about promotion and tenure and conduct performance reviews that affect peoples’ actual salaries without a comprehensive and thorough review of their work?

The answer is simple: publishers do it for us.

I am convinced that that’s really what this is all about. I don’t have time to read everything. But more importantly, I don’t really want to evaluate your work on its “intellectual merits,” because, well, you might do that to me. And really, this could get very emotional very quickly. And anyway, what qualifies you to judge me (or me to judge you)? We’re colleagues, after all.

The solution to everyone’s problem has been to outsource this decision to a third party that gives it a seal of approval while at the same time anonymizing the people who actually did read the book or the article. That allows us to move the whole problem somewhere else. What’s more, it allows us to make fine distinctions between people that we otherwise wouldn’t want to make ourselves. Chicago is better than Ashgate. Oxford is better than Michigan. Critical Inquiry is better than Modern Drama. Monographs are better than edited collections. It’s just so easy this way.

You ask how a profession that swings so solidly left can hold such absurdly elitist attitudes. I would submit that this apparent bit of cognitive dissonance is rooted in our mostly postmodern attitudes about value. “Who’s to say what good?” Humanities professors are mostly uncomfortable making judgments about what’s good; publishers don’t appear to have these deep philosophical problems (or rather, these philosophical issues are overridden by market concerns). There’s also our desire to avoid confrontation (“Dude, that’s so harsh”). Narcissism, sure. It’s also full of contradictions (Why does Oxford get to make truth claims about worth but we don’t?) You could say that it’s not actually the publishers; it’s our “peers” on the anonymous review panels that the publishers hire. But we pay a devastating price for that bit of bait and switch. First, it means that we have to sell our copyrights to compensate the publishers for their role as coordinators of all of this. Since they’re trying to stay afloat financially, they have to sell that content back to us – which usually results in highly restrictive forms of dissemination. Open access – which is an ethically superior form of dissemination on its face, and (I think) a moral obligation for public institutions – is effectively shut down by our own behavior. Second, it means that any form of scholarship not immediately susceptible to this treatment (e.g. the majority of digital work) can’t participate equally in this system. Truth is, no one really has a problem any more with digital work. It just has to be, you know, about article length. And single authored. And peer reviewed. And disseminated under the banner of a third party. And that’s because this isn’t about the medium at all. This is about the structures that allow us to make difficult decisions as painlessly as possible. I think most academics regard this as the best we can do.

I think it’s not the best we can do. The idea of recording “impact” (page hits, links, etc.) is often ridiculed as a “popularity contest,” but it’s not at all clear to me how such a system would be inferior to the one we have. In fact, it would almost certainly be a more honest system (you’ll notice that “good publisher” is very often tied to the social class represented by the sponsoring institution). But in the end, the clear moral good of having open access (and the probable dissolution of the UP system) may mean that we have to read and evaluate each other’s stuff. And that may mean that the mechanics of our entire review system has to change. It may actually mean that “peer review,” as such, disappears in its present form.

For years, I wondered why people are so resistant to electronic publication and digital projects generally. The answer just didn’t make sense: “We don’t know how to evaluate that kind of work?” “Really?” I thought. “Here’s an idea: How about you look at it and decide whether it’s good or not.” But that’s precisely the responsibility that no wants to have (without cover of darkness). This is the root of every bit of sanctimonious nonsense you’ve ever heard about “peer review.” Translation: We don’t have a certifying authority to whom we can offload this. That’s why I believe that creating these certifying authorities for digital work may end up capitulating to an already broken system.

Honestly, I think our goal as a community should be to present our colleagues with as many inscrutable objects as possible. We should be making lots of videos, podcasts, maps, “books” with a hundred authors, blog posts, software, and web sites without any clear authorial control. And yes, we should put open content licenses on all of it and give it away to everyone we meet. And then we should dare our colleagues to tell us that our work isn’t of sufficient intellectual quality.

Don’t worry. They won’t say that to your face. They didn’t read it in the first place.

[Update: Kathleen Fitzpatrick of Planned Obsolescence is next in line with Part 3 of this Hacking the Academy blogfest.]

Centers of Attention

2010-04-27T00:00:00-05:00

[This is a talk I gave in April, 2010 at the Knowledge Futures Spring Forum at Emory University.]

I’ve been around digital humanities centers for a long time – fifteen years at least. I’ve worked at them (in positions ranging from part-time staff member to Fellow), consulted for them, given speeches at various openings and anniversaries, and been present at a few center funerals (these happen at bars, usually). And so I’m always interested in how these things get started and how they end.

One of my favorite founding stories involves the Institute for Advanced Technology in the Humanities at the University of Virginia, where a lot of my ideas about centers were formed. According to the story, IBM offered to donate a server to the University of Virginia (this was back when such things were a lot rarer, and a lot more expensive). The University naturally approached the Computer Science Department asking if they’d like the equipment. The CS department, amazingly, said “No.” They had heard, however, that there were some people over in English and History who were doing things with computers. Maybe ask them.

I’ve always imagined the server washing up on the shores of the College of Arts and Sciences and starting a strange cargo cult among a group of people who normally didn’t talk to each other much. There’s a guy in history who’s into computers, and there’s someone in English. Neither of them really know what they’re doing, and the CS people are too busy with serious computational matters to help out the poets. The librarians, fortunately, know more than the computer scientists about how to actually run a rack server, and so they get involved. Questions arise: Where do we put this thing? Who pays for its upkeep? Doesn’t it need, like, maintenance or witchcraft or something? And are we really qualified to design Web sites, given that none of us have the faintest idea how to draw?

That this turned into one of the most vibrant centers of intellectual activity in North America – a hugely influential research group that would be widely imitated by such contemporary powerhouses as the Maryland Institute for Technology in the Humanities and the Center for Digital Research in the Humanities — should surprise no one.

We like to marvel at the technological wonders that proceed from things like servers, but in this case – I would say, in all cases – the miracle of “computers in the humanities” is the way it forced even a highly balkanized academy into new kinds of social formations. Anyone involved with any of these big centers will tell you that they are rare sites of genuine collaboration and intellectual synergy – that they explode disciplinary boundaries and even the cherished hierarchies of academic rank. They do this, because … well, really because no one really knows what they’re doing. Because both the English professor and the History professor need to learn mysql; because the undergraduate student from art history happens to be the only one who knows PHP; because actually, you do need to learn how to draw (or at least know something about design), and the designers are pleased to reveal their art to you. Because you know Java.

These may not sound like disruptive modalities, but in an area of scholarship where co-authorship is viewed with suspicion and collaboration is rare, the idea that you couldn’t master everything necessary to create a digital archive or write a piece of software was a complete revelation. It forced scholars to imagine their activities in terms of highly interdependent groups. To succeed, you had to become like the Clerk in The Canterbury Tales; “gladly would he learn and gladly would he teach.” Working as a full-time programmer at IATH in the late nineties (while finishing a Ph.D. in English) not only changed the way I think about computers in the humanities, but changed the way I think about the humanities, and about higher education itself.

Universities are designed around subject areas. But what if they were designed, like centers, around methodologies or even questions? Right now, we have English Departments, and Political Science Departments, and Biology Departments. And these various units – made up of people who only occasionally talk to each other – band off to form things like the Graduate Certificate Program in Eighteenth Century French Drama, or the Center for Peace Studies, or the Bioinformatics Initiative. What would it be like if that was all there was – structures meant to bring people and students together for as long as a methodology remains useful or a question remains interesting? Such entities would be born like centers – born with all the excitement and possibility of not knowing what you’re doing – of having to learn from each other what the methodologies and questions are really about. And they might also die like centers. I mentioned that I’ve been at a few center funerals, and I can tell you that they don’t die the way you think (lack of funding, for example, is probably the least common reason). Mostly, they die because people move on to other questions and concerns. And what’s wrong with that? You could imagine a university in which scholars move through a number of different centers over the course of a career, and students pass through a number of them on the way to a degree (we’d have to change the names of the degrees to something vague, like “Bachelor of Arts” or “Doctor of Philosophy”).

The things holding us back from this kind of grand vision are manifold. But in the case of the Digital Humanities centers, I think there’s a particular problem that we do well to acknowledge. Every center for Digital Humanities that I am aware of has some kind of service component. I don’t mean outreach of the sort that centers very often do – sponsoring activities for other parts of the university and for the wider community is a wonderful thing for any research group to do, and we need to do more of it. I mean the evangelical role that all digital humanities centers are expected to have. For most centers, it was just part of the deal; we’ll give you the center if you agree to act as the helpdesk for the legions of scholars who would like to create their own blogs and wikis. What’s that you say? Those legions don’t exist? Well, you can create them. In fact, we’d like you to spearhead our technological march into the twenty-first century by acting as catalyst for the “digital campus.”

I wouldn’t want to suggest that digital centers should become little ivory towers in the wider fortress. But I would suggest that Deans and Administrators preparing to establish Centers ask themselves why the Center for Peace Studies is not expected to ensure peaceful meetings in the German Department or why the Bioinformatics Initiative is not saddled with the task of assisting anyone who expresses an interest in their family history. Are we finally ready to create centers in the Digital Humanities that are valued not because of the services they provide, but because of the culture they represent – a culture that has always been about the two things we value most: the advancement of knowledge and the education of students.

Years ago, while working at IATH, my dissertation director (Jerome McGann, one of the cargo cult founders) stopped me in the hallway and said, “Steve, be sure to treasure this experience. I’ve worked in this field a long time, and I can tell you: you may never see this again.” I think Jerry was right and wrong about that. He was wrong; I’ve managed to see it several times since leaving IATH, most especially at the center I’m now involved with (The Center for Digital Research in the Humanities). But he was also right. It’s easy to treasure the wrong thing about digital centers: to see the excitement brewing in a community of teachers, students, and researchers as a new opportunity for what we might do, rather than a way to affirm an amazing thing that has already happened.

Day of DH 2010

2010-03-18T00:00:00-05:00

Today, I’m blogging over here for the Day of DH 2010. Hashtag for the affair is #dayofdh.

The Day of Digital Humanities is a virtual flash mob in which lots of digital humanists blog about their day. We do it mainly to demonstrate to other scholarly communities that we have way more fun than they do.

QED

2009-12-31T00:00:00-06:00

I’ve been reading an excellent biography of Thomas Aquinas and came across this quote, which I’d like to append to all my writings from now on:

If anyone, glorifying himself with false knowledge, dares to argue against what I have just written, let him not babble in the corners or with infants who are incapable of judging such a difficult subject, but let him write against this book – if he dares. You will then have to deal not solely with me, who am only the least in this affair, but with a crowd of other lovers of the truth who know how to resist your errors and remedy your ignorance.

Got that, quodlibbers? Anyone who wants to talk smack about hypostatic union better lock and load. That’s Thomas with “St.,” yo.

The biography is Saint Thomas Aquinas: The Person and His Work by Jean-Pierre Torrell.

Digital Campus

2009-10-29T00:00:00-05:00

Continuing this week’s media blitz …

The folks at the Center for History and New Media have, at their extreme peril, invited me to be an “irregular” on the Digital Campus podcast (think of a shirt that is discounted because it’s missing a button). This week, I joined Dan Cohen, Mills Kelly, Tom Scheinfeldt, and fellow irregular Bryan Alexander (Research Director for NITLE) in an episode entitled ”Theremin Dreams.”

Critical Code Studies

2009-10-26T00:00:00-05:00

I was very pleased to be invited, a month or so ago, to be a contributor to the Critical Code Studies blog (maintained by Mark C. Marino at USC). In fact, I was so pleased that I actually wrote something, which, although it probably diminishes the overall quality of the discussion considerably, nonetheless expresses my hope that just as literary studies began (according to one pataphysical genealogy) with belles-lettres, so critical code studies might have its own tradition of bit-lettristic writing.

I have a lot more to say on that subject, actually, but it will have to wait. I am so very, very far from inbox zero.

The essay is called, ”Tim Toady Bicarbonate.”

Humanities APIs

2009-10-17T00:00:00-05:00

I am very pleased to be attending the Workshop on Application Programming Interfaces for the Digital Humanities sponsored by SSHRC and hosted by the amazing Bill Turkel in his role as a member of NiCHE.

Here are a few things I’m thinking about going into Day 2:

In talking about APIs, we’re necessarily talking about access and the political and cultural issues that surround access to cultural heritage materials. It’s one thing for a library (say) to make some data collection available and to allow you to browse, search, and display it in various ways. It’s another thing to allow other people to come along and create their own ways of browsing, searching, viewing (which is what API access is really about). I think we need to insist on the necessity of this form of access as essential to the future of digital work in the humanities and social sciences. At the same time, we need to be respectful of those who are understandably nervous about it. How do we articulate the benefits of this kind of access? How do we persuade content providers that this kind of access is good for the institutions that provide it, and not just for the people who take advantage of the new entry point?
There’s a movable wall when it comes to APIs. I heard a lot of people yesterday describing elaborate ideas about data mining with textual resources (or something similarly ambitious), but in every case, I noticed that the idea was predicated not on access to a series of data points, but on access to the entire dataset. This raises a fundamental question (for designers) on where you put the “wall” between the resource and the user. You could imagine an API that had a single function called “get_all()” Call that, and you can mirror the entire dataset and do what you like. You could also have an API with dozens of highly granular hooks that return nicely formatted data structures, and so forth. The former is undoubtedly the most flexible, but it’s also the hardest to work with (particularly if you’re a novice programmer). But again, it’s a kind of shifting wall. If it’s data mining you’re after, you could do all that mining back on the archive side and make the results available through the (highly granular) API. These aren’t mutually exclusive, of course; Flickr, for example, offers both kinds. Still, I think thinking about this helps to highlight some of the design challenges one encounters with APIs in general.
I think we need to think more carefully about “impedance mismatches” between data sources. There was a lot of talk yesterday about mashing this humanities resource to that humanities resource, but I think there were also some hand-waving assumptions (I was guilty as much as anyone) about the degree to which that data is tractable from an interoperability standpoint. Some of the most successful web service APIs are successful, I think, because the data is simple and easy to work with (lat/longs, METAR data, stats arranged as key-value pairs, etc.). Humanities resources are often quite a bit more complicated, and there’s far less agreement about how that data should be formatted. It’s true that the TEI (for example) provides a degree of metadata standardization, but it’s mostly silent about how the content itself should be formatted. That is, when you actually look at the content of the “tags” (whether it’s XML or something else entirely), you find that people are defining things at radically different levels of granularity and with different ordering schemes. I don’t want to declare that the sky is falling; I just want to point out that some of this might be quite a bit more difficult than it sounds. And it’s a tough problem, because defining complicated interoperability standards in this space really does, in my opinion, run against the spirit of the thing.

I’ve had a wonderful time at this gathering, which includes so many talented librarians, scholars, and hackers (many of whom manage to combine all three skill sets). I can’t help but think that great things will come of this.

What Have We Gotten Ourselves Into?

2009-08-22T00:00:00-05:00

The blog stats are simply astounding. Tens – nay, teens – of people finding their way to my blog. Do they seek enlightenment through cartoonish dialogues? Solemn meditations on cooking? Pronouncements on programming languages and aesthetics?

No, silly, they want the syllabus!

The course enrollment is bursting at the seams (as is my email with override requests from prospective students). So let me say right now: the subject is dull, the assignments are impossible, and the professor is a jerk.

Oh, who am I kidding? The subject is fascinating and the professor is a sweetheart! (Sorry, the assignments really are impossible). He looks forward to welcoming everyone on Monday.

Writing as Programming as Writing

2009-06-27T00:00:00-05:00

Back in 2003, at the Digital Humanities conference in Athens, Georgia, Geoffrey Rockwell and I threw all caution to the wind and performed a live Brechto-Socratic dialogue on the relationship between programming and writing. People still ask us about it, but we’ve never been sure exactly what to do with it.

The intellectual glow of THATCamp must have put me in the mood, because this afternoon it came to me – the ideal forum for what Geoffrey and I privately refer to as ”Untitled #4.”

It was impossible to give Geoffrey’s character his signature beard, but other than that, I would say it perfectly recreates the original performance (including our extraordinary range as “voice talents”). Enjoy!

You can also see it here and here. Or, um, here.

Day in the Life

2009-03-18T00:00:00-05:00

Today, I’m blogging on a different site as part of the Day in the Life of the Digital Humanities. There’s an RSS feed, if you’d like to drink from the fire hose.

I’m already doing it wrong, of course – my first post is way too long, and it won’t help with any kind of auto-ethnographic anything. But then, I’m skeptical toward this whole thing. And I’m on Spring Break.

The No-Reading Seminar

2009-01-30T00:00:00-06:00

In my digital humanities classes, I always try to combine the technical with the philosophical (which, I believe, is one of the things that characterizes DH as a discipline). So, we’ll often study control structures on Monday and Wednesday, and then spend Friday talking about new media theory and digital humanities more generally. In the first semester, we read mostly excerpts and articles (McLuhan, Bush, Licklider, Turing, Hayles, Bolter, McCarty, Manovich, Kirschenbaum, and Rockwell show up pretty regularly). In the second semester, however, I usually suggest that we focus on one or two texts – preferably, some very difficult texts. Last semester we read a good bit of A Thousand Plateaus (we planned to read Badiou’s Being and Event, but didn’t get to it).

This semester, I had a bit of a brainstorm and suggested to the students that we might read Heidegger’s “The Question Concerning Technology,” but read it only in class with each other. In other words, no one is allowed to read the text outside of class. We all bring a copy of the essay, but then we put a version up on the screen for everyone to read, and we each take turns reading paragraphs. They liked this idea.

We’ve now done it twice and have made it all the way to the eighth paragraph of the essay. I’m not at all bothered by the slow pace, because I truly think that this is one of most enlightening class discussions I’ve ever been a part of (either as a student or a teacher).

What do we talk about? Mostly, we try to make sure that we understand Heidegger (this is a very difficult essay even relative to Heidegger’s already demanding corpus). But the real thrill, is that we end up thinking deeply about whether we agree or disagree with him, about our own definitions of technology, about causality, definition, ontology, and the tradition in which we’re reading. I walk out of the room thinking, “Now that’s a discussion,” while firmly believing that the professor is only a very small part of what’s going on.

As far as I can tell, the students are also finding it enlightening. We may burn out as winter turns to spring, but for now, I am being reminded every Friday of what the classroom is all about.

MLA Stylin'

2008-05-30T00:00:00-05:00

Like most of you, I’ve been perched on my front porch every day for two weeks waiting for the new (3rd. edition) of the MLA Style Manual and Guide to Scholarly Publishing to arrive. At long last, it came. Naturally, I sat down and read it cover to cover.

I don’t want to spoil it for anyone. I will note, however, that my lifelong dream of having one of my articles cited as an example of the use of italicized titles was not realized.

However, that insufferable slight was almost ameliorated by a new section on Fair Use that, in comparison to the cold informational tone of previous editions, almost rises to the level of protest. I particularly welcome the addition of such detailed explanations, which occur amidst frequent mention of the case law governing the Fair Use provision:

Congress intended the statutory provision … to restate the fair use doctrine that existed before the passage of the act, not to change, narrow, or enlarge it in any way, as the reports of the House and Senate committees make clear. Accordingly, all decisions of the courts before and after the 1976 Copyright Act are relevant to the determination of copyright law. […] Furthermore, the Copyright Act makes no statement amount the relative importance of the [four] factors, and the Supreme Court clarified in Campbell v. Acuff-Rose Music, Inc. (1994) that no one factor is more important than the others, nor must the use be supported by all four factors to be fair. (51)

And my favorite …

Although one occasionally hears that it is acceptable to use some percentage of the work or some specified number of words, neither the statute nor any regulation nor case law sanctions such guidelines on the quantity of material protected by copyright that may be taken without permission, and authors should not rely on them.

Actually, one doesn’t “occasionally hear” that it is acceptable. I have yet to encounter a library or department that doesn’t hand out a sheet describing exactly how many pages (or lines, or words) one can copy from a text before it violates what is widely understood to be the most important of the four factors (“The effect of the use on the potential market for or value of the copyrighted work”). “Very few,” is the message communicated by these guidelines, and yet most people I know understand it as an articulation of the Fair Use provision. Few seem to be aware that these guidelines were written by the Association of American Publishers – a trade association primarily concerned with protecting the industry – and have no basis in law.

It’s refreshing to see an articulation of Fair Use (put forth by a major scholarly society) that does not attempt to frighten authors into complying with the industry’s reading of the statute, but instead subtly urges American authors to assert their Fair Use rights as citizens engaged in “criticism, comment, news reporting, teaching …, scholarship, or research” (51). Perhaps we could excerpt this fine section (2.2.13) of the MLA Style Manual and hand it out in department copy centers as a replacement for the AAP’s manifesto?

Digital Campus

2008-04-21T00:00:00-05:00

I was delighted to be a guest (along with Bill Turkel) on Digital Campus for their 25th episode. I haven’t listened to it yet – and so I’m not sure to what degree I made a fool of myself – but it was great fun to hang out with Bill, Dan, and Tom.

Digital Campus, of course, is the fantastic podcast put out by The Center for History and New Media at George Mason University.

The Race Car Bed

2008-04-19T00:00:00-05:00

Some time ago, I posted an essay on craftsmanship that featured a piece of furniture that my father built. That essay turned out to be the most popular blog post I’ve written, and it also led to a number of emails expressing admiration for my father’s skills as a woodworker. It is with great pleasure, then, that I post this most recent example of my father’s work – a “race car” bed for my three-year-old nephew Angus:

Now, I’m going to guess that most of my readers are over the age of thirty. But I know what you’re thinking: Can I have a race car bed?

High Performance Computing for English Majors

2008-04-14T00:00:00-05:00

[HPC has been coming up a lot lately in conversations I’ve been having with other DH specialists. Or it was, before I went in for sinus surgery a week ago. I’m still recovering from that, and I’m not really sure about my ability to blog coherently. So please accept this essay from the archives. It’s from a talk I gave at MLA in 2006.]

There are people in this world who spend untold amounts of time tweaking and tuning their cars for some perceived need for high performance that seldom materializes on roadways intended for passenger automobiles. They spend hours “modding” their rides: changing the gas-to-air ratio, boring out the cylinders, fiddling with the feathers and springs on the shock absorbers, and injecting nitrous oxide into the fuel line in order to get “Dude, like 450 horsepower” out of a sedan principally designed to ferry children to and from school.

I have precisely this relationship with computers. The latest chip, the fastest disks, the most efficient bus architectures all fill me with a kind atavistic frisson. And once I lay my hands on the geek equivalent of NOS, I start rebuilding the kernel, changing the shared memory footprint, altering the thread model, reconfiguring the drive geometry, and adding optimization flags to my C compiler. It is true that my machines are often on the verge of melting, but that’s the price of perfection. There’s even a special version of the Linux kernel for bleeding-edge speed freaks called the “Love Kernel.” It’s essentially the standard Linux kernel with hundreds of high-speed performance patches applied indiscriminately. Here’s a quote from the README for the Love kernel:

IMPORTANT: steel300 and OneOfOne remind you that the patches here are sometimes experimental and could explode upon impact, make your [soda|pop] really bland, or other badness. We aren’t responsible for that, but we will mention that these patches will also make your kernel ROCK LIKE NINJA.

And that’s what I want to do. I want my computers to rock like ninja.

In a sense, ordinary training in software design is responsible for creating this insane desire for speed. The entire study of algorithms and data structures is framed by a concern with the trade-offs between time and space. If you undertake formal study of these matters, you find that much of what you’re doing is calculating the best and worst case scenarios for storage and retrieval within a particular data structure or under the strictures of a certain algorithm. After awhile, you can’t help but equate faster, smaller, and more scalable with better.

But if you study software engineering and design methodology at any level of detail – or better yet, start writing production code – you quickly discover that this equation is downright dangerous. Code optimization is fine when you’re talking about a fake implementation of a sorting algorithm. In a large, complex system intended for actual users, however, premature optimization is more than likely to result in brittle, unreadable code. And this assumes that you understand where the bottlenecks are in the first place. This is why even a brief foray as a computational test pilot will cause one to develop certain rational instincts about code efficiency. You begin to lower the bar to something like “fast enough” in order to create code that is more easily maintained and understood. You begin to distrust any optimization that isn’t completely verifiable using profilers and benchmarking tools. You begin to realize that it might be safer and more efficient to drive the kids to school in a minivan. Or at least you realize that this is the rational position, even as you irrationally try to break the sound barrier.

I have been writing software for use in the context of digital humanities for about ten years. During that time, I have written thousands of lines of code, but all of it has fallen neatly into one of two categories. Either it was intended to deliver data to the Web, or it was intended to perform some kind of data analysis operation offline. That covers a lot of different types of systems, of course. Sometimes the data being delivered to the Web consisted of reams of GIS data that had to be paired with text, styled, and delivered to a client framework that would render a real-time animated map. Sometimes the offline data analysis consisted of computing complex graph theoretical algorithms for the purpose of studying relationships within a corpus. But in the former case, network latency had the effect of making most of my shrewd optimizations seem futile. Why work for hours on some little speed hack when the processing that occurs prior to network delivery and rendering is only a small fraction of the total end-to-end userspace time? In the latter case, it really didn’t matter how long the analysis took. I was the only one who needed the data, and there really wasn’t any particular rush. Who cares if it takes fifteen minutes – or even fifteen hours – to crunch the numbers?

For the last few years, I have been giving talks in which I proclaim an “age of tools” in digital humanities, and the evangelium goes something like this: Over the last twenty years, we have spent millions digitizing texts and putting them online. The resulting digital full-text archives are among the greatest achievements in digital humanities. Yet for all their wonder, they remain committed to a vision of digital textuality firmly ensconced within the metaphor of the physical library. You can browse the text, read the text, search the text, and even download the text, but you can’t really do much beyond that. It is time to start thinking of ways to exploit this data with analytical tools and visualizations. Ideally, such tools should be an integral part of the experience of working with Web-based text collections.

Several of my colleagues in the field are working on something like this, including my fellow panelists [Greg Crane and Geoff Rockwell - ed.]. My own contribution is as a member of the Nora Project, which endeavors to implement the credo outlined above with an emphasis on particular varieties of text analysis – including, most significantly, data mining and machine learning algorithms. I won’t speak for Geoff and Greg, but I think I know why I’m here today talking about high-performance. It’s because for the first time in my career, caffeine-addled speed optimizations seem not only warranted, but necessary.

They’re necessary, because when we talk about large, full-text archives empowered by text analytical tools and visualizations, we’re really talking about trying to take procedures traditionally thought of as batch-processing jobs and importing them into a world in which, as Jacob Nielson famously noted, you have eight seconds to do something interesting.

Our data mining operations rely on massive matrices of data drawn from text corpora. For example, we might have a giant table (consisting of millions of cells) where one column is filled with word frequency counts, another one is filled with markers indicating the presence or absence of a certain feature, another is filled with ratios between nouns and verbs, and so on. We start out not knowing what any of this data really means, but we do know that texts (or parts of texts) in the corpus cluster in certain ways. There are genre distinctions, years of composition, different authors, different countries of origin. So we add one more column of data indicating the “label” for the particular text or text section. Text classification is the process of using statistics to figure out what patterns of low-level features conspire to make a text fit a particular label. So the usual method involves having a domain expert label some of the texts, and then setting the data mining algorithms loose on the rest of the matrix, so it can generate a set of predictive rules. If the rules are robust (and this is the exciting part) you should have a system that can correctly assign labels for texts it has never seen before. And, of course, the labels can be anything at all.

We’ve used data mining to create things like systems that can detect eroticism and sentimentality in English poetry and prose. And as soon as we say that, two objections emerge immediately. First, “Do we really need a system that can tell us that a particular Shakespeare play is a history? Don’t we already know that?” And second, “Who decides what passages are erotic or sentimental in the first place?” The first objection is an entirely sensible one, but what really intrigues us is the fact that the system often gets is “wrong” in some thoroughly thrilling way. The first time we ran a data mining operation on Shakespeare, it calmly informed us that both Romeo and Juliet and Othello are comedies. The computer scientists on the team were ready to go back to the drawing board, but the literary critics were more excited than ever, because, of course, a number of influential critics have noted that these two plays follow the basic dramatic structure of comedy, and all we wanted to do was look at the generated rules to see what low-level features are complicit in this subtle moment of generic ambiguity. The second objection – “who decides what the labels are” – is also a sensible objection, but we have an easy answer to that one. The user should decide. The user should be able to choose what vectors go into the matrix, and choose the labels.

And that brings me, at long last, to the main topic of this panel. Because until recently, no one has thought of data mining as a live, interactive process. To undertake meaningful data mining on full-text archives of literary texts, you need to parse the XML documents, tokenize them, run a series of natural language processing algorithms (to determining things like parts-of-speech), check them against a gazetteer (for named-entity resolution), and then crunch all the numbers. Then you need to assemble all of that data into a matrix. Then you need to do the actual data mining algorithm. Then you need to deliver it to the client and render it. This always takes hours, and it occasionally takes days. If you’re offline, it doesn’t matter (though even offline, you want to come to this problem fully armed with high-performance equipment). Online, it violates Nielson’s eight-second rule in a way that borders on the grotesque.

It’s possible to approach the optimization of this process in a thoroughly rational manner. First, you look at the whole end-to-end system and try to divide the operation into things that bind early and things that bind late. There’s no reason to parse the XML data and do the feature extraction live. All of that can be done at the pre-processing stage and loaded into a datastore of some kind. It might take days to do that, but if you’re clever, you can get a ton of “canned” data ready to be loaded into a matrix for analysis. After you’ve done that, you can think about ways to minimize the amount of data the system has to analyze, perhaps by segmenting the data in such a way that the system has less material to sort through as it loads the matrix. You might then look for obvious inefficiencies in the analysis layer itself, and try to optimize those as much as you can (without creating brittle, difficult-to-understand code). Finally, you can figure out ways to distribute the analytical process across multiple processors.

We’ve done all of that. We’ve canned it, chunked it, speed-hacked it, and even figured out a way to multithread the process across any arbitrary number of processors. The resulting system is dazzlingly fast. It’s just not fast enough for the Web. And so it is time, we think, to turn to some serious hardware.

And when we say serious, we’re not talking about expensive servers (we’ve got those). We’re talking about seriously expensive servers – distributed clusters of the sort that are used for things like particle physics, weather simulation, and the video rendering for Attack of the Clones. And that’s a problem.

It’s a problem, because in the context of a university, “high-performance computing” isn’t a technical term at all. It’s a financial act of faith made by very senior members of the administration, and a site of intense territorial protection by the “hard” scientists who help to make that act of faith seem less fraught with religious peril. A bunch of English professors who want to get into high-performance computing need to convince administrators that they should get a piece of the pie, and they need to convince the physicists that literary critics have just as much of a right to these resources as anyone else. Which should be an easy matter. All we need to do is talk to the people who are exploring the origins of the universe, and ask them to step aside for a moment while we look for dirty words in Dickinson.

And, of course, we won’t be asking them to step aside “for a moment.” Nearly everything done on these systems represents a batch job. The experiment (or the video rendering task) might take a long time, but it usually has a beginning and an end. We’re talking about ongoing processes running on a kind of supercollider Web server. Perhaps we need our own high-performance cluster? But then, who pays for such a thing? Digital humanities can bring in grant dollars, but most of the funding agencies we deal with are loath to fund even moderate amounts of overhead. Perhaps we are in over our heads.

Now, I’ve already confessed to being a semi-delusional, speed-obsessed maniac. Perhaps all of this represents nothing more than the idle fantasy of someone who wants “Dude, like 450 million words per second.” Surely, there’s much that we can do to bring about the age of tools without pouring millions of dollars into hardware. Why be so ambitious at this early stage? Do we really need to be thinking about high-performance computing for English majors?

I think we do need to be thinking about it – not because it’s a thing we need to have today, but because it’s a battle we’re going to need to fight tomorrow. To get where we are now in terms of text collections, we had to fight for resources that were unheard of among humanists. We were successful in that effort, not because we came up with outstanding technical arguments, but because we succeeded in effecting a cultural change at our institutions. We were able to convince Vice Presidents for Research that we could attract students and grant dollars. We were able to convince University Presidents that digital humanities was something of wide interest to the public (not to mention donors). We were able to convince library Deans that research efforts in this area could pay dividends in terms of prestige. And finally, we were able to convince our own professional societies (including the MLA) that scholarship in this area was essential to the future of the academy (witness, for example, that most astonishing of documents, the “Guidelines for Evaluating Work with Digital Media” put out by the MLA this year).

Of course, one need not act like a Ninja in order to rock like one. The best way to get into the high-stakes game of high-performance computing is to create compelling reasons to participate. I continue to believe that bringing analytical procedures to existing digital archives – particularly those that are as easy to use as search engines – is a worthy, if ambitious goal. Shadetree mechanics might have little hope of building their own highways, but clever digital humanists, by remaining committed to broad visions of the power of full-text archives, might well create the conditions in which high-performance becomes an ordinary part of our work as a discipline.

Being Trendy

2008-03-19T00:00:00-05:00

The Nation has a piece by William Deresiewicz called ”Professing Literature in 2008,” which presents a review of the Twentieth Anniversary edition of Gerald Graff’s Professing Literature. Mostly, it’s the usual screed, though it does a make a few points that even this pre-tenured radical might have to concede. I mention it here only to draw attention to the review’s most exhilarating moment – an “analysis” of the MLA job list:

There have always been trends in literary criticism, but the major trend now is trendiness itself, trendism, the desperate search for anything sexy. Contemporary lit, global lit, ethnic American lit; creative writing, film, ecocriticism–whatever. There are postings here for positions in science fiction, in fantasy literature, in children’s literature, even in something called “digital humanities.”

Language and Dictatorship

2008-03-16T00:00:00-05:00

The Arc forum has become my favorite list lately. There’s the usual stuff going on: feature requests, requests for help with specific coding problems, code examples, polls, challenges, and so forth. In this sense, it’s more or less like any other hacker forum. But there’s something else going on that’s very exciting.

Arc isn’t the first attempt to re-imagine Lisp outside of the Scheme and Common Lisp standards, but because Paul Graham – a very important voice in the Lisp community – is behind it, I think there’s an unusual amount of attention being paid to it. It’s also not a finished product (far from it), and so I think everyone is having a lot of fun trying to imagine what it might be. Graham’s writing the code, obviously, but the forum is full of bold thinking about where it might go, and I think that many of these ideas will come to influence the future of Arc.

One of the more interesting subjects to come up lately has been the issue of “dictatorship” versus what we might call “pluralism.” Now, when hackers use the word “dictatorship,” they don’t mean that in a bad way. When we say that a language is run by a dictatorship, we mean that its canonical form is determined by an individual or by a core group of developers. Perl is run this way, as is Ruby and Python (by Larry Wall, Yukihiro “Matz” Matsumoto, and Guido van Rossum, respectively). There aren’t dozens of implementations of these languages; there’s really only one of each. Few such languages are formally standardized, because there isn’t really a need to do so. If there were one relational database implementation in the world, I doubt very much that anyone would feel the need for an SQL standard. In a sense, standardization is a bit like radical Athenian democracy. We standardize not because everyone agrees, but because everyone does not agree. Various parties compromise in order to prevent any one faction from overwhelming the others. (This is in part why I find the impulse within the XML community toward creating “standards” for things that are not widely used or are brand new to be entirely baffling. Now that’s dictatorship!)

Until I started writing Lisp, I hadn’t really encountered anything other than dictatorship. One might argue C is run through pluralism, but the platforms I’ve worked on basically have one canonical implementation of the C compiler (gcc), so the effect is pretty much the same. But languages like Scheme and Common Lisp are quite different. There are standards for both languages, but there are dozens of implementations. And in the case of Scheme, the various implementations can differ wildly while still adhering to the (deliberately minimal) R5RS standard. Common Lisp has a much broader and more comprehensive standard, but even there, if you want to write code that can run under any implementation, you’re probably going to have to write some code that will check to see how things work in each of the major implementations.

Some people find this quite intolerable. They’d really like to be able to write code in CL or Scheme and have it run on any compliant implementation. Such people find the situation of Scheme to be particularly onerous, since the diversity of implementations really means that we need to speak not of Scheme, but “PLT Scheme scheme,” “Chicken Scheme scheme,” and “Bigloo Scheme scheme.” For these people, Arc feels like a chance to stop the chaos.

I’m personally not bothered by this, simply because I find that the kinds of things I write don’t need to run on multiple implementations, and the implementations I use tend to have everything I need. Most of the coding I do is intended for my own use, and while it would be nice not to have to ask my users to install a particular implementation, I don’t think many people find that qualification onerous. However, I can well understand why others would find this very frustrating. And everyone (including me) finds the situation at least mildly frustrating when it comes to third-party modules. If you write a module for doing, say, XML, shouldn’t it run on any Scheme interpreter/compiler out there?

I honestly don’t think Arc will achieve this, and I think the reasons involve an interesting mixture of the cultural and the technical.

The diversity of Lisp implementations is breathtaking. Some run as interpreters, some compile to C, some compile to native code, and some do all three. Some are designed to be embedded, others more or less ignore the OS. Some are designed to be “small and pure,” while others try to build into the language everything that would normally be in third party libraries. Some emphasize the ability to work with C libraries, while others are focused on the Web. And of course, there are versions not only for the major operating systems, but for handheld devices, the Java Virtual Machine, and microcontrollers. Incompatibilities abound, and yet if you’re, say, a Scheme programmer, you can probably find an implementation that seems highly optimized for whatever you’re trying to do.

All of this is facilitated by the most salient aspect of Lisp itself. Lisp has been aptly called “a programmable programming language,” because unlike the descendants of Algol, Lisp offers the programmer the ability to alter the syntax of the language itself with very little effort. In his book, Peter Siebel talks about how with most languages, the implementation of a new language feature almost always involves a drawn out process (which, in the case of a dictatorial language) can always be vetoed. And it’s easy to see why. A new language feature is almost certainly going to involve changing the compiler or the interpreter itself (and perhaps the external libraries as well). With Lisp, you just add it. This puts Lisp in the enviable position of being able to tack on – in a kind of borg-like fashion – any new trick that comes along. If you like Ruby’s for-each loop, and would like to add it to Scheme, you can do so in about a five minutes. But the same goes for object-oriented programming, aspect-oriented programming, meta programming, annotations, or whatever else is the flavor of the month. You don’t even have to settle on a particular style of, say, OO. You could write six different styles of OO and let the programmer just choose one that strikes his or her fancy. (One recalls Alan Kay’s famous quip, “I invented the term Object-Oriented, and I can tell you I did not have C++ in mind”). In a sense, every non-trivial Lisp program is a fork of the language.

Because Lisp is this way, it’s very hard to get people to settle on an implementation. If you don’t like the Perl module system, you have a couple of choices. You can either re-implement Perl or you can just suffer with what you have. With Lisp, it’s just too easy to change something like that, because it’s easy to change pretty much anything. And Lisps are (comparatively) easy to implement, so the low barriers to change extend even to matters that relate to the compiler itself. In fact, one could argue that this is precisely what Graham is doing – using Lisp to create a new Lisp that he likes. I suspect I’ll like it too. And so will lots of other people. But there will be many people who sorta like it. And they’re going to turn it into something they love.

Graham’s going to implement Arc in a way that makes sense to him. Being Paul Graham, he’s probably going to implement Arc in Arc (this, after all, is the guy who named his company after the Y combinator). I predict that people will then complain that it’s too slow – or too big, or too minimal, or too maximal, or too terse, or something else. But there just won’t be any strong disinsentive to go do something about it. And so a thousand flowers will bloom.

Of course, there are lots of things Graham and others could do to ensure that code that runs on one implementation runs on all the others, but I’m not sure that dictatorship, per se, is going to be a workable answer to the problem. Lisp programmers, perhaps more than any other kinds of hackers, really don’t like being told what to do. And they have the language to back them up.

Graham's Arc

2008-02-27T00:00:00-06:00

I will admit to being a huge (read, fawning) fan of Paul Graham. I’ve never met him, but I think his essays are terrific (especially the ones on Lisp). He clearly has a ninth-degree black belt in programming, and yet he’s one of the most clear-headed prose writers I’ve read when it comes to dilating complicated technical subjects. I, personally, would have no idea how Lisp macros – the single most powerful and mind-bending concept I’ve encountered in programming – work without the benefit of his book On Lisp, which has been circulating freely as digital samizdat on the Web for many years. Since I aspire to be both a black belt programmer and a clear-headed writer, I tend to take what he says and does very seriously indeed.

I’m not alone, of course, and so when Graham announced that he was creating a new dialect of Lisp (called “Arc”), I and many others got very excited. We were all particularly intrigued by the statement of design philosophy that appeared on his home page a couple of years ago, and have been waiting with bated breath ever since.

Well, Arc is out. And with its release (more of a stable pre-release) came a torrent of criticism. In fact, the criticism began years ago (Arc is vaporware, etc.). I won’t rehearse the criticism here; I’ll just make the general point that people have a lot of damn gall.

As far as I can tell, Paul Graham’s reasons for writing Arc are the same as for any voluntary development project. He’d like to give himself the tool he wishes he had, he’d like to amuse himself intellectually, he’d like to explore various aspects of design, he’d like to play around with some ideas he’s had for years, and he’d also like to contribute something useful to the world. These seem to me excellent reasons for doing just about anything, and it’s nice that he’s chosen to throw in the last one.

There are several legitimate reasons to feel miffed about software. You might be frustrated with the release schedule or the number of bugs or the fact that such-and-such a feature isn’t implemented yet. You might find the community that supports it unhelpful or the authors arrogant and imperious toward their users. You might think the whole thing is wrong from the start.

If it’s a commercial piece of software for which you’ve paid money, I can understand angry charges and criticisms. But FREE (as in beer, as in freedom, as in range, whatever) software? What gives anyone the right to shoot their mouth of like this?

It’s not that people can’t have these opinions. It’s that they air them so freely and with so little charity. Graham would be well within his rights to take his toys and go home, after all. He wouldn’t be the first FOSS developer to do so. It seems like once a month some talented hacker writes a farewell letter in which he or she admits that the constant battering is starting to wear them down.

I’m not suggesting that people stop critiquing software and design philosophies. Nor am I suggesting that everyone suppress their natural frustrations. I’m merely suggesting that all such critiques and frustrations be firmly wound up in a gentle cloak of charity, good will, and constructiveness. It might be true that the developer can tell a jackass from a contributor, but he or she might not. And the consequences of beating up on people in this way is the suppression of the motives I outlined above. Do we really want a world in which people don’t play for love of the game, but only because they’re compelled to by some other force?

In that piece on design philosophy, Graham wrote, “The great languages have been the ones that good programmers designed for their own use– C, Smalltalk, Lisp.” I think he’s right about that, and I think we could probably generalize that sentiment to lots of areas of human endeavor. Fortunately for us, lots of people with that idea have drawn the perfectly humane conclusion that what’s useful to them might be useful to others. If drawing that conclusion brings you nothing but grief, there’s no loss in really making it something for your own use. After all, couldn’t you just work on the project for love of the game and keep it to yourself?

If I were Graham, I might be asking myself why I’m even bothering. And that bothers me.

Language Games

2008-02-14T00:00:00-06:00

Stéfan Sinclair, one of DH’s most talented hackers, responded to the last post with a question about the “dominant language” in DH. I suggested it was Java, but (as I noted in the comment thread), I really have no basis for saying that. Here’s Stéfan:

I’d say (as unempirically) that there are more DH projects developing (not just using) code with scripting languages like PHP, than there are with Java, especially outside of the larger centres. But maybe this is just speculation based on what I see as the norm for project cycles: a researcher (or small team) gets some funding which includes money for hiring some research assistants – often graduate students – who are more likely competent in PHP (or Ruby or Perl) than in Java. Moreover, I think DH projects tend to favour getting something up fairly quickly over design and robustness; another reason why scripting languages would be more prominent. There are centres with dedicated staff willing and able to work in Java, but that seems to me a relatively rare luxury.

I didn’t mean to nitpick regarding a minor part of the post, I was just curious. I don’t think it’s crowning a champion programming language that matters, it’s more about how the reality of the DH research environment should be influencing the curriculum (or perhaps there are too few of us teaching programming for it to matter that much).

I think Stefan is probably right, but of course, both of us are relying on general impressions.

When you look at the development of computer science curricula over the last few decades, you can clearly see that discipline responding to industry pressures. Scheme might remain the language of Hal Abelson’s venerable 6.001 course at MIT, but in general, we’ve watched CS go from Pascal, to C, to C++, to Java as the demand for engineers with particular “skills” has changed out in the real world. I don’t know many CS professors who think C++ and Java are good teaching languages, though. Many of the professors I’ve talked to actually long for the days of Pascal, but they also know that students will object to learning a language that isn’t in common use.

When I started out in programming, I asked a friend (a very skilled hacker who was pursuing a Ph.D in CS at the time) what language I should learn first. I remember very clearly his answer, which was something like, “Oh, I don’t know. Just pick one. It doesn’t matter. How about a fake one? There are lots of cool pseudo-languages out there that will teach you what you need to know …” I thought he was 100% insane, and I was astonished that this guy – who was and is a master programmer, in addition to being a highly skilled theorist – would suggest something so obviously out of touch with reality. A few years later, I realized that he was 100% right. What’s important in programming is the concepts. If the goal is to learn programming and software engineering, the language literally doesn’t matter. Abelson’s Structure and Interpretation of Computer Programs (the textbook for 6.001), not only uses Scheme, but avoids explicitly teaching the language, per se. It’s perhaps the best book I’ve ever read on programming.

DH, thankfully, is not burdened with “industry pressures” in the way CS is. When I tell my students that it’s the concepts that are important, they believe me. They believed me even when none of their programming friends knew what Ruby was. I think they’d still believe me if I suggested that we all learn Haskell or Miranda. And that’s a good thing.

Still, it would be very useful to know what languages people regularly work with in DH. If we knew the answer to that question, those of us who teach programming for the Humanities (and I know there are only a few of us out there) could perhaps structure the teaching of the concepts in such a way as to make it easy to transfer that knowledge into other kinds of languages. I do this a little bit already, by occasionally pointing out the ways in which different languages – like C or Javascript – approach some concept that we’re studying in Ruby. I do that in part to emphasize that the fundamental concepts of programming don’t change drastically from language to language.

It would also be good to know what languages people use in DH, because it might help us to focus development where it’s most needed. We’ve been talking quite intensively about “tools” over the last few years in the DH community, but I’ve always felt that “tools” might best be thought of as an alias for libraries and APIs.

It’s not possible to do a scientific poll on a blog like this, but I suspect my readership has enough hackers in the ranks to get some good anecdotal information.

So how about it? What languages do you use? What languages do the people around you use? What languages are people telling you you should know? I’d love to hear about it!

Feelin' Groovy

2008-02-11T00:00:00-06:00

Well, it’s time to pick up another programming language.

I’ve been doing this about once a year since the late nineties, and in that time, my motivations for programming glossolalia have changed a few times. At first, I think I mostly wanted to jump on the latest bandwagon. I was also highly susceptible to arguments from more experienced hackers about how such-and-such a language was the Greatest Thing Ever. But after awhile, I found myself wanting to study languages because I find them completely fascinating. Nowadays, I think it’s just a way to expand my thinking about what languages are and what they can do.

But honestly, after doing this ten or twelve times, I find that I’m beginning to stray into the outer rim. What’s next? Haskell? Erlang? I had more or less decided that I’d do one of those over the summer, but a couple of days ago I stumbled on Groovy.

What’s Groovy? A language with an absurd name, for one. But beyond that, Groovy (according to the home page):

is an agile and dynamic language for the Java Virtual Machine
builds upon the strengths of Java but has additional power features inspired by languages like Python, Ruby and Smalltalk
makes modern programming features available to Java developers with almost-zero learning curve
supports Domain-Specific Languages and other compact syntax so your code becomes easy to read and maintain
makes writing shell and build scripts easy with its powerful processing primitives, OO abilities and an Ant DSL
increases developer productivity by reducing scaffolding code when developing web, GUI, database or console applications
simplifies testing by supporting unit testing and mocking out-of-the-box
seamlessly integrates with all existing Java objects and libraries
compiles straight to Java bytecode so you can use it anywhere you can use Java

I’ve used a few alternative languages for the JVM, including JRuby, Jython, and Kawa. I mean, what’s not to like? The syntax of Ruby, Python, or (be still my beating heart) Scheme with all the might and magic of the Java class library? What could be better?

In my experience, the original languages and runtime environments are better. I don’t know what it is. I always feel like the Javish stuff just don’t belong there somehow – like it’s some kind of crude hack. And before I get hate mail, let me say that these implementations are not crude hacks. They’re very skillfully done. There’s just something about the mixture that doesn’t sit well with me.

I haven’t started looking closely at Groovy yet, but I can see the general plan. They’ve taken some of the best ideas from languages like Ruby, Perl, Python, and Smalltalk, kept the general contours of Java’s C-ish syntax, and built a scripting language that has all the soul-stirring power and ubiquity of the Java class library in a nice little package. And, of course, it’s trivially easy to embed Groovy in Java or to integrate them in some other way.

Now, I might find it annoying (that is: slow, or poorly documented, or whatever). But if it really does have the ease of use and expressive power of a good scripting language, I may start teaching it in my Digital Humanities courses. I’ve been teaching Ruby to English majors for a number of years now, and I still think it’s a magnificent teaching language. But if Groovy was similarly good for teaching and allowed an easy migration path for students interested in Java, I just might be sold. Java is the dominant language in DH, and while a few of my students have been able to pick up Java after learning Ruby, it would be nice to have a language that was semantically closer to Java. I could imagine a class that goes through Groovy, and then ends by starting off with Java. But then, Groovy really would have to be groovy.

They will have to change the name, though. Can I really have a course description that says we’ll be learning Groovy?

I’ll report back when I’ve played with it some more.

Zenware

2008-01-26T00:00:00-06:00

As an addendum to last week’s discussion of writing workflows, I offer a quote – cribbed directly from Matt Wood at 43 Folders – which is in turn taken from Jeffrey MacIntire’s The Tao of Screen over at Slate. How’s that for connectivity? To wit:

There’s an emerging market for programs that introduce much-needed traffic calming to our massively expanding desktops. The name for this genre of clutter-management software: zenware.

The philosophy behind zenware is to force the desktop back to its Platonic essence. There are several strategies for achieving this, but most rely on suppressing the visual elements you’re used to: windows, icons, and toolbars. The applications themselves eschew pull-down menus or hide off-screen while you work. Even if you consider yourself inured to their presence, the theory goes, you’ll benefit most from their absence.

This explains, perhaps, the sudden interest in stripped down word processing environments for professional writers (like Scrivener, which is gradually becoming the easel of my intellectual life). It also explains why I was so happy – and dare I say productive – using the the BlackBox window manager on Linux for the better part of ten years. Something about its spartan landscape made me want to sink into the eremitic confines of words and code. When I see “iconistan” (McIntire’s phrase) on someone else’s desktop, I sometimes wonder how they manage to get through the day.

It strikes me that the Zen interface does not necessarily mean the simple interface. The Linux command-line (or is that “koan-line?”) is hardly simple, and yet it continues to fill me with pleasure (or is that “satori?”) – in part because there’s nothing to do there but work and think.

I’m hiding everything from now on.

Writing Implements

2008-01-19T00:00:00-06:00

I haven’t used a word processor, for anything other than opening someone else’s document, in over ten years. Truth is, I do just about everything in Vi.

That’s right, folks. Vi. The editor optimized for 2600-baud modems. The one with the near-vertical learning curve. The one that requires a mode change for delete. I’ve used it to write an entire dissertation, one book (and most of another), dozens of articles and papers, thousands of emails, and many thousands of lines of code. Not only that, but I use it in console mode. No GUI, no buttons, no windows. Vi.

I could wax on about the virtues of Vi, but my rationale for using it – or, more broadly, my reasons for using an industrial-strength text editor as opposed to a word processor for everyday writing – didn’t come suddenly. I started doing everything in Vi, because my first real job involved programming in UNIX.

I started out in digital humanities in a shop that ran pretty much exclusively on UNIX (AIX, no less). I ended up falling very much in love with UNIX, and decided (after being a loyal Mac user for a number of years) that I’d start running Linux at home. That turned out to be a wise move. When, years later, I found myself in charge of maintaining a rack of high-performance servers, I knew exactly what to do. Ten years on, I know A Lot about Linux.

But from my first moment as a full-time Linux user, I found myself stuck with a serious problem. What was I going to do for word processing? OpenOffice didn’t exist at that point, and I was still in graduate school with lots of seminar papers to write. I looked around at what the UNIX folks were using, and discovered LaTeX. I was hooked.

Sometime later, I got deeply into the whole business of creating beautiful documents. I read a lot about book design, typography, visualization, illustration, and print history, and as a result, I started to care a lot about how my documents looked. LaTeX was good for this, because it (and its parent, TeX) allow a virtually limitless level of control over how things look. But even before I got good with LaTeX, I liked the mere fact that I could compose (in ASCII) in one window, but have a beautiful final version of my document in another. It was as if I was able to see what my prose would look like “in print.”

Recently, I read an article about the tools that professional writers like to work with. As you might guess, people were pretty much all over the map. Some write everything long hand on legal pads and then type it into Word later on. Some compose directly in a word processor (with a lot of people clinging to tools that haven’t been officially supported in years). I was stunned, though, to discover how many pros — including novelists — work in something like Quark for exactly the same reason that I was working in LaTeX; they wanted to know how it was going to look when it rolled off the press (even though it’s highly unlikely that the publisher will accept the author’s own designs).

After awhile, my workflow started to seem more like a photographer’s workflow than a writer’s workflow. I had separate applications for editing (vi), spell checking (aspell), document design and layout (Scribus and LaTeX), typography (various fontbook applications), illustration (Inkscape), photo editing (The Gimp), citation management (BibTeX), and printing (Ghostscript and Acrobat). Today, I tend to use all of these types of tools fairly regularly for things that most people would do with Word. A few months ago, I bought my first Mac in about twelve years, but it actually had very little effect on my writing workflow. InDesign replaced Scribus, Illustrator replaced Inkscape, Photoshop replaced Gimp, but everything else stayed the same. Vi and LaTeX run perfectly fine on the Mac (as they do on the VAX, the Commodore 64, and that Lisp Machine you picked up on eBay).

I wouldn’t try to defend this way of doing things. Writing tools are an individual thing. Some writers don’t care at all about how it’s going to look when it’s printed. In fact, some prefer not to think about that at all when they’re composing. Some people really can’t work without a fountain pen and a legal pad. Others never write with a pen (I’m one of them, actually). Some compose in Word and are capable of amazing feats of ingenuity with it. Some people, amazingly, compose in Quark. But when I started publishing, I realized that there were great advantages to working in an ASCII editor. Publishers accept submissions in a number of formats, including Word, ASCII, PDF, and RTF. A few will accept submissions in LaTeX. But they’re all united on one point: they want the document to be as dumb as you can possibly make it. They don’t want you designing the text. No matter how much you might care about how your work looks, your main goal before you send it to a publisher is making sure it looks as much as possible like it was composed on an IBM Selectric in 12-point Pica. And, of course, if you’re working with desktop publishing applications yourself, you’ll probably find the “pour” less problematic if you start with flat ASCII.

(Oh, how I love that word “pour” when applied to text. “Import” makes it sound as if I’ve established a trade agreement with Adobe.)

All of this has been on my mind a lot lately, because I’m thinking of changing my basic editor (for writing, not coding). If you write for a living, you’ll understand that this is a bit like contemplating a change of religion.

I got on this tangent after reading a really good (not to mention funny) article by Virginia Heffernan in The New York Times called “An Interface of One’s Own.” I’ll leave that essay (with its “Goodbye cruel Word”) as an exercise to the reader, but I’ll reiterate the general point: word processors may not be sufficiently geared toward the work habits and needs (not to mention the peculiar idiosyncracies) of most professional writers.

That article got me exploring Scrivener, which is a very impressive tool (its virtues, along with the features of several other “writing-centric” editors, are lovingly described in the article). I’m not sure I’ll switch. In fact, I think I’ll probably use up the entire thirty-day trial before I make a final decision. But so far, it seems to be the ideal tool for the way I work. It separates composing from designing, offers lots of different “compile” options for exporting into various layout programs (including Word, which one might think of as an easy-to-use layout tool), and has lots of different features for organizing large writing projects. There’s a movie available that will give you a sense of how it works.

You’d think I was buying a car or investing in a company. It’s a big decision. But then, I spend more time with my writing tools than I do with any other single application (save, perhaps, my Web browser).

So, what’s your workflow like? Are you happy with your tools? I’d love to hear about it.

Greetings Humanists!

2008-01-16T00:00:00-06:00

I’ve noticed a sudden upsurge in foot traffic since Edward Vanhoutte graciously included me in his list of “digital humanities blogs” in a recent post to Humanist. These visitors are undoubtedly perplexed to find me talking about, um, furniture.

When I started this blog, I had every intention of focusing on digital humanities, and that remains a big part of what appears here (most things I write wind up having something to say about something digital). But over the course of the year, I have discovered that it’s a great place to park essayistic writing that doesn’t seem to fit anywhere else in my professional world. In the end, this is the kind of writing I most enjoy doing, and my friends and colleagues have generously indulged me by reading it and offering their comments from time to time.

I’m pleased, though, to be considered part of the cadre of bloggers in digital humanities – particularly given the quality of work you’ll see if you visit the links on my blogroll – and I have every intention of visiting that theme often.

Still, if meditations on cooking and woodworking tools are not to your taste, you may want to set your aggregator (if you’re using one) to one or more of the revelent categories on the sidebar: particularly “digital humanities” and “programming.” “geeking out” is usually devoted to quick things of a humorous (or ironic) bent, and “belles lettres” is for the essays. “rand()” speaks for itself.

But honestly, you shouldn’t waste your valuable coffee break on this post at all. All the action is over at Lisa Spiro’s Year in Review.

Tool Envy

2007-12-31T00:00:00-06:00

My father has been an amateur woodworker for nearly forty years, and this Christmas I had a chance to see what anyone would have to consider his masterpiece: a secretary built in solid mahogany using mostly hand tools.

It’s a stunning work to which these photographs do meager justice. The hand carved ball-and-claw feet support a “bombe chest” with curves so dramatic that they seem an impossible outcome for the material from which they were formed. The doors above swing open, like an old watch case, to reveal a warren of little drawers, a writing desk, and a pair of slim shelves for candles. I cannot imagine what letter would be of such importance that it would require the use of such a dais, except perhaps a letter of gratitude to the saplings of the tree that gave its life for something so grand and beautiful.

It is a cruel fact of my genetic makeup that I have no talent for such things (my brother, a couple of years younger than me, pursues the construction of guitars with an ease I find almost insulting). I am occasionally filled with the desire to pursue my father’s avocation, but I find, upon careful examination, that it is not the bombe chest that I desire so much as Sunday afternoons in a quiet workshop. I remember the smell of wood shavings from my childhood the way others remember the smell of baking bread, and the simplicity of the questions and answers that attend the activity. “What are you building?” I’d ask. “A chair,” he’d say. Never in my life as a scholar have I been able to answer a question about what I was doing so briefly and with such certainty.

In the end, though, it’s the tools that fill me with envy. Woodworking tools are perhaps the only thing more beautiful than a meticulously crafted piece of furniture. Even their names fill me with pleasure: rabbet plane, coping saw, mortise gauge, firmer chisel, oilstone. They are heavy, solid, sharp, durable, and greet you like a firm handshake when you hold them. Like hunting dogs and violins, they long to fulfill their purpose. My father tells a story of how, as a young child, he gave me a cross-cutting saw and a huge block of wood. I sawed away with fury for a long while, and when the piece was finally cut I burst into tears. Whether those were tears of joy or sorrow I cannot recall, but even today I see the logic of that response.

Years later, as a student in college, I fell in with a crowd of oil painters, and the sweet smell of turpentine was added to my list of madeleines. They also had tools, and I envied the materiality of art making as I envied the haptic pleasures of the workshop. Gesso, stretcher bars, oil paint, brushes, wax medium. I am even less able to make art than furniture, but the physicality of art fascinates me to this day. As a young prose writer, I was beginning to understand the importance of erasure. But how I longed to undertake that activity with the same bodily exertion they used when they scraped the paint off a canvas with a spatula and wiped their considered thoughts on the pant leg of their jeans.

I had no real idea of the physicality of my medium until graduate school when, in a class that looked at “books as physical objects,” I was able to handle 400-year-old codices that possessed nearly all of the qualities of my father’s secretary. Books of the hand press period needed to be pressed, sewn, bound, and cut, and there were tools for doing all of these things. As with woodworking tools, these ones had magnificent names: piercing awl, bone folder, composing stick, chase, galley, foolscap. Once, I had a chance to pull the bar of a wooden hand press. My body thrilled to it just as it did when, again in childhood, I would bring an axe down upon a log I was splitting for the woodstove in our basement. “Let the tool do the work,” my father used to say. And what work it is when the kinetic energy of arms and shoulders presses ink into paper like a hot brand.

I do not wish this to be taken for nostalgia. I do not long for the days of quill pens and hand presses. The tools of my trade are digital, and I cannot see a single argument for why it should be otherwise. At the same time, I do not understand why these new tools cannot have the solidity and craftsmanship of the old.

Computers are marvelous devices, but a laptop is to a wooden hand press as a disposable razor is to a Lie-Nielsen block plane. I adore the the MacBook Pro I’m using to write this essay, but I adore it solely for what it allows me to do. There is no pleasure in its keys, its buttons, its adapters, or its hinge, all of which seem fragile and temporary. Apple has rightfully won awards for its sleek, innovative designs, but no one would think to give a craftsmanship award to the manufacturers who stamp them out like cans for holding tuna.

One might argue that sophisticated equipment must be delicate by nature, but no one who has held a camera made by Leica or Rollei could think such a thing. In fact, these cameras are the closest thing I know to the high quality hand tools of the page. It is impossible not to feel pleasure when hitting the shutter release on a Leica and hearing the clockwork miracles within. A Rolleiflex is as solid, as unlikely, and as perfectly proportioned as a bombe chest. No one doubts that they will work a century from now. Whenever I hit the power button on a laptop, I wonder if I’m pressing it too hard.

I will never own a Rollei or a Leica. Only a professional would dare spend that kind of money on a tool, and only a professional would demand this level of perfection. I understand this, because as a professional writer and programmer, I spend three or four times what ordinary people spend on their computers. For my money, I get ungodly levels of speed, panoramic monitors, and more storage than I know what do with, but I do not get anything fit to stand in the same room as a Leica. The parts of my computers break like everyone else’s. None of them could stand a three inch drop. They will be sent to the landfill without a hint of farewell.

People complained when they discovered that the battery for the new iPhone is soldered in – aghast at the thought that Apple was merely trying to create eventual enthusiasm for iPhone 2.0. It didn’t occur to anyone that the iPhone might fall apart in your hand before the battery wears out. Those who complain about the present flimsiness of electronic media devices are offered “ruggedized” tools, but there is no point of comparison between “ruggedization” and craftsmanship. The former tries to compensate for what is, at heart, chintzy and ephemeral; the latter aims to avoid the need for such compromises in the first place.

I said before that there was no nostalgia in my longing for high quality tools, but perhaps there is. Next to my high-performance desktop machine – the case of which, after a year, is already beginning to discolor – there’s a notebook and a pencil for which I together paid nearly fifty dollars. The former is a beautifully made Moleskine notebook with a sewn binding and solid boards. The latter is a perfectly crafted lead holder with a clutch as firm and eternal as the clutch on a Lambourghini. I did not hesitate at the price of either, and would gladly pay more. I am, after all, a craftsman.

The Nora Demo

2007-06-18T00:00:00-05:00

My colleagues on the MONK project have assembled a fine video of the nora system illustrating how a scholar might use it to explore erotic language in the letters of Emily Dickinson.

As much as I like the demo, I’m even more excited by the fundamental methodology behind it: using machine learning to leverage one’s own sense of things in the process of interpreting texts. In essence, we’re trying to provide users not with some empirical evidence to support a preconceived conclusion (as is often the case in traditional text analysis), but with a new view of the text that requires further interpretation. The nora system (and the MONK techniques that are now in development) don’t try to tell you what an erotic text is. It lets you decide that, and then it takes that set of interpretive judgments as the basis for further views of the text. The result is that one “sees an aspect,” as Wittgenstein put it, and in my estimation, seeing aspects is precisely what literary criticism (and much of humanistic inquiry) is all about.

Very exciting times for text analysis and visualization in the humanities.

Richard Rorty (1931-2007)

2007-06-12T00:00:00-05:00

When I arrived at the University of Virginia in 1992 – to begin a doctorate in English – I had no thought of doing anything with computers. The theory explosion of the 80s hadn’t fully ebbed, and the academy was busy kneading what it had learned from continental philosophy into the “new historicism.” I was there, of course, to become a literary theorist.

But I was a strange theorist. My heroes weren’t Derrida and Foucault, but the Anglo-American language philosophers – in particular, Wittgenstein whom I still regard as the greatest modern philosopher. I had dreams of reforming hermeneutical theory, not with the bitter skepticism of European post-structuralism, but with the down-to-earth good sense of those who had wisely ignored Saussure’s conundrums.

But what to do with such a weirdo? Imagine my surprise when I was assigned Richard Rorty – easily the most famous living American philosopher – as my advisor!

Rorty had ascended to the position of Chair of the Humanities at UVA, which, he explained to me at our first meeting, meant that he had no meetings to go to. ”I’m afraid I know nothing of the technical details involved with getting a graduate degree,” he said, taking a draw on his pipe, “so we’ll have to confine ourselves to the loftier goals of your education.”

I took Rorty’s class in critical theory, of course, as we all did in one way or another. I admired his entirely unflappable manner (the most stinging attack from a student was usually met with a shrug and a smile followed by a more or less brilliant response). Rorty’s signature move in a lecture was to confess that he “didn’t understand” an essay by Cixous or Jameson (I’ve tried to cultivate that same honesty with my students, though unlike Rorty, my lack of understanding is usually quite real). I especially loved his willingness to throw down the intellectual gauntlet. One of my most frequent experiences in grad school involved sitting in a seminar with the world’s leading authority on a subject and having that person “lead discussion” among a bunch of grad students who (understandably) didn’t know a blessed thing about it. Rorty told us on the first day that he was there to urge a particular viewpoint on us, that he would be marshaling various texts in his defense, and that we should fight back. We did. It was education at its best.

I suspect few of Rorty’s students were converted to American Pragmatism, but anyone who went through the English Ph.D. program at UVA during the years he was there, and took the “theory course” from Rorty, came away with certain ideas that I think tend to distinguish us as a group. Most of us came to graduate school wanting to separate the wheat from the chaff. We wanted to say that authorial intention was wrongheaded, that Foucault was right and Fish wrong (or vice versa), that there were good and bad theories of gender – and that there was a way to be “current” in your thinking about contemporary critical theory. Rorty knew that this is what we were trying to do, and didn’t disapprove, but his real beef was with the idea that any one of them should act as a normative principle for interpretation. Authorial intention is a useful thing in some instances (I remember him saying, to everyone’s dismay, “One hopes that there are always people around trying to reconstruct the content of an author’s consciousness”). And so is Derridean skepticism. It’s also okay to think that one gender critic is better than another, so long as we are clear about what “better” means.

We were taking a theory class from a great expert on the subject, who, to our astonishment, seemed to be telling us to go back and get on with the business of interpreting literature (with whatever tools make the most sense). Even the most hard-core “theory heads” seemed to soften after making their way through the Rorty boot camp. It was okay to pursue high falutin’ theories of gender construction; it was also okay to devote your life to the textual recension of Piers Plowman. Nothing like a properly ramified episteme.

Richard Rorty leaves behind a vast corpus of books and essays that are among the finest philosophical works of the twentieth century. He also leaves behind a generation of scholars who are far less tedious and doctrinaire than they might have been had they not passed, however briefly, under his powerful influence. It’s sad to think that he won’t be around to keep it real for the next generation.

MONK Project Website

2007-05-04T00:00:00-05:00

I’m pleased to announce that the project website for MONK is now up and running.

Not much in the way of content just yet, but watch that space.

Beautiful Code

2007-04-15T00:00:00-05:00

Non-programmers are often bemused to hear programmers speak of beauty and elegance in code. It’s a strangely ineffable assignation, yet one that every serious programmer can make. Some pieces of code are not just utile, but dulci. And nothing thrills the heart of an engineer like the moment of beauty.

Paul Graham offers a code example in his book On Lisp (out of print but available on line) that strikes me this way. It’s just a tiny little “counter” procedure:

(defun make-adder (n)
  #’(lambda (x) (+ x n)))

This function takes a number, but instead of returning an incremented value, it returns a closure that will add that number to any subsequent function call. Hence:

(setq add2 (make-adder 2)
  add10 (make-adder 10))
(funcall add2 5)
7
(funcall add10 3)
13

Graham calls this an example of a “utility function,” but I must admit that when I first saw it, my reaction wasn’t “Wow, what a useful thing!” or “Ah, now I understand how lexical closures work!” My reaction was simply, “Good heavens, that’s gorgeous.”

But why? Perhaps it’s some convergence between beauty and cleverness. Cleverness isn’t always a virtue in programming (particularly since such moments often exchange clarity for concision), but sometimes things manage to be both clever and beautiful – clever because they’re beautiful, and beautiful because they’re clever. And “cleverness” is often (though not always) a component of art. The Mona Lisa exudes a kind ineffable cleverness, as does the astonishing photorealism of Old Masters paintings, and in both cases, it’s not merely craft that produces this sensation.

Beauty in code is not a function of utility at all (though the two often accompany one another). This code sample (found both in Sitaram’s Teach Yourself Scheme in Fixnum Days and Dybvig’s The Scheme Programming Language) also strikes me as beautiful. It’s a set of recursive co-routines for deciding whether a number is even or odd:

(define is-even?
  (lambda (n)
    (if (= n 0) #t
      (is-odd? (- n 1)))))

(define is-odd?
  (lambda (n)
    (if (= n 0) #f
      (is-even? (- n 1)))))

These co-routines pass the number back and forth; you get your answer, because the function that returns the answer will be the last procedure called – the last player with the football, as it were.

In one sense, the code is perfectly practical, since it’s prefatory to a discussion of letrec – a variety of conditional that allows you to assign local variables recursively. But in another sense, it’s entirely silly. Scheme, after all, provides both odd? procedures. But ah, what a beautiful piece of code. It’s not, “Wow, isn’t Lisp great!” or “Ah, now I understand letrec!” It’s just “What a beautiful piece of code.” For me, at least.

Hand a geek a pocket watch, and he or she will immediately open up the back and stare at the mechanism for an hour. And if you could persuade that person to speak out loud, they’d be saying things like, “Look at that! And that! Wow, that’s just … beautiful!” And that really is something like an aesthetic experience that is in a way indistinguishable from the experience of art.

I don’t mean to argue that Lisp is inherently beautiful; the examples are in Lisp because that’s my current obsession, and I’m reading a lot of Lisp code these days. In fact, I think what I’m talking about here transcends language. It’s certainly not a matter of syntax. One could easily imagine beautiful C, Java, or Fortran. I had certainly seen lots of examples of beautiful code before I knew anything at all about Lisp.

Got some beautiful code (in any language)? I’d love to hear about it.

Chicken!

2007-03-31T00:00:00-05:00

What can I say? The Greatest Language Ever and the Greatest Language Possible are both doomed propositions. The former ignores the infinite variation of use cases, platforms, coding styles, and the sociology of individuals and groups. The latter does all of that and goes still further by arbitrarily choosing language features for which the “best” is likely to be a highly debatable matter. Like all good philosophical questions, these one’s don’t have concrete answers. We pose them not to arrive somewhere, but to stimulate thought and further innovation.

But Lisp is still the Greatest Language Ever.

I only learned Lisp a couple of years ago. I’m not sure how I got there, really. I think I might have stumbled on one of Paul Graham’s essays (perhaps from a Slashdot interview Kent Pitman gave some time ago). I was thoroughly intrigued by what Graham had to say, and decided to give it a shot. That, of course, led me into the Scheme vs. Common Lisp debate, as well as to the question of which implementation to use.

I think it took me about an hour to decide against Scheme. Nearly everything I read about it suggested that it was a highly minimalistic version of Lisp intended for introductory computer science courses and ponderous experiments in the study of languages and algorithms. In other words, it wasn’t meant for serious application development at all. In fact, the very first Q from the Scheme FAQ sealed it:

Scheme is often used in computer science curricula and programming language research, due to its ability to represent many programming abstractions with its simple primitives. Common Lisp is often used for real world programming because of its large library of utility functions, a standard object-oriented programming facility (CLOS), and a sophisticated condition handling system.

So (I concluded), if you want to build real apps you want Common Lisp. I ended up going with SBCL (which is a fantastic implementation). I also read Peter Seibel’s book, which is really sensational.

I started this recent series of blog posts, because I wanted to talk about why I’m both dazzled and frustrated by certain aspects of Common Lisp. None of my objections involved the language itself (I’m not even sure I follow some of the critiques of CL that show up on the newsgroups). My problems were the garden variety ones. CL folks use Emacs/Slime. I use Vim (which has very weak support for IDE-style development with Lisp). And anyway, I hate IDEs. I want the compiler to compile (or the interpreter to interpret), the debugger to debug, the editor to edit, and I want to switch tools whenever I want. I also don’t want anything abstracting me away from the details of the tools themselves. That’s just me, but there it is.

I loved having a REPL, but I hated having just a REPL, and while it’s possible to get SBCL to work with a shebang, it involves a lot of hacking of configuration files. Package installation was often complex and tedious, and the library I was looking for usually wasn’t available (or if it was, it had absolutely no documentation whatsoever). I fully understood the arguments about why it’s hard to create standalone “binaries” for CL, but I wondered why there wasn’t something like a Java jar file – some easy way to launch an app with minimal fuss.

As I’ve said before, there is a way to do all of this if you’re patient. But when you read the posts about these matters, you witness a very peculiar rhetorical trend. Someone posts asking about, say, how you go about creating an “executable” with Clisp or SBCL. Someone might respond with a howto, but the person asking is much more likely to get a sermon about how they need to free their mind. They’re told about how the line between development and use is blurred in Lisp, about how “standalone programs” are actually a myth, since the operating system ships with the C runtime and is therefore providing you with mountains of scaffolding (no different from Lisp!). They’re told that the REPL is a perfectly legitimate “shell” for ordinary users. And anyway, the UNIX shell is a horrific hack from which we should all attempt to extricate ourselves. In fact, it’s really much better to have Lisp insulated from the fallen world of shells, C libraries, conventional interfaces, etc. You just need to embrace the Lambda Nature.

Yeah. Whatever.

I get it! I really do. I understand these arguments. In fact, some of my objections are completely unfair (No documentation? No libraries? Well surely you can do something about that!). Other points are absolutely dead on (like the one about the C runtime). It’s just that I’m trying to get my work done and make my users happy. They will not be happy if they have to fiddle with the common-lisp-controller, set up aliases for asdf, recompile fasls, and then learn Lisp syntax so they can use my program. And I’m going to be unhappy if I have to wade through source code for lack of documentation, struggle with the FFI, and spend an hour setting up my system so I can use a particular package. It may be – in fact it is – the Best Language Ever. But it’s not the Best Userspace Tool Ever. Not by a long mile.

So I started looking around for other Lisp alternatives, and this led me to a long, second look at Scheme.

I discovered that the opening salvo of the FAQ is absolutely true. It is a very small language, and is therefore ideal for teaching and language research. But what the FAQ was leaving out, I think, is the startling implications of a language that is trivially easy to implement (relatively speaking). If you’re going to implement CL, you better lock and load. It’s going to be a major job. Scheme? Well that’s a different story.

The fact that Scheme is easy to implement has led to dozens and dozens of implementations. Some of them are “pure,” in the sense that they provide the core language and don’t concern themselves with OS integration. That’s perfect if you’re teaching Lisp. But what if you want to target the JVM (“for shame!” say the CL folks)? Or compile to C? Or run it on a Palm? Or use it as a systems programming language? Or embed it in another program? Or embed it in another programming language? Or put in on a cell phone? Or use it as the scripting language for your editor?

And we can go further. What about a Scheme that is designed to work seamlessly with UNIX? Or a Scheme that makes it trivially easy to call native libraries? Or a Scheme that can be used as a shell? Or a scheme that acts like an ordinary “scripting language?”

What I discovered, is that there are Scheme implementations for all of that. They’re all Scheme (and therefore all Lisp), but none of them try to be all things to all users (or worse, impose philosophical restrictions on how the language is used).

Imagine my delight when I stumbled across Chicken Scheme (one of several that try to fill in a particular programming niche). This is a Scheme implementation that compiles to C (using a very clever method), which means that you can very easily create the elusive “executable” with a single command, and it will behave like any other native app. Its package system is brainlessly easy to use, and it has lots of libraries to do good-old-fashioned every day stuff (talk to databases, munge XML, export to CSV, etc.). In fact, it really feels like Ruby or Perl or Python. But it’s fast! And it’s Lisp!

That was enough to make me fall in love, but my real moment of epiphany came when I discovered Easyffi.

All of the CL implementations allow you call native functions through a foreign function interface. I read over some of the specifications for doing that (CFFI and UFFI). “Yeah, it’s doable,” I thought, “But it’s going to require some serious effort.”

Here’s how you call native C libraries from Chicken using Easyffi:

You reference the C header in your source file.
You call the native function (in Scheme).

Sorry, did I miss something? I mean, it’s a little more complicated than that, but not much. I sat down to write an interface to the native GraphViz library. I had it working in about a half an hour.

The mind reels. I’m speechless. So, I can just create interfaces to any C library I want (making them as Lispy as I care to with macros and whatnot)? Just by calling them? And then I can compile the programs that call those interfaces into fast C code that will behave like an ordinary POSIX program?

And I can do all this in the Greatest Language Ever!?

I’m a convert. I’ve known for awhile that Lisp is the red pill. Now it seems that, for me at least, Chicken Scheme (and Scheme in general) might be the little blue one.

The Greatest Language Possible

2007-03-24T00:00:00-05:00

I ended my last post, The Greatest Language Ever, with a personal conundrum. Why is it that, given a project for which the choice of language was not influenced by extraneous factors, did I choose Ruby rather than Lisp?

Anyone who has lingered around the Lisp community would probably be able to see the answer coming: lack of libraries, no easy way to get a standalone binary, not enough momentum behind the language, the loneliness of being the only hacker in sight using Lisp, lack of integration with POSIX, etc., etc. And the Lisp fans have various answers prepared for all of these. If you go over to comp.lang.lisp and search for the keywords in the last sentence, you can see the whole battle. In fact, you can peruse at least a decade’s worth of the same questions and answers going back and forth.

The short answer is usually that Common Lisp does all of these things. In other words, there are many excellent libraries, you can create standalone programs, Lisp is going to undergo a great resurgence any day now (have you read Peter Seibel’s excellent book? It won a Jolt Award!), and you can integrate with POSIX. But the situation – my situation and the situation of many others – is more complicated than that. In fact, I think both sides are right.

But rather than pick through the claims and counterclaims, let me step back for a moment and talk about The Greatest Language Possible.

If the Greatest Language Ever is a ridiculous notion (for the reasons outlined in my previous post), the Greatest Language Possible is even more so. Yet in a way, the idea is even more irresistible. Frederick Brooks was right to note, in The Mythical Man-Month, that programmers are optimists. We will vastly underestimate the time it takes to do something, naively declare things to be easy or even “trivial” to implement, and generally approach most problems, to our extreme peril, with a can-do attitude. When we talk about dream languages, we’re really expressing a longing for the perfect tool – the one that really would make everything easy and trivial.

I mentioned that my favorite languages are C, Ruby, and Lisp, and I think my perfect language would blend all three.

A few years ago, I posted the following on Slashdot. It was essentially a response to a critique of C:

You know, I never hear anyone disagree with the type of thing you’re saying here. It’s unsafe, there’s no garbage collection, the pointer abstraction is confusing, the macro system is terrible, it’s just high level assembler, etc., etc.

But there are lots and lots and lots of people who code Linux programs in C – the vast majority of the programs I come across, at any rate. These people surely aren’t being coerced into it by some manager. I assume that

most of

the people writing sophisticated software are multilingual (hard to get to get really good without learning at least half a dozen languages, in my > opinion). They surely all know about OO, templates, assertions, abstract classes, and whatever other language features are out there.

It’s like the biggest silent majority in computing. All these people merrily hacking away in C without complaint.

I would like to hear someone talk about why they like to code in C. I’m not asking for a language war. I would just like to hear from this silent majority.

The first response back said it all:

C is for people who understand how computers work, and how they work best, and who can’t or won’t accept “easier” or “faster” (to develop in) programming languages just because they won’t always generate the best code.

Now, them are fightin’ words, for sure, but I think I agree. I am one of those who has been merrily hacking away in C (nothing big, just stuff for my own system) for years without a complaint. And I think I love it because of its primitive nature. There’s something about programming on the metal – thinking about memory usage, imagining the content of the registers, breaking open every black box – that is appealing in some basic way. But there’s also the practical matter of being a UNIX programmer. C is the common tongue of UNIX. And it’s fast. Really, really fast.

Ruby is a joy for exactly the opposite reason. It keeps you blissfully unaware of the details. There are even times when you feel like you’re speaking English to the computer. It’s elegant, “fast enough” in most cases, and there are lots and lots of libraries that make it easy to talk to native C interfaces. In a way, I always want the library to be in C, but at the same time, I always want to call the library in Ruby. It’s even pretty Lispy, as non-Lisp languages go, and includes some direct borrowings (though, as an aside, I find it interesting that I rarely use lambda functions when writing Ruby, and I think it’s because the Algol-like syntax doesn’t lend itself to this kind of expression. The parentheses in Lisp aren’t just there for decoration.)

And then there’s Lisp. So elegant and expressive, so much fun to write. Half the time, I don’t know whether to laugh or cry.

Somewhere in here is my ideal. Not my metaphysical pronouncement on languages, but the tool I wish I had at my disposal. It’s as fast as C, yet as high as Ruby. It speaks UNIX effortlessly, and it’s trivial (there’s that word again!) to call native libraries from it. It has a vast library (perhaps as a function of it being so tightly integrated with C), and it’s reasonably portable. Oh, and it’s also a Lisp.

I chose Ruby over the Greatest Language Ever for the recent project not because of any show-stopping defect in the Lisp implementations or overwhelming virtue in Ruby, but because you have to weigh a complex set of factors for the particular problem and hope for the best. Lisp has the language, but Ruby has the libraries. It would be possible to hook Lisp into the libraries, but that’s a complicated matter, and it would constitute a clear case of overengineering just to get some proof-of-concept code working. Writing those libraries would be the patriotic thing to do, but Lisp’s FFIs are complicated and I don’t have time to do it. None of this is the fault of Lisp, Lisp’s implementors, Lisp’s advocates, Lisp’s community, or anything else. It’s just a hacker on a deadline.

But did I mention that I think I’ve found an implementation of Lisp that does all the things I’ve been talking about? Could it be the dream language?

Be still my beating heart. Next post.

The Greatest Language Ever

2007-03-17T00:00:00-05:00

Over the years, I’ve managed to learn a number of different programming languages. I’m not an expert in all of the languages to which I’ve been exposed, but I’ve written at least one nontrivial program (and in most cases, several such programs) in C, C++, Perl, Python, Java, PHP, Common Lisp, Scheme, Prolog, and Ruby. Broaden the definition slightly, and I suppose you could also include Bash, Awk, and SQL.

There are a lot of factors involved when making a decision about which language to use for a particular project, and very few of them have to do with a language being the “best language” as such. C is an excellent language for writing mouse drivers; it’s probably not the best choice for AI. Java is a miserable language for writing operating systems; it’s quite a good choice for server-side web applications. But of course, even that is a largely subjective matter. Plenty of people do low-level systems programming (of sorts) in Java, write GUI applications in C, and do AI with PHP (okay, maybe not). And anyway, this isn’t even the biggest factor. You pick a language because your “group” (your company, your project, your school) uses that language, because it’s the one you know best (or the only one you know), because there’s a fantastic library available for that language that fits perfectly with what you want to do, and so forth.

The question of which language is best is also full of minor religious questions. Static typing or dynamic typing? Interpreted or compiled? Object oriented? Functional? Procedural? Garbage collected? Since it is provably possible to write anything computationally tractable in any language, one finds oneself reduced to a balanced tri-fold truism about programming languages:

All languages (approaches to compilation, syntax, etc.) have advantages and disadvantages
The “best language” is likely to be the one that is most suited to the particular task at hand
Javascript is the worst language ever

But really, that’s no fun at all. It may be true that questions about which language is best are mostly subjective, but if you write software for a living, your own likes and dislikes begin to seem like truisms themselves. Surely the cabinetmaker doesn’t need to justify her love of a particular hand plane?

Of all the languages on my list, there are three that I genuinely love: C, Ruby, and Lisp. And the greatest of these is Lisp. In fact, I’ll just say it: Lisp is the Greatest Language Ever. Period.

The reasons why Lisp is the Ultimate Language have been eloquently expressed elsewhere, so I won’t rehearse the technical merits of the language (particularly since, as I just noted, such rehearsals are futile). I will say, though, that it radically changed the way I think about programming (in any language).

My experience with Lisp was something akin to my father’s experience with Wagner several years ago. He had been listening to opera for many years, owned a vast collection, and had become quite an “expert listener,” but hadn’t purchased any Wagner. So he bought a copy of Das Rheingold. He tried to like it, but the first few listens left him cold. In fact, he really thought it was awful (despite the fact that many of his fellow opera afficianados consider it possibly The Greatest Opera Ever written). After awhile, though, he found that several passages were beginning to grow on him. In fact, he started to really like Das Rheingold. So, he bought the second one (Die Walküre).Same thing. Sounded like noise.

By the time he finished, he told me that he had to put away Der Ring des Nibelungenbecause, as he put it, “It was making the rest of my opera collection look amateurish. It’s truly the greatest opera ever.”

My experience learning Lisp and coding a few serious programs in it was deeply profound. Afterward, most of the other languages I had been using regularly seemed silly and inane. I found myself saying things like, ”I’ve spent an hour on this method, and I know I could knock it off in three lines of perfectly elegant Lisp!” And what I was lacking in those languages was a whole host of programming constructs I had either never heard of or only dimly understood before learning Lisp. Passing a function into a function? Why would you ever want to do that! You wouldn’t. Unless you got seriously into Lisp, in which case you find yourself (a) doing it all the time and (b) writing much more elegant, expressive code as a result. Same goes for closures, continuations, anonymous functions, and macros.

Macros, in particular, might be the most dazzling thing I’ve ever seen in programming.

Programming is all about “extending the language.” Any language will have hundreds of built-in functions, and when you write an application, you are essentially using those functions to write new ones for your own application. But there are major limits to this. You might be able to write a function called “read_data_stream()” or “sort_pyramid(),” but you can’t extend the language at more fundamental levels. You can’t, for example, write your own if-then-else block or for-loop (and have it work like a part of the language itself). In Lisp, you can – and you find yourself doing it effortlessly after awhile. In fact, you find yourself using Lisp to write the programming language you wish existed for your particular problem. And with Lisp, that is a thousand times easier than it sounds. Do that for a few weeks, and all the other languages will seem like crude stone tools.

I’ve spent the last week or so writing in Ruby. It’s a wonderful language. It’s a joy to program in it, and I’m almost always trying to find ways to overcome the various reasons not to (“that’s not the language of the project,” “there aren’t enough libraries,” etc.). I know it like the back of my hand, and I teach the language every year. It even has a number of Lispy constructs (like closures, continuations, and anonymous functions). But it ain’t no Lisp. In fact, the only way it could be as good as Lisp would be for it to be a Lisp dialect (which it is not).

But last week, I was writing proof-of-concept code. There was no one telling me what language to use, no “audience” for the code, and there were good, serviceable libraries available for Common Lisp, Ruby, Java, Python and Perl. I went with Ruby.

The question, of course, is why not write it in The Greatest Language Ever?

Well, that’s a separate rant, which I’ll save for another post.

Video Nostalgia

2007-02-08T00:00:00-06:00

I will be adding nothing new to the blogosphere by mentioning this fantastic video by Michael Wesch, which has been careening around the Web faster than a dancing baby.

But I must ask: Does anyone else feel a wave of nostalgia watching this?

As a guide to what’s new and cool in the world of web development, it seems to me a little too exuberant regarding something that really isn’t all that new or revolutionary. If you’re at all involved with Web development, “Web 2.0” is by now pretty old news.

But the video instantly takes me back to something like 1996 when I used to give presentations that sort of looked like this (and I could use terms like “radically decentered” in a talk on hypertext without laughing). Combine that with the earnest techno, the low-tech/live-tech look-and-feel, the “not since Gutenberg” evangelism – I’m just so filled with longing for the days when all that seemed just so cool and exciting.

It’s all still cool, of course. In fact, it’s probably cooler, given that the technical revolution we’re seeing online (full-fledged applications of the sort we could only dream about back in ‘96) are truly revolutionary. But it’s just not the same. Back in the mid-nineties, we looked at the Web (which was appallingly primitive by today’s standards) and thought, “This changes Everything.” Web 2.0 also changes everything, but not, you know, Everything. The first revolution was sudden. This one is more an evolutionary development to which we all easily and gleefully adapt. Back then, I was frequently asked by bemused audiences of my dev-angelical preaching whether I still liked books. Nowadays, no one would bother to ask such a silly question, because “doing literary studies with computers” doesn’t really seem all that weird any more.

Ah, the good old days … you know, like, ten years ago.

Comical Ruby

2007-02-05T00:00:00-06:00

I was an extremely early adopter of the Ruby programming language. In fact, I’m pretty sure I own one of the first printings of the first pickaxe book. There’s even evidence to suggest that I was one of the first people to teach a course in Ruby at the college level. I’m not often so ahead of the curve, but there it is. I was way into Ruby way before it became fashionable.

And yet, somehow I managed to miss why’s (poignant) guide to Ruby – an online tutorial on Ruby that comes close to being a graphic novel.

Thanks to Brett Barney of CDRH for pointing this out. He is obviously way, way, way ahead of the curve.

PDF goes ISO

2007-01-29T00:00:00-06:00

Slashdot reports this morning that PDF is being submitted as an ISO standard. Of course, PDF is a de facto open standard – I have literally dozens of open source implementations of PDF tools (including such amazing apps as pdftk, without which my life would be meaningless), and none of them would have been possible without the open format.

But having PDF be a de jure standard is very good news, as far as I’m concerned. I love PDF, because my favorite way to create documents is to typeset them lovingly in LaTeX, export to Postscript, and then export to PDF (I have not willingly used a word processor in over ten years).

If PDF is approved as an ISO standard, it will mean that the standards zealots among my circle of friends (yes, these are the kinds of friends I have) might back off and not insist that absolutely everything be in XML.

I’m not knocking XML, mind you. I drank the Kool-Aid on that one years ago. But when it comes to creating beautiful documents for people to read, LaTeX/Postscript/PDF is hard to beat.

Text Analysis in the Wild

2007-01-26T00:00:00-06:00

This article has been making its way through the text-analysis episteme over the last few days. The article itself is unremarkable (it’s just a rundown of President Bush’s remarks on energy policy during Tuesday’s State of the Union Address). But if you scroll down a bit, you’ll see a clever set of balloons showing how frequently various keywords were mentioned. Enter a term in the search box, and you get a more elaborate version.

It’s a lovely interface, and it’s actually quite interesting to play with. I wonder, though, why this particular technique is so much more interesting with ordinary expository prose (and, in particular, political prose) than it is with, say, literary texts. I’ve done similar things with various novels and poems, and they always seem to me far less enlightening than one might expect. I will say, though, that the techique does become interesting when you begin to do this with all of, say, Jane Austen’s novels. Then things begin to shake out.

Of course, we all know that the authors of political speeches (particularly speeches with as much moment as the State of the Union) pay very close attention to which keywords are used, how often, and when – almost performing a kind of reverse text analysis, which is in turn immediately analyzed with applause meters and so forth. This also seems to me to be one of the few contexts in which the colorized indication of “where” a keyword occurred becomes useful. Past attempts to do this with literary texts have produced nothing other than mildly interesting eye candy.

I hope the New York Times continues doing this sort of thing. In fact, I hope they eventually adopt nora and start making it a normal part of the online reading experience. We shall see.

Syllabus Now Available

2007-01-07T00:00:00-06:00

The syllabus for ENGL 8/478: Electronic Texts is now available

ENGL 4/878: Electronic Texts

2007-01-04T00:00:00-06:00

I’ll be teaching digital humanities at UNL this semester. Here’s the course description:

This course is a broad introduction to the use of computers in humanistic study. We will survey the field of humanities computing from computational analysis of style to meditations on the cultural impact of computing in scholarly research and publishing. We will also study several specific technologies in detail – web technologies, the UNIX operating system, and relational database design – with an eye toward becoming proficient creators of digital scholarship.

As I usually say on the first day of this course, “The bad news is that this course is hard. The good news is that I’m a sweetheart and I’ll do just about anything to help you learn the material.”

Why is the course hard? Mostly because it demands a style of studying and learning different from that to which most humanities students have become accustomed. The technical portions of the class demand some attention to detail, a willingness to experiment, and a certain calmness in the face of frustration. It does not demand any kind of innate technical acumen or anything of that sort. I have lost track of the number of students who came to college or grad. school in open flight from anything resembling an engineering discipline who discovered in this course that they are exceedingly “good at computers” – including very technical aspects of the subject. Some have even gone on to specialize in digital humanities.

Why is the professor a sweetheart? Well, mostly because I am a student of the humanities. And despite all the geek cred, I still believe that digital literary study is more about literary study than digital anything. I well remember sweating my way through all of this when I started out in the field, and I have a very good handle on where students get tripped up. I also firmly believe that in our wired world, it’s essential that we all gain some control over the technology that increasingly pervades our lives. It gives me great joy to usher students across the boundary separating users of technology from builders and developers, because with that transformation comes an enormous level of empowerment. Being able to fix your car when it breaks down is a tremendous skill to have. Being able to bend computers to your will is even more so, since here we’re dealing with information technology – a medium of thought and communication as vital to the transmission of ideas as the ability to use a pen.

I therefore have every intention of raising an army of hacker/scholars at UNL.