Skip to content

Good tools

Published on: April 5, 2013    Categories: Misc, Programming

Apparently we’re in one of those every-couple-of-years cycles of everybody and their brother rushing to adopt/encourage others to adopt the hot new programmers’ text editor. This time around it’s Sublime Text, which, though I haven’t personally tried it out, does seem to at least be a very nice editor. If you were just starting out and needed a quality text editor, I think you could do a lot worse than Sublime Text. However, I would still, and will still, recommend that you also at least try out one of the traditional Unix text editors: Emacs or vi/Vim. And by “try out” I do mean try out — yes, they have learning curves. But make a good-faith effort for, say, a few weeks and see how it goes. Sublime Text will still be there if you decide that’s what you want.

Why do I recommend this? Well, there are a few reasons.

Good tools are investments

I’ve already mentioned that “everybody jump to this hot new editor” is a cycle that seems to repeat every few years. For example, it was not so terribly long ago that the blog posts were all saying “just use TextMate” (and though TextMate was a nice enough editor, and still works, I doubt anyone would seriously write such glowing praise of it today). Now they’re saying “just use Sublime Text”. Now, perhaps it’s not such a bad idea to make wholesale changes to your development process every few years. But — and this is mainly my personal opinion — there’s also a compelling argument for finding something that works, and riding it until you can’t anymore. Good tools give enormous returns in terms of their ability to simplify your work and make you more productive. But a good tool, that you’ve had time to get to know and gain familiarity with, will give you even more.

Good tools, for programmers, are investments: you give them your time and your brain up-front, and then they pay dividends for years on end. I’m writing this post in GNU Emacs inside a terminal window, for example, and GNU Emacs inside a terminal window has been my day-to-day editor for over a decade now. I’ve tried other editors — I own a copy of TextMate, for example, and occasionally use it for simple things — but Emacs is what I always come back to. I’ve invested some time and some memory space, and Emacs has paid me back many, many times over. And, to be honest, I’m nowhere close to being an Emacs master; I still learn interesting new things it can do on occasion, and most of what I know about it is a core set of important functions that I use all the time, plus how to use the help system.

There’s an attitude that tends to develop after that amount of time with a good tool, which can seem condescending or dismissive or even envious of more recent projects’ success. But I don’t think that’s the core of it. To take an example, Sublime Text’s website lists, as the very first feature advertised on the home page, “Goto Anything”, which apparently is a way to quickly (and, bizarrely for OS X, using what appears to be the system-standard keybinding for “Print”, but oh well) jump into a file, or to a specific line or specific symbol within a file, including the ability to complete from a partial name.

Of course Emacs also does this quite well; Emacs’ ability to quickly jump into and around files is something I use the heck out of on a daily basis. And that’s what occurs to me on reading about “Goto Anything”. Not because I’m smugly asserting that Emacs invented this feature, or because I’m annoyed that some other editor is getting advertising mileage out of something that’s not new, but because investing in a good tool is a kind of future-proofing: you will, in time, come to notice that the awesome whiz-bang features of newer tools are essentially the same things you’ve had access to for years now.

This is one of the dividends I’m talking about, but it’s one that may take significant time to become noticeable. Though it’s not the only attitude you’ll pick up…

Good tools give confidence

Closely related to that attitude is something I vividly recall Neal Stephenson once writing about, with respect to learning how Unix works. Here’s a choice quote (from the essay “In the Beginning was the Command Line”, should you want to look it up, and you really should):

This is not the place to try to explain why each of the above directories exists, and what is contained in it. At first it all seems obscure; worse, it seems deliberately obscure. When I started using Linux I was accustomed to being able to create directories wherever I wanted and to give them whatever names struck my fancy. Under Unix you are free to do that, of course (you are free to do anything) but as you gain experience with the system you come to understand that the directories listed above were created for the best of reasons and that your life will be much easier if you follow along (within /home, by the way, you have pretty much unlimited freedom).

After this kind of thing has happened several hundred or thousand times, the hacker understands why Unix is the way it is, and agrees that it wouldn’t be the same any other way. It is this sort of acculturation that gives Unix hackers their confidence in the system, and the attitude of calm, unshakable, annoying superiority captured in the Dilbert cartoon. Windows 95 and MacOS are products, contrived by engineers in the service of specific companies. Unix, by contrast, is not so much a product as it is a painstakingly compiled oral history of the hacker subculture. It is our Gilgamesh epic.

This is largely how I now feel about Emacs. I don’t know how to do everything Emacs can do; I don’t even know everything it can do. But I do know that when I run into a problem that involves editing text, it’s a safe bet someone else had that problem, solved it and left behind some functionality either in Emacs itself or in a bit of Elisp I can grab and use. And even if the way Emacs solves a problem seems weird the first time, usually by the second or third time it starts to click, and — like the Unix novice in the above quote — a little moment of “oh, that’s why it’s this way” occurs.

Best of all, a little bit of knowledge of how to use Emacs’ help system, which is not hard to pick up, makes practically all of this easily discoverable. The net result is that I have a practically unshakable confidence in Emacs at this point. It’s possible that I could get to that feeling with a newer editor like Sublime Text, but I don’t think it’s particularly likely, because…

Good tools are timeless

