Another repost as I get caught up... and more holy wars!
I’m feeling a bit crankier than usual today, so I’m posting this editor flame war rant. So time to put on your asbestos suits everybody!
Vi/Vim sucks. So does Emacs. There is almost no reason for a modern day beginning programmer to use either of these editors. Therefore, I get particularly annoyed when I see programmers making the claim that to be a “real programmer,” you have to learn and use Vim or Emacs as your text editor. I feel the same way when people claim that Vim and Emacs are the end-all, be-all of text editors.
First, while I’m saying that those editors suck, I’m talking about the editors themselves, not the people who use them. If you’ve been using those editors for years and have achieved proficiency in them, hey, great, I got no problem with that. Despite sucking (and I’ll explain the nature of their suckage later on), they’re still very powerful editors that a person can be quite productive in after having spent enough time learning them. If you’ve already mastered Vim or Emacs, no matter the reason why you first took the time to learn them, bully for you.
Second, there is one good reason to learn the basics of vi: doing any sort of development or administration on/for a full-blown Unix/Linux machine (not a smartphone running a Unix/Linux derivative OS). If, for example, you’re only writing iOS apps all day long, learning vi serves no useful purpose. Vi is the editor of “almost last resort” (the real editor of last resort is ed, but you can think of it as a crippled, line-editing-only vi with a similar command set) on Unix/Linux. It’s guaranteed to exist on all machines and to run when you need to make a quick configuration or code modification while remotely logged in over a slow link (unless somehow your terminal settings have gone wacky, in which case, you have no choice but to fall back to ed). Therefore, some basic proficiency in vi (opening, saving, navigating, modifying, searching, etc. files) is a must for these scenarios. However, you don’t need any more than the basics here. Emacs, though usually on most machines, isn’t universally guaranteed to be there, so it’s less useful in this case than vi.
Now, I’ve already stated that both editors are powerful, so how can they also suck? Simple – their user interfaces are crap. Sure, they may have been state-of-the-art for the 1970s, but we’re in the 2010s now. We’re no longer running VT-100 terminals on our desktops and the tools we work with should reflect that. Granted, both Vim and Emacs have GUI modes that go a decent way towards modernizing their user interfaces, but they still feel like bolted-on additions to 1970’s technology instead of a more modern design – especially since the archaic terminal-based UI is fully available within the GUI versions of both programs. Frankly, it feels like they were mostly done to provide nicer fonts and somewhat better multi-file support (multiple separate windows! tabs!) relative to the terminal-based versions (as well as to help port them to operating systems that may not have good text-based terminal support built-in).
Emacs lovers and haters both know about the crazy Control-Alt-Meta-Shift-Super-Hyper command set. I don’t think I’ve met an Emacs lover who thinks the command set is a good thing outside of letting the editor be a modeless editor. They seem to pretty much think, “it’s somewhat annoying, but I’ve learned its quirks and how to get at the features I want, so I’m cool with it.” Some of them may have even taken the time to remap commands to less crazy keystrokes by writing their own elisp. Okay, I admit that’s pretty cool, so props to Emacs and its users there.
Vim fanboys, however, seem to think its modal functionality and 1970’s era user interface is inherently superior to anything that’s come later. They go on and on about how using hjkl to navigate is a mark of brilliance as it keeps your hands on the home row. They talk about how its single-character commands were designed for user efficiency. Want to know a couple of dirty secrets? The main reason why hjkl keys were chosen for navigation in Vi had nothing to do with being on the home row. They were chosen because the 1970’s ADM-3A terminals that vi’s creators used back in the 1970’s had arrows printed on those keys on their keyboards. Being on the home row was coincidental. As far as the whole single-keystroke command efficiency thing, true, it was more efficient -- when trying to type over a 300 bps link on those same ADM-3A terminals! Admittedly, those single-key commands do chain together quite nicely to create very powerful compound commands. However, those compound commands start to resemble line noise (hey, back to the 300 bps links!) once they become non-trivial. Actually, I know of another 1970’s modal editor known for having lots of one-character commands that can be chained together that end up resembling line noise: TECO. Oh, and TECO is the direct ancestor of Emacs, which was originally a bunch of TECO line noise, er, I mean macros. Hmm… Finally, to those of you who think “real Unix users use vi,” I have news for you. Ken Thompson, one of the original creators of Unix, thought vi was a piece of crap. He actually preferred using ed over vi for many years until Rob Pike developed the Sam editor (which, shock and awe, was a full-blown GUI editor!). Unix’s other co-creator, Dennis Ritchie, also wasn’t a big fan of vi. His preferred editor was Rob Pike’s follow-up to Sam, Acme (which was also a full-blown GUI editor!).
As an aside, Acme, despite being odd-ball compared to just about every other text editor out there in many ways, is actually a really cool editor. I’m not sure I’d want to use it as my primary text editor, or even as a beginner’s first editor (it’s certainly got the “for advanced users only” feel to it in many ways). I’d also argue that, overall, it has a superior and more modern UI than either Vim or Emacs (though even it has a couple quirks that annoy me).
Going back to Sam, Acme, and GUI editors in general, both Vim and Emacs fanboys talk about the superiority of the keyboard interface. Again, they’re full of crap. This isn’t the 1970’s anymore. We have these things called “mice” (as well as similar devices like “touchpads,” “trackballs,” and that little eraser thing on ThinkPads). Keyboards are great for making small movements close to the current cursor position, but if you need to move large distances, it’s hard to beat the efficiency of a mouse (there, I said it). The same applies to selecting random blocks of text to apply editing commands to. Yeah, I know, Vim and Emacs both have all sorts of commands you can chain together to say things like “move up 25 lines, jump right to the 3rd instance of the letter ‘f’ on the line, then select to the end of the word,” but, really, is that actually superior to just “grab mouse, move pointer to line, drag pointer over text”? Going back to Acme, one of its strengths is that it probably makes the most intelligent use of the mouse I’ve ever seen in a text editor. The amount of power and efficiency it gives the mouse is actually really awesome. In fact, if I were ever to write my own text editor from scratch, I’d probably start with giving it Acme-like mouse capabilities (and even some of its other UI features). They’re that good.
Again, if you’ve become a total Vim or Emacs ninja, I’ve got no problem with that. Many of you (and myself included) started programming on machines where Vi/Vim and/or Emacs were the best editors available, so you had no choice but to learn one or the other. Maybe you were influenced in the past by someone who insisted that Vim and Emacs were the end-all be-all of editors and you just followed their lead without trying out anything else. Okay, I can understand that too, even if I think you were possibly misled. As I said, I have no problem with Emacs or Vim users in general, just with fanboys who think that all “real” programmers should use one of these editors as their primary development tool.
So, what does a programmer need in a text editor: Basically, the bare minimum is the following:
Vim and Emacs both offer these features. So does Sam. So does Acme. So does Sublime Text. So does Github Atom. So does QtCreator. So does just about every decent editor out there not named “Notepad.”
A nice to have feature for an editor is extensibility via an internal scripting/macro language, an API, and/or integration with external tools. Vim (though not so much the original vi) and Emacs count here. Then again, so do Sam… and Acme (which lets you write extensions to it in any language of your choice if you enable the file system interface). In fact, again, just about every editor claiming to be a programmer’s editor these days has some sort of extensibility feature. As for why I’m calling this a “nice to have,” well, in theory, a powerful enough editor may not require this as it has all the necessary features built-in. The editors I routinely use nowadays may be examples of this, except that I believe that many of the apparent “built-in” features are actually implemented as plugins using their extensibility mechanisms that happened to be included as part of the default installation.
What about things like syntax highlighting, folding, etc.? This comes down to personal taste as I’ve come across well-respected programmers who both love and hate those features. If you absolutely love those features, by all means use an editor that supports them, but don’t knock people who choose not to use them either.
So, what do I use? Well, I’m a bit of an oddball as I use different editors for different jobs. Still, this isn’t quite so crazy since all these editors have similar CUA-style keyboard shortcuts, meaning the learning curve in switching between them is much smaller than the curve in switching from, oh, say Emacs to Vim. For C/C++ code, I’m a big fan of QtCreator on Linux (and so is Linus Torvalds, for that matter, although he still prefers using the custom-hacked version of MicroEmacs he’s been using for years) and it’s what I use at my day job. On Windows or Mac, I’ll often use Visual Studio and Xcode, if only because most of the projects I’m doing on them are quickies where I don’t want to spend the time writing Makefiles and such and just wanna spit out a binary with minimal fuss. That said, I think they’re also good editors even if you don’t use their built-in project functionality and instead use external build scripts (in fact, that’s also how I happen to use QtCreator). For general scripting and text editing, I’m liking Github’s Atom a lot. IntelliJ’s PyCharm is a good tool for large Python projects. NetBeans and IDEA are good for Java (Eclipse is a steaming pile of crap though). Vim is what I use when remotely ssh’d to a machine (though I prefer using joe if available). Oh, and for little one-off things, I often fire up Acme just cause it’s so neat to play with, even if I don’t think I can work on a large project in it. I’ve also used Komodo Edit and Sublime Text for a while and, while I don’t use them at the moment, I think they’re also very good editors.
Anyway, the point of this rant is, “Don’t try to go convince beginning programmers that they need to learn Vim and/or Emacs to be ‘real’ programmers.” Any suitable programmer’s text editor is just fine. The general rule of thumb for beginners is “Anything but Notepad” (or whatever your particular OS’s equivalent of Notepad is).
Also, I’d strongly recommend even dyed-in-the-wool Vim and Emacs users to play with other editors every so often to see if they can make them more productive. I was an Emacs user way back when, then I switched to Vim for a few years, and then I decided to try out other editors to see if there was a “better way” out there. While my “better way” may not actually be better for you personally, it certainly has turned out to be better for me.Share on Twitter Share on Facebook