I am a huge fan of text editors. While I have taken a few GUI editors for a spin, I always come back to Terminal Vim. In this post, I’m going to develop an argument as to why you should stop using IDEs and pick up an editor using Vim as my end example. If you use a text editor besides Vim, feel free to replace all forthcoming instances of Vim with the name of your favorite text editor. Of course, if you find yourself repeating the phrase, “I didn’t know text editors could do that,” or “My text editor doesn’t have that feature,” you should also switch to Vim.
Many developers, perhaps you among them, frown upon the use of text editors in instances where an IDE is available. After all, an IDE offers such a rich set of powerful features, how could a text editor ever compare? Many arguments exist that countermand this mindset. Most IDE programmers consider an IDE’s ability to ‘think’ by using parsing techniques as their most powerful feature, and the source of most of an IDE’s offerings. I, however, see this as a terrible curse upon the programmer. As Mr. Weasley said in Harry Potter, “Never trust anything that can think for itself if you can’t see where it keeps its brain.”
You’re a programmer because you can (or currently want to) learn to read and understand the syntax and semantics of code. With an IDE you can place your cursor over a red squiggly line, which the IDE has figured out is an oopsie, or over any old declaration, and with a key press it will plop out some information that makes your job not just easier, but also nonexistent. As a programmer, learning equates to professional value. An IDE lets you lazy your way out of understanding. Don’t let IDEs rob you of your value. Vim can offer you more convenience, while also letting you learn the hard lessons for yourself that will make you a better programmer.
A good text editor can emulate most of the other features offered by any popular IDE without the need to understand semantics. They also operate faster, because they lack the heavy background tasks necessary to build parse trees. Vim programmers have found clever ways to perform the heavy tasks that an IDE might perform using its complex parsing system. Vim lacks the ability to ‘read’ the code for you, but then again, that’s your job. You should understand the code, its effects, and how to parse error messages without the need of a help library.
Not to mention the loss of valuable coding experience, learning an IDE deprives you of the ability to work with anything beyond the scope of the IDE’s supported languages. “It would have been nice if I could have spent some time using Vim,” you’ll think to yourself as you stare at that ssh prompt or your terminal only access to a crashed system (Fans of GUI text editors should reread the last sentence of the first paragraph). Your job security might also look rather shaky when your boss needs you to edit some source code for the washing machine specific proprietary programming language that your IDE doesn’t support.
With Vim, you not only receive the ability to navigate faster during the editing process, but also gain fine grained control over what tools you wish to include in your developer environment. Developers add a lot of unnecessary bulk to IDEs that apply to only a particular subset of project types. With Vim, plugin authors usually do not target a specific project type, and so their tools will carry over to everything you work on, thus providing a consistent experience across all projects. Customization through plugins makes Vim uniquely yours, and offers exactly what you need without frills.
Developers of IDEs don’t have time to add features that don’t pertain to the project type. You will miss powerful editing features like buffers, registers, and modal editing (Vim plugins do exist for IDEs, but they offer a subset of commands). An IDE will include templates and domain specific refactorings that can cause you to shoehorn systems into specific design patterns. You should manually build in design patterns and complete refactoring to the specific needs of your design. After all, if someone pays you to code, you should being using your expertise to make the system look and perform correctly to give your employer the best value. Using the IDE for these purposes outsources your job to the machine. If you need code expansions, just use snippets instead.
An IDE expects a certain workflow from the user. Your IDE will control the way in which you work, rather than the editor conforming to your most efficient style. Vim gives you the power to mold th editor to your most efficient style. Because Vim focuses on being a great editor, the speed you gain through using it allows you to focus on more important tasks like considering the semantics of a program.
Vim is good for your health in a very literal sense. An IDE expects you to use a mouse in order to navigate through menus and interact with the GUI. As it turns out, keeping your hands in one place not only offers an increase in speed, but also prevents the development of wrist strain, which many programmers have developed due to the wrist motions necessary to control a mouse. A GUI benefits the consumer, not the producer. Learn to live in a terminal and you will instantly gain back that five seconds it’s going to take you to look up that method definition manually(or just use a vim plugin).
Did I mention that Vim is scriptable? If you don’t like the way Vim behaves, you can program it to your exact liking. Is Vim missing some terribly useful IDE element? If a plugin doesn’t already exist (which is unlikely), you can build it yourself!
To use a cheesy analogy, like a family blade passed down through the ages, Vim is your inheritance as a programmer. The personalization you give it will make it uniquely yours, such that no one will be able to use it as effectively as yourself, and you will find any other blade unable to cut with the same accuracy and power.
