Let your tools inspire you: Editor elitism, bias, and myths that keep you from thinking outside the box.

In order to frame and set the context for the rest of the post, I’m going to start off with one of my favorite XKCD comics:

Why do those nerds care so much about the editor?

Having a good toolbox and being skilled with your tools is just as important to a developer as it is to a carpenter. Imagine trying to build a house, but you only had a rock for hammering your nails in. You’d be slower, more prone to mistakes, turn out lower-quality work, and probably frustrate the hell out of yourself in the process. For those of you out there who don’t code, the connection may not be intuitive, but for anyone who has spent thousands of hours composing and manipulating code, the thought of using something like Windows Notepad for any serious work is painful.

Ask anyone who’s been coding for a long time what they use and why, and I can almost guarantee you’ll get a well-reasoned, thought-out, and probably passionate answer. If the editor they use is either Emacs or Vi(m), you’ll probably experience something close to religious enthusiasm (and a possible conversion attempt).

There is a duality to the process of writing code. Almost always rigorous and mathematical, it is at the same time a personal artistic expression of the person writing it. Bad code is ugly and inefficient. Good code is like prose to those who understand the language; A beautiful expression of creativity and genius.

That being said, there is a lot of tedium and repetition in the process of coding. Any time you’re mechanically repeating a mindless action, you’re taking up time that you could be coding, understanding existing code, or brainstorming about the code. A good editor is needed so that it is easier for you to get the mechanical stuff out of the way, and get back to thinking and composing.

From humble beginnings: A little history about myself.

When I very first started programming, it was teaching myself GW-BASIC on a 1982 IBM PCjr. Development took place inside the GW-BASIC command line-based development environment, and was probably the furthest thing from an efficient editor. Lines of code had to be prefixed with a line number, otherwise the interpreter assumed that it was a direct command that should be executed immediately. This caused enormous difficulty when trying to insert new lines of code between existing lines. The convention was–as far as I could gather by reading existing programs written in GW-BASIC–that lines would increment by 10. This way, if you decided later to go back and insert a new line, you would give it some increment between the two existing line numbers. Viewing existing lines of code was done through the “LIST” command. There may have been better ways to optimize your workflow, and better tools to use, but this was back before the days of common household internet, Google, and Stack Overflow. I was a kid in his basement with nothing but existing code samples and a whole lot of free time on his hands.

Web design, WYSIWYG, and Dreamweaver, oh my!

In my teens, I became intrigued with web design, and started learning websites through the not-really-programming approach of Adobe Dreamweaver. This was good enough to get some rudimentary sites going, and since the big thing of the day was Yahoo GeoCities, there wasn’t much competition in the aesthetics department. However, I quickly ran into situations where I was bumping up against the limitations of the WYSIWYG editor. Whether it was adding advanced functionality to the visual layout I had, or trying to peek under the hood to figure out why something wasn’t working, I found myself more and more in the source code, rather than the visual pane. I began to notice that the code was always more complex than it had to be, and it wasn’t very nice-looking either. For a while I used the source code pane of Dreamweaver to write and edit code.

The need for a “real” editor.

Then I discovered Notepad++. This was the first time I had been wowed by an editor. It was lightweight, simple to understand and learn, but packed with powerful features in the dropdown menus. I learned of the amazing utility of macros, automatic source code re-indenting, and plugins. I used Notepad++ (and Gedit, when on an Ubuntu machine) as I taught myself Perl, HTML, CSS, Javascript, and PHP, and would continue to use it until and for the first year or so of formally studying Computer Science.

Completely unfamiliar territory: Discovering Emacs.

When I began the Computer Science program at the University of Virginia, I was quickly introduced to IDEs, and fell in love with how capable they were. Code-completion, function lookups, easy management of the file tree–the list of features went on and on. The IDE did so much for you! Click a button, and just like magic, your application is built and ready! I wondered why anyone would prefer not to use an IDE. As I progressed to the more difficult CS classes, I was required to become familiar with the terminal, building manually using tools like Make, and (for at least one class) was required to use Emacs. The professor even asked us questions on the test about how to do things in Emacs, just to make sure we were actually using it!

