Stephen Ramsay

Syndicate content
literatura mundana
Updated: 6 years 39 weeks ago

Digital Campus 69

Thu, 19/05/2011 - 20:23

I was very pleased to join Dan Cohen, Tom Scheinfeldt, Mills Kelly, and (for the first time!) Amanda French for Episode 69 of Digital Campus: “Strange Bedfellows.”

Reading Machines: Toward an Actual Publication Date

Thu, 05/05/2011 - 20:40

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 ( 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

Sat, 09/04/2011 - 19:49

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 pairing 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 . . .


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:

1. 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.

2. 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 switch 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 return 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.

Crossword Data

Sun, 20/03/2011 - 15:48

Day of DH 2011

Fri, 18/03/2011 - 05:08

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

Oh, and so is everybody else.