Emacs is older than I am (and, for that matter, so is vi). Software just doesn’t survive this long, with this kind of popularity, without doing something special. In the case of Emacs, it didn’t stick around because it was pretty to look at; it’s not, though it does have a kind of austere elegance to it that grows on you after a while. It didn’t stick around because it was super easy to use, though by the standards of 1970s programmers’ text editors it was actually pretty good. It is more or less infinitely customizable, but that’s not it either; plenty of infinitely-customizable software now resides in the dustbin of history.

I believe that Emacs has survived as long as it has because, like a few other great pieces of timeless software, it has a big idea. Unix’s big idea, for example, was “everything is a file”, an idea that’s still as useful today as it was forty years ago. Emacs’ big idea is “everything is a buffer”.

A buffer, by way of explanation, is what you are looking at when you look at Emacs. What might be called the “editing pane” in another editor, except it’s an editing pane on steroids. When you’re editing a file, the contents of the file are displayed and manipulated in a buffer. When you give a command to Emacs, you do it in a buffer. When you don’t quite know what file you need, and want a directory listing, you get it in a buffer. When you view Emacs’ documentation, it’s in a buffer. When you customize Emacs… you customize it in a buffer. You can throw anything in a buffer; I’ve got Firefox configured so that “view source” pops into a buffer in my running instance of Emacs, for example, and I compose commit messages in it too. You can have as many buffers as your computer’s available resources can support. You can be looking at multiple buffers at once. Oh, and once you know how to work with a buffer, you know how to work with any buffer, because the core set of “how to do stuff in Emacs” commands work in every buffer.

This is one of those strange-seeming ideas when you first start to encounter it. It’s easy to get annoyed and wonder why Emacs has to be so weird, when everything else managed to implement menus and dialog boxes and those sorts of things years and years ago (you can get Emacs with those, by the way, if you really want them; I just don’t recommend it). But if you stick with it for a while, one of those little “ah-ha” moments happens, and suddenly you go from “wait, everything is a buffer?” to “wait, everything is a buffer!”

There’s more to Emacs than buffers, of course, but that fundamental idea, and the simple fact of being a more or less ruthless implementation of it, is what I think has ultimately given Emacs its longevity. And speaking of longevity…

Good tools grow with you

It is entirely possible, and not uncommon, to outgrow a piece of software you’re using. Most good programmers I know have outgrown at least one or two languages, for example. Usually this happens when the language just can’t keep up with your use cases anymore, though if you’re determined enough you can retrofit pretty much any feature you need into pretty much any language (no guarantees about how nice it will look when you’re done, though; trying to force the square peg of higher-order programming into the round hole of Java, for example, is never going to be pretty).

A truly great piece of software, though, never seems to have those limits. As you grow and learn and start doing more advanced things, it seems to grow with you; often, you’ll discover the feature you never knew you needed right as you find out you need it.

Emacs is like that. When you start out and all you’re doing is writing and maintaining, say, a few little scripts, Emacs does that just fine (and so would any other text editor). You don’t even have to learn very many of Emacs’ own commands, beyond how to open a file and how to save it; you can navigate around with arrow keys (or, in GUI versions of Emacs, with your mouse). But then maybe your files start getting bigger as your code grows; now you discover that Emacs has far more powerful and efficient ways to move around and find things. Then you realize your operating system’s copy/paste functionality just doesn’t do what you need anymore, and you discover the kill ring. Then you start learning how to use the region and apply commands to manipulate whatever precise chunk you need to manipulate. And away you go, with Emacs keeping pace the whole time. After a while, you can make text jump up and dance at your command in ways that look like black magic to anyone watching over your shoulder.

And in the end there really is no limit to what you can do with Emacs. Even if some piece of functionality doesn’t exist yet, you can add it — on the fly — and keep right on going, because Emacs is implemented in the language you use to extend it. There isn’t a “plugin API” in Emacs; there’s just Emacs, with all its functionality exposed to you and to your code, live, all the time. Which means Emacs can always go as far as you can.

And the other stuff

Those are the big, philosophical reasons to give a traditional Unix text editor a chance. And though I’ve been singing the praises of Emacs, vi/Vim in its various incarnations is equally praiseworthy. But there are plenty of other reasons, many of them quite practical. These editors tend to show up everywhere; some form of vi is literally a required component of Unix, for example, and some form of Emacs is never more than a quick package-install away. Tons and tons of things use Emacs’ core keybindings for moving around and doing basic editing tasks.

These editors also have proven staying power, which is an attractive feature given the overhead involved in switching out something as core to your workflow as your text editor. And they run practically anywhere and on anything. Whether it’s your desktop machine, or the Raspberry Pi on your physical desk top, or the phone in your pocket (I have used Emacs on my iPhone; the lack of real keyboard suggests some form of vi would be better there, though), or a server on the other side of the world, these are the editors that can go anywhere and do anything.

So by all means, try out Sublime Text, or whatever takes its place in the next cycle. But also try out Emacs or Vim (both also have the advantage of costing you zero dollars to obtain, which makes it easier), or even both, and give them a real chance. Even if you decide you’re happiest with Sublime Text or some other editor, you’ll come away with knowledge of some incredibly good tools. Maybe someday you’ll come back and pick them up when whatever you’re using at the time just isn’t keeping up with you anymore, And even if you never use them again, you’ll be better off for the experience of having tried and learned.