Oh, how I hated Emacs for the first few months. It was the most confusing editor I had ever used. What was up with those key bindings? None of the shortcut keys were what I was used to… Alt-w to copy? Ctrl-y to paste? How the heck do I exit this stupid program?? Well, thankfully I was forced to use it for a few months for that class, because I wouldn’t have made it even one day with Emacs on my own.

The summer following the semester in which I was forced to use Emacs was a transformative time for me, with regards to coding. I began doing GPGPU research with a professor at UVa, and began taking my coding (both professionally as well as hobby-based) a lot more seriously. I began doing a lot with CUDA and OpenCL, and doing development on remote Ubuntu boxes. This meant I spend a lot of time working over SSH. By now, I had used Emacs enough in class to be decently familiar with it, and the ability to use it in the terminal after I had SSHed into a box gave it a lot more value. I started using it almost exclusively at this point, and that began a journey of extreme attachment and customization.

Anyone who’s used Emacs for any significant length of time can tell you about the .emacs file, and they probably have a large set of personal customizations to it. For me, this was one of the best parts about the editor. Once I got the basic built-in behavior down, I discovered that Emacs was an editor that would evolve along with you. If I found myself missing or desiring a particular piece of functionality, a quick trip to the .emacs file, along with a few lines of elisp, and I was on my way. At this point, I was a die-hard emacs fan.

Doing it all over again with Vim.

It wasn’t until November 2011 that I became curious enough about Vim to give it a try. I ended up trying and dropping Vim about 8 or 9 times out of frustration before it finally stuck. Once I got over the hump of learning the concept of modal editing (in addition to key bindings that were, once again, completely different from anything I had ever used), I was actually able to become very productive in the editor. I discovered all kinds of amazing features. One of my favorites to this day is the “change inside” feature. I’ll leave it to you to learn about this, but do a Google search for “Vim change inside parentheses” (or do the fantastic and well-done Vim tutorial, built in to the editor) if you want to learn about it. Vim, like Emacs, was a highly-extensible, customizable editor that would grow and evolve with the programmer. At this point, I’ve added so many helpful bindings, settings, and functions to my .vimrc file (similar to the .emacs file) that have taken Vim from a fantastic editor, to my own custom and personalized tool. It has become something I don’t even think about when I use it, which allows me to focus on the task, and not the tool.

Back to the Future with Sublime Text 2

It sounds like I’m pretty happy with Vim at this point, so why the step back in time to the days of a gui-based editor and try Sublime Text 2? To be honest, I was suffering from a bit of mouse envy at this point, seeing one of the guys on our iOS team at work move so proficiently about his code. I was starting to wonder why I was still mired in the days of a 30-year old text editor when so many modern alternatives were just waiting to be used. Plus, I was fairly enamored with the beautiful ST2 interface (the Monokai theme is one of my favorite themes to date, for any editor). I decided to give it a shot, just to see what it was like, and immediately discovered how useful the features were. The “go to anything” functionality was fantastic, as was project-wide search-in-files. It was fast and accurate, and made it incredibly easy to jump around massive code bases. Furthermore, the multiple cursors functionality was incredible. Far from being a gimmick, it was much more useful than I had initially thought it would be. The fact that each of the cursors has its own copy/paste buffer was a mind-blowingly awesome discovery. The minimap (a 30,000-foot view of your code) is a great way to get a visual overview of the “shape” of your code, something that is especially helpful for orienting yourself and getting a feel for where things are in larger source files:

Sublime Text 2 in action

As a backend developer who spends most of his time working either on remote servers, or remoting into a headless VirtualBox instance (via the fantastic and wonderful Vagrant), Sublime Text 2 posed some challenges at first. Then I discovered the SFTP plugin for Sublime Text 2. This allowed me to ssh into a box, navigate around, and then edit a file. The SFTP plugin would bring a temporary working copy of the remote file to my local machine, and then upload it back to the remote box any time I saved it. This happened seamlessly behind the scenes, allowing the user to interact with the file as though they were working entirely on their local machine. The folder mirroring feature worked in a similar manner, mirroring an entire project tree to your local machine. You could then use “go to anything” or find-in-files within the project tree. With the right options enabled, ST2 would ensure that you had the most recent copy from the remote box each time you opened the file on your local machine, and would then upload any changes in your mirrored folder to the remote box as they were saved.

