I’m an emacs girl: emacs is the environment that taught me to love Lisp, emacs is most of the way to becoming an extension of my desires, emacs is in Neal Stephenson’s memorable phrase “the thermonuclear text editor.” Like everyone else who’s smitten with it, I have a theory about What Makes Emacs Different: emacs is a paradigm, not a program.

Let’s talk about interfaces. In 1976, using computers was harder— not because people were dumber or worse at design, but because there were fewer giants on whose shoulders to stand and because the computers themselves were incapable of working as hard. That meant, in turn, that the 1976 OS couldn’t be as generous to user-space programs as the 2013 OS can be. In 2013, the OS can step up and be the primary answerer of the question, “how do I use this computer?” In 1976, the OS is too busy running the computer to do more than nod in the Bourne shell’s direction. This has considerable downsides for programs: they have to do everything themselves. But they have one important freedom: they get to answer the user’s fundamental “how do I use this computer?” question any way they want.

In 2013, the OS has an answer to this question, more or less opinionated according to the OS. Because it is easier to let the OS answer the question, that’s what most programs do: they use the OS’s chrome, file management, and other facilities. There are many good things about this: there are many more useful programs in the world than when programs had to do everything themselves. But it is a tradeoff: a program that comes from the world where the OS provides easy answers is almost completely unable to provide its own answers.

This is where we come back to emacs: the reason that emacs can look so strange in 2013 is that it has its own opinions, strong ones, about how to relate to files, displays, and text. Emacs is a paradigm for how to interact with text. It has stronger opinions than modern programs because it comes from a time when programs had the ability to answer those questions themselves. A program from the strong-OS era— for example, Eclipse— or which adapted itself to strong OSes— for example, Microsoft Word— is restricted by being situated within the boundaries established the by the OS' answer to “how do I use this computer?” Eclipse and Word are programs that edit text. Emacs is a language for editing text.

One of the clearest ways to see this is to compare emacs to something that’s more similar to it than Eclipse or Word: vi. With its movement-operation-modifier syntax for commands, vi has its own answer to the question “how do I use this computer?” that’s every bit as thorny for us 2013 folks as emacs' answer— and that’s just as powerful when you grok it deeply. In the context of their 1976 roots, you can see that the creators of both vi and emacs embarked on the tremendously ambitious project of giving users a language in which to edit text. The existence and popularity of software that’s pushing 40 years old and still being actively used and extended, is strong evidence that both did well (though we should check our survivorship bias and note that most programs from that era did not survive in the same way).

If you are someone who spends a lot of time with text, especially if you’re a hacker, you should be using emacs or vi. There are many okay and good tools for editing text and producing code, especially for specific domains, but emacs and vi are the only great general-purpose editors. A program that wants to take advantage of the benefits that a modern OS offers could possibly be great— but it would have to be a different route to greatness than emacs and vi took.

I spend a tremendous amount of time with prose and code, and emacs is a great match for me. For a large class of problems, my response to encountering them starts with M-:. I routinely try to use emacs' keyboard shortcuts in other contexts (e.g. switching tabs in Firefox with C-x o). I was actively excited when I found out that emacs had integrated a unit testing framework. When I tell you that you should use emacs, you should know that that’s the kind of relationship I have with emacs. I think you should use emacs anyhow, because I think that when a task is important to you, you should use a great tool for it, not just the first good one you find. “How will I use this computer to produce prose and code for the next 20 years?” is a very, very important question to me.

The answer is emacs.