I started reading The Productive Programmer today, and I’ve already, in the first 15 pages or so (including introduction), found some interesting tidbits worth sharing.
One of the first things the author mentions is the idea that having a nomenclature for something makes it more readily discoverable, comprehensible, and reproducible. I’ve never seen it put as succinctly as he does, but it strikes a chord with most of my internal musings about how language mediates and empowers my everyday experiences and work. As I told two of my philosophy professors before leaving RIT: I believe, rather strongly, that my philosophy classes have contributed more to my abilities as a computer scientist than the majority of my computer science courses. In a sense, my philosophy and computer sciences courses were like learning cartography and discovering a map of an island in the middle of the ocean. Give a man a fish and teach a man to fish and all that.
So, words are powerful, and having names for things is an incredible tool. I can’t think of the direct quote, but I know that Steve Yegge (on more than once occasion) has mentioned that the point of Design Patters (Gamma et al) is to provide the language with which to talk about these things. It is harder to see and understand these patterns in your code unless you have something simple to associate it with in your mind – until I learned about the Visitor pattern, I didn’t really understand just how prevalent it was.
Moving on, in very quick succession, he iterated a few truths about using computers that, again, hit close to home. First, that the keyboard is faster than the mouse, and second, that “ease-of-use” and efficient are not often the same.
I want to qualify the keyboard thing really quickly. There are cases where the keyboard is certainly no match for the mouse (or stylus) – say in drawing applications. An article I once read articulated it in terms of bandwidth – when you input bandwidth needs to be high but your output bandwidth can be low, the keyboard is the best way to go. I always think about it combinatorically, often in conjunction with vim, my editor of choice. I can accomplish an incredible number of things in an equally incredibly few keystrokes, and this is because there are a very, very large number of key combinations. Think: number of keys on the keyboard * number of modifier key combinations * number of key presses. Even only considering the letters/numbers/enter/space (+ modifiers) and typing in, say, four keystrokes, we have 38 * 6 * 4 = 912 different actions I can accomplish in four keystrokes. Sure, you couldn’t remember 912 things, but what if those things were made up of more atomic parts?
And it gets even better – interaction with vim is designed in smaller, atomic pieces. “ggVG” is the key combination for select all, but it isn’t really “select all”. What you are saying is:
“gg” – go to beginning of file. gg is the command for “goto line”, and without any numerical arguments, goes to line 1. If you do provide arguments, say, “50gg”, you’ll go to line 50.
“V” – visual line mode – visual modes are kinda like “selection” modes – the selections starts from wherever the cursor was when you entered the mode and goes to wherever you move it once you are in the mode. There are three different visual modes – “v” is visual mode, “V” is visual line mode, and “^V” (control-V) is visual block mode. In visual line mode, which we are going into here, all lines from the start cursor to end cursor are selected.
“G” – go to end of file. G is also “goto line”, except that it defaults to the last line of the file instead of the first.
It might sound complicated (it certainly isn’t easily discoverable or immediately obvious from the interface), but over time, you pick up more and more of these commands. And most learning is more than linear – once I discover that “w” moves me to the next word, I can combine it with most of the commands I already know – “d” means delete, so “dw” says delete to the next word!
Back to the book, the last portion I read was about launchers, like Quicksilver (the ultimate launcher) and a few of the approximations on other platforms. Colibri is one mentioned on Windows that is closest to QS, but it hasn’t seen development in at least a year now. Enso is one of the other ones often mentioned, which always includes the fact that it was started by Aza Raskin, one of the early Mac interface guys. “Oh, it most rock!” (you are supposed to be saying this).
I’ve used Enso in the past, but found that it doesn’t really give me the same thing as QS does (Mac envy here – I don’t have a Mac, but I’ve used QS extensively on the Macs at RIT and on friends’ computers). Every once in awhile, I’ll install it again on my computer, only to feel let down after a few days.
For shits and giggles, I went back to the Humanized website and watched the Enso demo video again. And then almost fell out of my chair laughing (at them, not with them).
The majority of the demo is spent explaining a few things:
- You, as a computer user, do calculations all the time
- It is unbelievable that a calculator is faster to use (at calculating things) than a computer
- With enso, it takes 3 seconds to do a calculation. Without, 30 seconds.
What enso allows you to do is:
- Type in your calculation into some editor control (if you haven’t already)
- Select that calculation
- Hold down “Caps Lock”
- Type “calc” (for calculate)
- Release “Caps Lock”
- Your selection is replaced with the calculated value
And for my next trick, the world without enso:
- Type your calculation into some editor
- Select the calculation
- Press Ctrl+C to copy the calculation (you might already have it in the clipboard, though, so you can skip this step if you do)
- Press Window+R
- Type “calc”
- Press Ctrl+V to paste the calculation (that’s right – you can paste into calculator)
- Press “Enter” to complete the calculation (and you’ll see the result displayed)
- Press Ctrl+C to copy the result (that’s right – you can copy from calculator too!)
- Press Alt+Tab to go back to the last application
- Press Ctrl+V to paste the result
So, yes, it is double the number of steps, but it certainly doesn’t feel that bad. Let’s do a quick timing test. Given, say, 4+(9*5), and starting from step 2 (assuming I’ve already typed it).
Ready? (I’m actually going to do it now, so wait a second to read the next line so that you can experience the drama with me).
6 seconds. I imagine enso would be slightly faster, as it is basically the equivalent of 1-5 in the “without enso” world, but it isn’t 10 times worse, as Aza would have you believe.
In fact, who the hell cares? I can’t even remember the last time I’ve needed to do this, besides to prove that Aza has his head up his ass and in circumstances where I’m already in a spreadsheet applicatoin (like Excel or Google Spreadsheet).
Enso is decent as a launcher, but not any better than, say, Launchy, which is what I’m currently using on my home machine. It also solves the calculator problem in what I think is a bit nicer way – instead of typing in “calc” and having it calculate your selection, you paste (or type) the calculation directly into Launchy and it shows you the answer (this is because Launchy doesn’t care as much about the form of things that get typed in; enso is purely “verb noun”).
The other benefit to Launchy is that it is open source, so you can figure out how it works pretty easily. Also, there is a decent community of plugin developers and good resources on how to make plugins, which means increased value for users.
So, things look good so far for this book. If you have some free time and a few extra dollars, go grab yourself a copy.