Why I came back to Vim.

Vim in the terminal!

As good as Sublime Text 2 is, I didn’t stay with it. Oh, sure, I went back and forth, much like I did when switching to Vim. I even thought for a while that I had moved to ST2 for good. In the end, though, I came back to Vim. Here’s why.

  • I value my pinky. On OSX, my OS of choice, Sublime Text 2 benefits from the basic Emacs movement bindings that are built into the operating system. (Side note: This was one of the downsides to using Sublime Text 2 on Windows–no Emacs bindings. I know I can install the sublemacspro package in Package Control, but it’s not the same as using Sublime Text 2 on OSX.) Although I’m very fluent with this binding, it results in me holding down the control key for a large portion of the time I’m using the editor. I even have my control key swapped, which helps immensely. There’s just no way around having to hold down control, no matter where you swap it. Some people prefer the Emacs-style key chords as opposed to modal editing (and I did too, for a while), and that’s fine. Personally, I like the modal editing method.
  • Getting around the text is precise. This is where Vim excels. Emacs is a do-everything tool, and a damn good one, at that. It excels at being not only extensible, but having just about every feature you could need (and many that you don’t even realize you need yet) all wrapped up into one package. For me, however, I spend most of my time interacting with, and composing text, and this is where I like my editor to excel.
  • While working on remote files with an editor on your local machine is cool (and Sublime Text 2 with the SFTP plugin is the best workflow I have experienced doing so), I need to interact very frequently with the command line. Emacs gives me this option with the ability to open an embedded terminal, but my preferred method is to open a tmux session on the remote machine. With nested windows and split panes, tmux becomes something of an IDE. It has the additional bonus of allowing me to detach, move to another computer, and reattach, picking up exactly where I left off.
  • Vim (and Emacs, for that matter) doesn’t have a notion of a “Super” key (Windows logo key, or Command key on a Mac). I thought that, since Sublime Text 2 was available on Linux/OSX/Windows, that I could invest in this editor wholeheartedly (like I did with Emacs and Vim), and have a portable and coherent coding experience when I jumped between platforms. What I didn’t realize until trying to use Sublime Text 2 on Windows instead of my usual OSX was how much I had the Command+[some key] shortcuts ingrained in me. A vast majority of my experience on Windows was different from the experience on OSX, and this caused my productivity to grind to a halt as my focus shifted from the task at hand, to trying to figure out how to use the tool.
  • High portability of skills. Vim’s motions and key bindings port well to other development environments, like Eclipse and Visual Studio, via the use of plugins. I’ve tried a couple of platforms with various plugins, and have been very pleased with them. While they don’t fully execute every last bit of Vim functionality (some come very close!), the important bits–namely anything to do with moving around and interacting with the code–are easy enough to implement, and are well represented in the various plugins I’ve tried. All this to say, by investing my time in learning Vim, I have a skill set that I can use anywhere that I can find Vim (which is pretty much anywhere) and, should I be required to use another development environment, my skills won’t go to waste due to the ability to bring the Vim control scheme to other platforms.

Inspired by my editor: What using Sublime Text 2 taught me.

While I did spend a fair amount of time learning and switching back and forth from using Sublime Text 2, it certainly was not a waste, by any means. Using Sublime Text 2 introduced me to a number of awesome features that I had not even thought about searching out or trying to implement in Vim. For example, I found the ability to instantly jump to a file in my project directory in Sublime Text 2 incredibly useful, so I wrote the following, and added it to my .vimrc file:

nnoremap <F2> :tabnew <bar> :r!find . \| grep -i ''<left>

This allows you to press F2, type any portion of a file name, and it will open a new buffer with any files matching that search that are within the current working folder, or any nested folder. To make this more sane, I also told Vim to keep whatever directory it was opened from as the working directory, rather than the directory of the file you’re currently editing:

set noautochdir

