It’s true what they say about working with other smart people; you end up learning a lot from observing their work and perspective. Early on in my time at Square, a bit of pair programming with a couple of great engineers led me to eventually picking up vim as a default code editor, at least for anything that isn’t better handled by a full-fledged IDE12. Granted, I don’t program much anymore, but I still turn to vim the once or twice a year, when I need to navigate bits of code.
vi(m) is a hard editor to learn, and its role as the default editor for Bash shell provides ample humor when unsuspecting users invoke it and can’t figure out how to exit3. Its difficulty is twofold:
- Modal editing, where the editor can either be inserting text or manipulating the text or cursor; the latter is the default state and the main reason why folks do stumble into vim don’t see anything on the screen when they hit keys.
- A non-visual, shortcut-key-laden macro-like language for editing text that’s impossible to organically discover; designed during a time when the alphanumeric keys were the only method of input, they’re overloaded to enable a diverse number of editing operations.
It’s actually nigh impossible to find another popular editor outside of vim that features modal editing. Interface designers and builders have abandoned idea, opting instead for the straight-forward WYSIWYG-type interfaces that, in conjunction with a GUI, is less powerful but much easier to understand. In fact, when editors are thinking of such a modal interface, the primary/only line of thought is to implement vim keybindings. Other apps have also included some simple subset of these bindings for simple commands, most often the alternative movement keys (
l). The point is that both software makers and users have largely agreed to not proliferate vim’s constraining design choices, that the tradeoff between editing power and usability is not really worth the cost of obfuscation, complexity, and high learning curve.
Inevitably, however, some will mistake this collection design resolution as a purposeful gatekeeping mechanism. For some its devotees and evangelists, the difficulty is a feature, its mastery proof that the user is—uh—really serious about their text editing. I often make the argument that valuable things—skills, titles, company missions, passions—have to by definition be earned through laborious hard work and time, but using something like vim as some sort of demarcation ends up feeling elitist.
Maybe I shouldn’t act surprised; this is, after all, just another rendition of geek one-upmanship.