An IDE can heavily influence the development experience in a language, as I found last week with IntelliJ for Java. This week at Chicago Ruby, Brian and Chris of Hashrocket talked about how the VIM IDE influences the experience of writing in Ruby.
Going from Sublime to VIM is a switch that some of my Rubyist colleagues have chosen not to make because, they explain, the additional bells and whistles of VIM cause more confusion than efficiency. I admit, I’ve had the same impression: the first time I saw VIM, I was watching a presenter demonstrate some Ruby code. I struggled to articulate my questions to the presenter because VIM’s line numbers followed the cursor rather than staying put. That made a bad first impression. I looked forward to coming to Chicago Ruby tonight for a second impression that might make me rethink my position. Unfortunately, that did not happen.
That’s not to say that VIM isn’t awesome and worth a look. Perhaps it is. But, from my perspective, VIM’s opportunities to convert Sublime users lie in places other than those emphasized here. So I humbly offer the following set of reactions to the VIM presentation, from a Sublime user. Here’s what I got from it, and here’s what I wish I got from it.
First of all:
The presentation began with a demonstration of VIM’s ease of use. To exemplify this, we were shown how one can, in a keystroke, delete all the white space lines. Just as easily, we could delete all the lines with digits. Or duplicate them.
OK, that’s flashy. But why would I want to do these things?
I put the white space in there for the purpose of making my code more legible. I have no reason to take it out. And the digits trick seems out of left field.
Here is another selling point we received for VIM: “even if you’ve been using VIM for 10 years, you’re always learning new things to do with it.” This is bad. If it takes me 10 years and I still can’t use my IDE optimally, then it’s creating a barrier to excellent development.
Why is this ten-years thing okay for programing languages, and bad in an IDE? It’s because programming is a craft. An IDE is a tool that allows us to practice our craft. Allow me to draw an analogy: after ten years as a carpenter, I’d be delighted to continue to learn interesting tricks and practices to improve my carpentry. At that point, I do not want to be finding out new features of my hand saw.
So if none of that was effective for me, what would be effective in selling VIM to a Sublime user? Some clues await in the second portion of the presentation: the demo and test drive.
Second of all:
Here is what we covered in aforesaid second part of the presentation:
Navigation – this was glossed over, which is a shame. If there’s one thing I cannot stand about Sublime, it’s navigation. Why do files look like they’re in folders that they’re not in? Why can’t I drag and drop files into different places in Sublime? If VIM does these things more easily than Sublime, than this is a major selling point. But we heard nothing about it. We didn’t even see one example. I want at least two examples of this: specifically, I’d like to see how VIM solves the two problems I mentioned above with navigation in Sublime.
Tags – references to every appearance of a symbol in your codebase. OK, but I can do that with cmd-shift-f in Sublime by doing a directory-wide find-by. This does provide an advantage in that if I want to see a lot of different tagged things rather than one word or something.
Use Working Sets – VIM helps with this by providing a buffer list of windows and tabs opened in this VIM session. This allows for tab-complete…similar to ctrl-t in Sublime.
Git status – I can see the differences between code bases on different branches with git diff…exactly as one might do in the terminal.
Leap between gems – In VIM, we can go to a giant list of all the gems in our project, then jump into any of those gems and change the code locally with ease. This is an excellent feature. This, in my humble opinion, needs to be feature number two that gets listed, after a much more thorough examination of the navigation advantages in VIM. All the stuff that came between navigation and this should move down the list.
Summon a file by its role name – this is another tab-complete thing that a Sumblime user would accomplish with cmd-t.
Autocomplete – By hitting ctrl-a, a developer can have VIM autocomplete code based on the code in recently used files. How does this work in practice? It “autocompletes” by having you scroll through a giant list of stuff you’ve put in the code already. Sublime does this, but I don’t use it: if I typed it recently, I remember it. This might not be the case while working with 700 different classes in Java, and so IntelliJ’s version of this feature is a major timesaver. In Ruby, this doesn’t save as much time.
Surround.VIM – Example: automatically removes both parentheses, rather than you having to delete them one at a time. Maybe this saves some developers a lot of time. If so, it deserves emphasis. This is not the case for me, though.
Ruby-aware motions to delete a whole method, jump to the next method, reorder methods: I could see this being really useful, especially for cleaning up a file. If I want to make model code legible to other devs, I’ll alphabetize the methods in there. Moving them easily would help. Actually, will VIM automatically alphabetize them for me?
Lots of Plugins. So this is cool. See above: is there a plugin that will automatically alphabetize all of my methods? Because that would be a selling point.
Just to be clear, I’m not bashing VIM. Clearly, it has converts from Sublime who see something in it. Given that, I must speculate that a stronger case could be made for why more of us should make the switch.