This is just one example of how I would discover a feature I liked in a different editor, and then look for a way to implement in my editor of choice. I wouldn’t have thought about it if I hadn’t been exposed the feature in Sublime Text 2. The same thing happened when switching to Vim from Emacs; Either by trying to replicate the ability to perform some task in Vim that I was able to do in Emacs, or by discovering a new feature in Vim, and then attempting to see if I could do it in Emacs, I learned a great deal about both editors, and came away more experienced and more knowledgeable. I am not, by a long shot, the most experienced Vim user at my job, but I have had numerous occasions where others have asked if I knew how to do something in Vim. Even though I’ve only used Vim for about a year so far, I still had plenty of experience to offer, thanks to feature exploration and trying to take things I liked from the world of editors at large, and implement it in Vim.

Myths, bias, and other terrible reasons to stick with X.

One surprising hurdle I faced when attempting to switch from Vim to Sublime Text 2 was editor bias. Or maybe it was editor elitism? I felt that going to a GUI-based editor somehow made me less of a hacker, and a less-impressive coder. It sounds incredibly stupid, but somewhere, nestled away in the depths of my psyche was the notion that all real hackers used text-only terminals for everything they do, never touched a mouse, and when they stepped away from their computer for more than a few minutes, they all had matrix screensavers that would cascade cryptic symbols down the three or more monitors they were coding on at all times.

I’m not downplaying the usefulness or legitimacy of the command line in any way. As previously mentioned, I spend almost 100% of my time in the terminal for development. But to have something like “how will others view me”, “will I seem impressive to others”, or “Hollywood does it this way” become metrics for choosing the tool you will use for coding is just plain stupid. If you’re coding so that people will look at you and be impressed, you’re doing it wrong. You shouldn’t be doing it at all. And yet, that mindset was part of what was holding me back from really jumping in and going all out with Sublime Text 2.

Here are some other reasons not to use editor X that really suck:

  • MYTH: You’re always faster when you don’t have to touch the mouse.
    While it’s incredibly productive to be able to perform all of your actions from muscle memory, without having to leave the home row of your keyboard, there is the occasional advantage that using a mouse can provide. Scrolling with the mouse wheel to peruse and learn code is actually quite nice. And when you’re taking a visual overview of your code, it’s quite nice to have the ability to swing the mouse arrow right up to where your eyes are already looking, click an exact spot on an exact line, and begin editing. In addition, dragging a rectangle region of the code with the mouse is wonderful. People may claim that it’s inaccurate and a waste of time to be pointing and and clicking, but I (and anyone who’s ever played in Counter Strike tournaments) will disagree, at least that you can’t be fast or accurate with a mouse. Even though it might be faster to perform a majority of editing actions using the keyboard only, it is by no means a blanket fact that mouse is always slower. If you’re picking an editor simply because it’s cool to not have to touch the mouse, you should probably spend a little more time in thought about which editor is actually right for you.
  • MYTH: Editor X is better because it’s everywhere.
    It can definitely be an advantage to have your editor be available (and even installed by default) on all of the major computing platforms, but it should not be the reason you decide to invest in that editor. While you may not be able to just remote into a server at a moment’s notice and use your editor of choice, that shouldn’t dictate what you use when you actually sit down and spend any serious amount of time in your development environment. If you’re settling in for the long haul on a project, take some time and set up a good dev environment. Set up an SFTP connection in Sublime Text 2 to the machine your code resides on. Install Emacs. Pull down your Vim configuration files on the machine. If you are so restricted that you don’t even have permissions to install on that machine, you should probably set up an intermediate development and testing environment, pushing your code to the restricted server only when necessary. I can’t think of a good reason that you would need to worry about such restrictive constraints for anything other than quick maintenance or on-the-spot fixes and tweaks on someone else’s machine.
  • MYTH: Real programmers use X.
    I’ve already covered this above, but it’s worth reiterating. I’ve seen some of the most brilliant programmers I’ve met use everything from Vim to TextMate. It doesn’t matter what you use, as long as it’s customizable, extensible, and can evolve with you. Don’t try to impress people with your editor, impress them with your work. That goes a lot farther, and people will actually remember you for it.

Summary, and lessons learned.

Don’t just take your editing experience at face value, and write off functionality that doesn’t exist (or that you don’t know exists). Let your experiences inspire you to build and evolve your editor of choice. Just because you should pick one editor and learn the hell out of it (see also) doesn’t mean you have to be satisfied with only what that editor has to offer (and especially not with what you think that editor only offers)! Explore, expand, and make sure you have a powerful, configurable, and extensible editor that will grow with you.

Advertisements