Why are text editors more popular than IDEs with the engineers in the software industry? by @jeremyhoffman
Answer by Jeremy Hoffman:
This is an excellent observation and an excellent question! It is surprising.
I primarily work in C++ at Google, and my teammates and I all use emacs or vi(m). (I use emacs — the legacy of CS 107 at Stanford.) Here are some reasons I can think of for the widespread use of emacs and vi:
- speed — emacs and vi are bare bones, and as such they never hang. Eclipse hanging is sort of a running joke among the engineers who use it. Also emacs and vi support powerful keyboard shortcuts and commands — once you've used them a number of times, you don't need a menu bar to execute them. I don't know how quickly you can switch to another file and view it side-by-side with the file you're currently viewing, but in emacs, I hit C-x 3 C-x-b start_of_other_buffer_na[tab][enter] pretty fast.
- habit — Most of us picked up emacs and/or vi at some point in our education or careers, got to Google, found official documentation and support for them, and got to work. Call it "inertia" or call it "laziness," but it takes a big improvement in productivity to get a programmer to change his or her tools.
- editing is not the hard part — IDEs make some things easier (auto-completion, auto-refactoring). But I think the hardest part of a Google engineer's job is not the code entry itself — it's deciding which libraries to use, choosing the right algorithm, making decisions about tradeoffs, and designing the data structures to be clear and capable. These are not things that an IDE can even help with.
- customization — Google has added some emacs libraries that perform useful IDE-like functions, and I've picked up enough emacs lisp to write a few functions to tweak some aspect of emacs. For instance, I wrote an elisp function that toggles the frame width from "wide enough for one 80 column file" to "wide enough for two 80 column files" and assigned it to F8.
- non-editor tools — For browsing and understanding existing code, as opposed to editing it, Google engineers have other tools. Likewise for reviewing other people's code changes — we don't do this in emacs or vi. 🙂
- consistent style — The entire Google code base adheres to a rather strict Style Guide. (Public version:.) So I can identify at a glance which identifiers are types, methods, local variables, member variables, and global variables. And I can almost always tell which arguments to a function are the inputs and the outputs. So we don't need an IDE for that.
- stability, as in constancy — emacs and vim never change. I don't have to worry that an update is going to be forced on me that's going to "move my cheese" and disrupt my workflow.
It may be that early on in the life of a programmer, the features of an IDE are very helpful, but as you get more experienced, you are better able to "run the program in your head," like Cypher in The Matrix. ("You get used to it… I don't even see the code.")
That's not to imply that engineers who use simple text editors are somehow "better" than those who use IDEs. I wish I used an IDE that was better than emacs. The most important thing, at Google or anywhere else, is that you and your team should choose the tools that make you as productive as possible.
Note that this is my personal opinion and reflects my personal experience.