james mckay dot net
because there are few things that are less logical than business logic

Posts tagged: vim


For those of you who don’t understand the title, it is vim-speak for “Forget this, I quit.” As of this week, I am no longer a vim user. I have uninstalled it from both my home and work computers and do not intend to pursue it any further. After over four years as a casual vim user, and a handful of failed attempts to take it further than that, I can safely say that attempting to become a serious vimmer is the most pointless exercise in futility that I have ever attempted, a complete distraction, and a vortex that sucks you into unreality.

I was first introduced to vim about four and a half years ago by a couple of friends who run a local two-guys-in-a-garage IT consultancy, who questioned my geek credentials on the grounds that I’d never used it, and dismissed me as a wuss because I preferred to use nano when I had to ssh into Linux servers. More out of curiosity than anything else, I got hold of a vim cheat sheet and started having a play with it, and I’ve ended up using it as standard in Linux ssh sessions nowadays.

More recently, I started trying to use it on Windows. In theory, it sounded like a good idea — stop relying on IntelliSense, and commit your APIs to memory — but I’ve found that in practice, while it’s nice and handy for quick-and-dirty edits to single files such as my hosts file, when it comes to more serious use — trying to make extensive edits to a .NET project, for instance — it rapidly starts to feel like an exercise in futility, and I’m usually back to Visual Studio and Resharper with their IntelliSense phrasebooks before you can type :wq.

Let’s take a fairly simple operation. You have a dozen or so lines of code that you want to move from one place to another. In theory, it’s quite simple in vim. You put your cursor on the first line and type 12dd. You then move to where you want to put it, and press p. Only how do you know it’s 12dd and not 13dd? You have to count the number of lines first. Great. Let’s press j-j-j-j-j, counting all the time until we get to the bottom, then type 13k to get back to the top, only to discover that we’ve mis-counted. Vim fanboys tell me that you can be much more fluent once you know how to use it, but this doesn’t seem particularly fluent to me.

I recently came across a screencast of someone using vim to do some fairly complex cleanup of a Microsoft Word document by running the raw XML through various regexes and macros. It all looks pretty clever and all that, but it makes me ask, why are you using a text editor at all for that in the first place? That kind of thing is the job of a scripting language such as sed, Perl or Python, simply because you should be saving it to disk for later re-use.

Of course, there’s a massive learning curve, and they also tell me you also need to customise it heavily before you can see any benefits, but they say it’s worth it. I dunno. Maybe you will see some benefits, but on the other hand, maybe you won’t. Or maybe you will think you do but you won’t have any metrics from “before” to compare it against. Certainly, it seems to me like a lot of effort for something where YMMV, and it all looks particularly pointless when there are more modern alternatives out there that are far more intuitive, easier to use, and every bit as powerful. In the meantime, not having reached that point of fluency, vim still feels to me very much like trying to edit code with Notepad. Or, as my colleague Ashic Mahtab said on Twitter, it “seems like Resharper for Notepad.”

Tourists and residents, Visual Studio and vim

My blog post on Silverlight seems to have attracted quite a bit of attention from the Silverlight fans. Silverlight has quite a devoted following among many .NET developers: after all, you get one language and platform for everything from the front end through to the back end, you get IntelliSense, you get Resharper, and you get some awesome visual tooling. It also offered a hope that perhaps some day we might be able to ditch HTML and JavaScript altogether and build websites in XAML and C#.

A lot of .NET developers hate JavaScript, and indeed all other dynamic languages such as PHP, Ruby and Python, because you don’t get the IntelliSense, the drag-and-drop support, and so on. Even the best of us — people of the calibre of Jeremy Miller or Ayende — struggle without Resharper, as Rob Conery noted:

Finally – I can’t tell you how ironic I continue to find it that the people who rip apart visual tooling cannot, I repeat cannot function PERIOD without Resharper. I wanted Ayende absolute fumble when we coded together, and Jeremy Miller was just about… no he was completely… USELESS without it.

