The Cult of Vim

I start too many of my blog posts like this, but I pay too much for this site and write too little, so I guess this is a good time for my annual revisit to my blog and to add some content. My past posts have been pretty philosophical in content, so in my next "series" of posts, I'd like to discuss some of the more technical engineering oriented things I've learned from my internship at Riot Games this summer. 

Today, I'd like to talk about the cult of vim, and why I am now a flag-waving card-bearing vim fanatic. In particular, in this post I'll share some of my thoughts regarding reasons to switch to vim I found personally compelling, challenges to switching to vim, the philosophy of vim, and some of my personal vim settings & config.

the official vi gang sign

the official vi gang sign

A Little Bit of Background

My first exposure to vim was from Jae's Advanced Programming course (CS3157) in my sophomore year, and my god, I hated vim so much. I did most of the course assignments in vim because he introduced us to and suggested using vim, and every minute of vim just sucked for me. I hated not being able to scroll, I hated having to type ':w' to write a file, I hated having to type 'i' to start typing, and most of all, I hated pressing the arrow key to move through characters of a line.

I understood that unless there was some masochistic trend amongst programmers, vim was probably not as hard to use as I thought it would be, but I was too lazy to learn C pointers and vim commands at the same time, so I just accepted that insert mode was weird and movement in vim was crappy.

After my experience in vim, I was introduced to IntelliJ from my internship at OTC Markets, and I was a pretty big fan. I could click on stuff and use my mouse and run a debugger, and I thought wow! IDEs are awesome. In my own personal work, from recommendations from friends, I usually used Sublime Text 2 and it was pretty decent for what I wanted it to do. I thought editors were just tools for programming, and since the meat of programming seemed to me to be the technical concept, quibbling about editors felt like putting the cart before the horse.

I started trying vim again and explored using it seriously after working with my colleague at Riot, the awesome Kyle Burton. When we were pair programming early in my internship I watched him work in vim, and I was convinced that vim was either super awesome or he was some kind of wizard (maybe both, still not sure about kbot...). I was deeply impressed by how fast he could execute commands to manipulate text from vim, and I felt like despite the steep learning curve and the bad first experience, I was slow enough in Sublime that ramping up to parity wouldn't take too much effort. Now I pretty much use vim exclusively for programming, I have a vim plugin installed for when I'm working in IntelliJ, and sometimes I even accidentally press shift-v to try to select lines in Google Docs.

Why Vim?

There are a couple of benefits of adopting vim, but in my mind, the most important one is that vim is an incredibly productive editor. There is a saying in the software engineering world that 90% of programming is thinking and 10% is actually coding, and I find that some people (me included) use that as a justification for less mastery over their tools. Since most of us spend most of our time thinking instead of typing, the logic is that optimizing for typing speed and editor speed doesn't yield that much of a gain. Personally, despite making the argument a couple of times in the past, I don't really buy that anymore. In my opinion, even if the premise is true, there are still very solid gains to be made for editing faster even in the 10% block of time a programmer is actually coding.

However, the real benefit of using a tool that you're very familiar with (and that could be vim, or any other editor), is that editing becomes second nature. If my primary focus in programming is to think about the problems, then I want to be as focused as I possibly can be, and any divergence in my thought or any distractions in my window of focus from thinking about my editor is *bad*. It doesn't matter how small the distraction is, how short the command is, any thinking you have to do about your editor is a distraction from your focus and that is *bad*.

I like this comic about interrupting programmers:

source: http://heeris.id.au/2013/this-is-why-you-shouldnt-interrupt-a-programmer/

source: http://heeris.id.au/2013/this-is-why-you-shouldnt-interrupt-a-programmer/

And I think it also applies in your editor. The less noisy your editor is in your mind, the faster you can do things with your tools, the better it is for your focus - and that is perhaps the most compelling argument for switching to vim.

Another strong plus of vim is that vim is available anywhere. I am recently beginning to appreciate this more, but vim requires no download, no installation, no setup, and almost anywhere where there is a UNIX environment, you can edit stuff with vim. That turns out to be super useful both when you change to a new machine, or more commonly, when you're working on another machine or in a VM. Even without your personal vimrc, vanilla vim is pretty decent and more than enough for most editing purposes. To me, it boils down to ease of portability, and in a Java-esque manner, vim is write once edit anywhere :p.

Challenges of Using Vim

So why don't more people use vim? Well, one of the significant challenges of moving to vim is the steep learning curve. I've been using vim every day for almost 2 months now, and I'm only starting to scratch the surface of beginning to "grok" vim. Vim is, for all intents and purposes, as far as I know, infinitely powerful, and as you learn more, there will be more and more commands and tips and tricks to learn until you can convince your friends and family that you are a vim wizard. The learning curve, in my mind, looks something like this:

poorly drawn image courtesy of paint

poorly drawn image courtesy of paint

But the productivity of using vim compared to most editors looks something like this:

disclaimer: these images are my own subjective views, based on editors I've used before

disclaimer: these images are my own subjective views, based on editors I've used before

As you can see, the learning curve is less of a curve, and more of a 90 degree wall. Learning vim is super hard, your productivity plummets when you start, and it feels like you're battling with your editor the entire time. However, for me, once I worked with vim more and understood the idea behind vim, I started sliding down the learning curve and boosting my productivity.  In the next section of the post, therefore, I'd like to discuss my understanding of the philosophy of vim, and how to address some of the challenges of vim.

