Jacob Kaplan-Moss:

We’re an industry obsessed with automation, with streamlining, with efficiency. One of the foundational texts of our engineering culture, Larry Wall’s virtues of the programmer, includes laziness.

I don’t disagree: being able to offload repetitive tasks to a program is one of the best things about knowing how to code. However, sometimes problems can’t be solved by automation. If you’re willing to embrace the grind you’ll look like a magician.

Over the last few years I’ve realised that there’s a balance to be struck between automating tasks versus manually tackling stuff. For instance, I have rules set up in Hazel, and macros set up in Keyboard Maestro, to perform tasks when I hit a set of keys or apply a tag to some files, and those save me some time and make my life a bit easier. But sometimes I’ll make time to go in and organise files myself, transfer them elsewhere if need be, or delete them if they’re no longer required. And I will still print things out occasionally, for the simple reason that having it on paper beside me makes it easier for me to cross-reference between what’s on there and what’s on the screen.

I’ve also reduced the number of online services that I rely on, because their utility is contingent on an internet connection plus the servers staying up. Neither of those is an absolute certainty. Local resources may not be able to perform all of the magic, but at least if something goes wrong I’m in a position to fix them or find workarounds.

And while I have a lot of respect for the command line, I find the concept of wanting to not have to leave that environment to be almost fetishistic. I’m old enough to remember working at a physical terminal, and that is not a place I want to be 24/7!

Let’s Not Dumb Down the History of Computer Science

An edited transcript of a talk given in 2014 by Donald Knuth (of The Art of Computer Programming fame), where he discusses the paucity of study and analysis of how computers, the software that runs on them, and the development of said software, has progressed over the years.

GIVING THIS TALK might be the greatest mistake in my life, because I’m going to talk about controversial things. I generally go out of my way to avoid argument whenever possible. But I feel so strongly about this that I just have to vent and say it.

Although there is “history” in the title, I’m not going to tell you about the history of computer science. Instead, I’m going to talk about historians of computer science–about historiography. This is meta-history. I’m going to try to explain why I love to read works on history, and why I’m profoundly disturbed by recent trends in what I’ve been reading.

Knuth gives examples of the gaps that exist in our knowledge of this history, and offers up suggestions of where to look for the information to plug those gaps.

There are many wonderful algorithms and source codes whose histories are completely untouched. If we technicians can study and explain them in depth, then historians will at least have material to which they can later add the breadth.