Yet PHP, Python, Ruby and JavaScript developers never have a problem with this. Poor support for IntelliSense never seems to bother them. Inconsistent conventions, such as whether $needle or $haystack comes first — perhaps the number one criticism levelled at PHP by .NET developers — are regarded as pretty much a non-issue. Developers working with dynamic languages are happy to put up with editors and IDEs that Visual Studio users would consider primitive.

Just try introducing your average .NET developer to vim. They’ll freak out.

Whoa! A console-based application! No IntelliSense! It doesn’t even have any drop-down menus! What is this, the Dark Ages? How do I edit things? How do I get out of it? How do I get help?!

Yet vim — and its equally mystifying arch-rival emacs — are incredibly popular outside the mainstream .NET community, as too is the command line. In fact, many non-.NET developers actively dislike some kinds of graphical tools, instead, preferring the command prompt. That’s probably why Joel Spolsky’s Mercurial tutorial, hginit.com, uses the command line almost exclusively. Visual Studio is perceived as a bloated, slow, YAGNI-fest, and the end-to-end integration of Team Foundation Server is dismissed as snake oil. Why?

It’s a case of two completely different mindsets.

When I was younger, one of my hobbies was learning German. I was never much good at it, mainly because I didn’t get as many opportunities to practice it in real life as I would have liked, but I did end up going to Germany a handful of times on some short (4-5 day) trips.

One thing I learned about Germany is that going there for a short visit is not quite as effective at teaching you the language as you would expect. A huge proportion of Germans speak very good English, and they will switch to it faster than IntelliSense can replace if with IFormatProvider at the slightest hint that you are struggling. English is cool in Germany.

For example, on one occasion, we were travelling up the Rhine by train when der Schaffner came into the carriage inspecting tickets. “Fahrkarten, bitte,” he said.

I handed over my ticket. He looked at it.

Haben Sie einen Zuschlag gezahlt?” he said.

At this point, my schoolboy German deserted me. I hadn’t the foggiest what ein Zuschlag was. Nevertheless, determined not to let the fact that I was linguistically challenged get the better of me, I made a wild guess that it was something to do with changing trains (as we had done in Karlsruhe), completely forgetting that I already knew that the word for changing trains is umsteigen, which most certainly isn’t ein Zuschlag. But when you’re as bad at German as I am, all those words beginning with um and zu tend to sound a bit too much like each other anyway.

Wir haben, um, zugeschlagen…

The conductor decided, in the light of the fact that I was struggling to speak nonsense, that some IntelliSense, aka English, was in order. “The supplement?”

Okay. So der Zuschlag is the supplement that you have to pay for reserved seats on German trains. I dug out the Zuschlag ticket, showed it to him, and he was on his way.

Now it’s one thing when you are only visiting a foreign country for a few days and either (a) staying with English-speaking friends, or (b) doing touristy things like travelling up the Rhine by train. It would be a completely different matter if you went there to live permanently. As a British or American expatriate living in a foreign country, you could get away without learning the local language and with relying on phrasebooks and English-speaking friends. But it would be much harder. After all, you would have to deal regularly with all sorts of people and situations. People like estate agents and lawyers and councillors and traffic wardens and pastors and doctors and car salesmen and vets and school teachers and politicians and telemarketers and social workers and employers and clients and creditors and bank managers and next door neighbours and kids accidentallyonpurpose kicking balls over your fence asking if they can come and retrieve them and people in Krähwinkel who have lived in the same house all their lives. People whose interactions with monolingual Brits and Americans are few and far between, and consequently have less of an inclination or opportunity to learn English.

Vim, emacs and the command line are like that. They take you right out of your comfort zone and force you to actually learn the vocabulary that you’re using in your code. You learn whether $needle or $haystack comes first in PHP, just as you would learn the difference between der Leiter and die Leiter in German. It sticks in your mind sooner, you become more familiar with the intricacies of the language, and you are more likely to be able to say, at an earlier stage, “Oh yes, there’s a word — a method — for that somewhere.”

By making us reliant on the IntelliSense phrasebook, Visual Studio encourages us to think like tourists. By forcing us to learn the language, on the other hand, Vim, Emacs and dynamic typing make us think like permanent residents.