Modal Editing in Vim

There's a lot that's confusing with vim, and one of the biggest things I think stumps new users of vim is the modal system of vim. Vim operates in a few different modes, but for most intents and purposes, vim has two modes: normal mode, where you move around and select text and run commands, and insert mode, where you insert new text. That is super confusing for a new user. 99% of other text editors only have insert mode, and the first time I used vim, I was very upset that I had to press 'i' to enter insert mode and I basically stayed in insert mode the entire time except when I was writing the file.

It turns out that that is a completely wrong way to think about vim.

The Philosophy of Vim

The correct way of using vim, in my opinion, is to generally stay in normal mode, and only leave for short bursts of typing in insert mode. The philosophy of this is that vim commands are meant to be combined, and this makes a lot more sense once you begin grokking vim, and stop seeing files as something you edit, but instead as grid-like blocks of text that you can freely manipulate and command.

The "Zen" of vim is that you're speaking a language, and a good way I learned to think about normal mode commands is as a language, with verbs, nouns, and adjectives. The verbs are your commands, such as 'c' (change), 'd' (delete), 'y' (yank), the nouns are your movements, such as 'w' (word), '}' (paragraph), or 'G' (eof), and the adjectives/adverbs are your numerical prefixes and your descriptors, such as 'a' (around) and 'i' (in). vim commands are meant to be combined into "sentences," which on a higher level, describes to vim what you want to do.

This turns out to be an incredibly powerful idea. Think of the time you spend actually inserting new text when you program, versus the time you spend moving around, copying text, deleting characters, etc. I would wager that the latter far outweighs the former. Part of the power of vim is that with proper knowledge of the commands, you can very quickly manipulate, move, copy, remove, replace, and delete text, leaving the actual typing of new code in short bursts in insert mode. The more vim you know, the shorter and more informative your descriptions are, and the more powerful vim becomes as a tool.

Another great benefit of using vim to its full power is the '.' command. The '.' command repeats the last command line change, and so the more succint and the more stuff your last command does, the more useful the '.' becomes. For example, if your last command was 'x' (delete 1 char after the cursor), then '.' is the same as 'x'. However, if you'd like to delete multiple words without counting them, or indent text, '.' is helpful as a "macro" for your last command.

This really only begins to scratch the surface of vim, and there's still a ton of commands and tools in vim that I don't know how to use yet. It can be daunting for someone coming into vim to be willing to take the dive and pay the high upfront cost of learning vim, so in this next section, I'd like to talk about what is maybe vim's greatest challenge- its super high learning curve.

How Do I Start Learning Vim?

When I learned about models for the atom in middle school & high school, I began by learning models that were largely incorrect, but were helpful in providing enough understanding to eventually refine my model. I think in a very similar way, learning vim is much easier when you ignore all the commands except the ones you immediately need. Instead of thinking of learning vim as learning the commands first and then trying to use every single one, remember that vim, just like any editor, is ultimately your tool. Describe to it what you want it to do, and then learn how to speak the vim language.

What is the first thing you'd like your editor to be able to do? A great place to start is the ability to move up, down, left, and right by characters. The first thing I learned in vim was to use 'h,j,k,l' instead of the arrow keys, and got familiar with keeping my hands on the home row. Once moving with 'h,j,k,l' started to annoy me (and it did pretty soon) I started to learn other movement commands such as moving by 'w' (word), 'b' (back 1 word) and '}' (paragraph). Once I got used to those movement commands and wanted to know more, I learned more powerful commands such as 'f_' (find next char), '/' (search), and 'z(t,z,b)' (keeps cursor in current position but scrolls view top, center, or bottom of the screen).

Let your pain drive your development, and trust that if something feels bad, there's probably a vim command for it. I found it a much more effective way to learn vim via describing to vim something I wanted to do, and once that proved to be annoying or painful, learn and describe to vim something more powerful. In my opinion, it's better to not try to learn every single command and use macros immediately. The plum model, while very wrong, is a decent model to start learning the structure of atoms, and moving by 'h,j,k,l', while very inefficient, is a decent way to start learning vim.

$MYVIMRC

Vim is also great because it's super personalizable. It's easy to edit your .vimrc to suit your personal habits and needs, and just as good chefs have custom tools, good vim-mers have custom .vimrc files. I've only started customizing my .vimrc and adding plugins, but here is a link to my .vimrc on github, and my vim cheatsheet (although I'm sure there are better ones on the internet). I won't go through my .vimrc here because there's nothing too fancy there, and the file is commented pretty heavily.

Some Final Thoughts

I've only started using vim really recently, so there's still a ton left for me to learn. The next goal for me is to learn how to use tabs and buffers more efficiently, since I still think of them in terms of files instead of blocks of text. I would be more than happy to hear any comments/ suggestions/ lessons regarding making my vim-ming more efficient, any awesome plugins or .vimrc lines I've been missing out on, or the philosophy of vim. I'd also love to see if more people could benefit from vim,  so if you're thinking of taking the leap and climbing the curve, please let me know! I'd be happy to discuss vim with you anytime.

I would like to finish this post with a vim koan:

No ultimate difference

One day a monk visited Master Wq, and inquired, “Master, how will my code be different when I have mastered Vim?” Master Wq answered, “Before Vim: declare, define, process, print. After Vim: declare, define, process, print.”
source: https://sanctum.geek.nz/arabesque/vim-koans/

p.s. I typed this post in vim.