There is an interesting dichotomy in the tech world: innovation is constant, yet there are widely used technologies that bear a strong resemblance to what developers were working with thirty or forty years ago. We still have sed and awk. Fortran is still used for some purposes. We still use terminal emulators based on the actual teletype terminals manufactured during the seventies. Despite the unrelenting pace of change, there is a certain set of tools which have survived decades of technological churn in some recognizable form.
There is something to the idea that the longer something has managed to stick around, the longer it is likely to stick around in the future. While you can barely get through a week in today’s world without having to learn a new JavaScript library, there are some technologies that do what they do so well that novice developers come to depend on them just as their predecessors did. It seems like it would be hard to get excited about implementing a better ls when the ls we have lists files well enough, and that’s all we need it to do.
Two programs which have this quality of staying power, and which will be the main subject of this post, are Emacs and Vim. (For the remainder of this post, when I write Emacs and Vim I will be referring to the most widely used versions of both, although there are many alternative implementations, both recent and historical.)
Not Like the Others
Emacs and Vim are programs with a lot of personality. They’re unique. Not like the other programs.
Despite the pace of technological change, there are times when sticking with what you know—and what the majority of computer literate people at this point in history know—is a good idea. This is especially true when it comes to user interaction, as what the user wants, generally speaking, is for the thing to just do what they expect it to do; if your intentions are instead to inaugurate a new era of interface design by switching the key strokes they committed to muscle memory years ago, your innovations are unlikely to be appreciated. For example, if the key strokes for cut, copy and paste are different in your application from those the user has used successfully for years, then these basic operations, formerly so familiar as to be almost unconscious, now require effort. Is that extra effort going to be worth it to your users?
Emacs and Vim are two programs that don’t do what you expect them to. They don’t even do cut and paste the way you expect. In fact, they don’t even call it cut and paste, they call it kill and yank, and the keys associated with those actions are different from the standards adopted by various operating systems as well as different from each other.
In the case of these two particular programs, there is a reason for their bucking the status quo: they both come down to us from a time when many of the current conventions about computer interaction, many of the assumptions about how a program should react to user input, had not yet solidified. This was a time when the authors of new programs were serving small user communities, such as at universities with electrical engineering departments lucky enough to get their hands on a computer, and had to work within the limitations of early computing machinery. The solutions they came up with were shaped by that context and its constraints, and it is a testament to their creativity that these programs are still in use today.
So what is so special about these programs, that they have made the long journey from their first implementation to current-day incarnation, despite the high learning curve demanded by their unconventional interfaces?
Programmers and Their Editors
Because software is code and code is text, programmers spend a lot of time inside their text editors. We spend so much time that our editor becomes something like an extension of ourselves. There will always be irksome technologies that you as a developer just have to deal with, but if your editor makes writing code feel like walking uphill with weights strapped to your ankles, the negative impact to your quality of life may make you despair for your future.
It is the text editor’s role as basic programming necessity that gives developers the incentive to take the time to learn these programs that at first seem odd and antiquated. I do think that Vim and Emacs are worth the time required to learn them, although at first you will have to look at it as an investment into your career that will pay off down the line someday, especially when you first open Emacs and find that something as simple as selecting a section of text doesn’t work the way you thought it would. If you don’t give up then and there and run back to Notepad++, then you are on your way to learning a tool that will not only make you more productive, but expand your conception of what a text editor, or of software in general, can be.
Why Bother?
I’m not averse to using an IDE; they are very useful for large projects that require you to navigate hundreds of thousands of lines of code, launch processes, connect to databases, run tests suites and otherwise try to stay on top of the heap of technologies that we are accustomed to working with today. Nevertheless, I think it worth any serious programmer’s time to learn the classic text editors, if for no other reason then that they are widely available and are either installed or can easily be installed on most OS’s with a package manager. That’s the “if for no other reason” reason, but in fact, there are other reasons to learn them, despite the time it will require.
One reason that is not often discussed is that, coming as they do from an earlier and in some ways very different time in the history of computing, they remind us that many of the conventions that we have become accustomed to are the products of their historical time and place. They are, in a way, living fossils, which remind us that things can and have been different. While we are used to “reptile” referring to something that scurries under a rock when we walk by, it would at one time have meant something that would have us jumping behind the nearest rock were we to see it coming our way. These applications remind us that there are other ways of looking at and accomplishing the tasks that we do with software every day.
What I Like About Emacs
Emacs is one of the most unique pieces of software I’ve ever encountered. There is the long standing joke that it is a great operating system in need of a good editor, and the truth behind this joke is that Emacs is as much a platform as a text editor. Emacs is something like a symbiotic entity composed of an editor and a Lisp environment, where every part of the Lisp interpreter is available to you when writing editor extensions, and all of the power of the editor is available when writing Lisp code. It may be that Emacs is the only piece of software that has ever taken full advantage of the fact that text editors are software for writing software, and that this meta-circularity provides the opportunity for an environment where every editor extension makes it easier to create new extensions. Any IDE of any significant size will come with a plugin architecture, but Emacs goes beyond plugins by exposing many of its own primitives, allowing you to take advantage of them in your own code.
As great as it is, the effort required to learn it makes Emacs an acquired taste. This is partly because it does not follow current conventions, but also because it has its own idiosyncratic conventions that you must make part of your vocabulary in order to understand it. For example, most of the editor commands which are not simply inserting a character start with a prefix key, and they are grouped into sets according to the key that begins them. One of those prefix keys is known as the “Meta” key, a holdover from the Space Cadet keyboard which had more modifier keys than the Shift, Control and Alt that we are used to (the Meta key is mapped to Alt on modern keyboards).
Learning Emacs, at least as an editor, is a matter of learning these key combinations, known as “key-chords.” Learning Emacs as a programming environment, on the other hand, is a matter of learning Emacs Lisp: how to create new major and minor modes, how to use hooks and advice, and all of the other means it provides for making it a more useful tool.
What I Like About Vim
While Vim is scriptable, it is not the programming environment that Emacs is. My experience with Vimscript (admittedly not extensive) indicates that it is much more like a DSL for editing rather than a general purpose language like Emacs Lisp. Rather, the big draw for Vim is the economy of keystrokes made possible by its modal editing paradigm. Vim solves the problem of how to separate editing and character insertion by having separate modes for each set of actions. This means that editing operations like deleting, searching, and replacing text can be done with few keystrokes, at the cost of having to be aware of which mode you are currently in at any moment. The command for moving down two rows in Vim is simply 2n (assuming you are in “normal” mode rather than editing mode).
This is made even more powerful by the ability to build complex commands by composing “nouns” and “verbs”. For example, the composite command “delete the next three words” is carried out with just the characters 3dw, where “d” stands for the verb “delete,” “w” for the noun “word,” while the “3” acts as an “adverb”, indicating that the operations should be repeated 3 times. This ability to carry out multiple actions with just a few keystrokes cuts down significantly on the friction that occurs between typing the keys and viewing the result on the screen.
I have less to say about Vim than Emacs, but this is not because I think the later is superior to the former. They occupy different niches in the space of text editors, and both will stretch your ideas about how editing text can be done.
Concluding Words
I have the feeling that, because these editors are so different, both from each other and from other programs of their kind, being fluent with both of them is something like being multi-lingual. In the same way that a bilingual person (I am unfortunately not) activates one set of encodings at a time, depending on which language they are using, when working in one or the other of these programs you put yourself into a different mode to utilize that editor’s unique way of encoding its commands.
I don’t want to overstate the challenge involved with learning these editors. While it does take practice to reach fluency, this practice can be had in the normal course of using them to write code. Like any complex application, most of what you will actually use on a regular basis can be learned in a few days, and you can pick up the rest as the need arises.
Although I lay no claim to clairvoyance, I suspect that these programs will continue to be around for the rest of my programming career, regardless of what changes are on their way. While part of what I enjoy about this job is the opportunities it provides for learning new things, we don’t get many opportunities to learn something that will stay relevant for the foreseeable future; another reason to make these unique but challenging programs part of your toolbox.