Skip to main content

The Lessons of Vim

Full Disclosure: I’m no longer using Vim as my full-time editor. I’m giving Atom a shot, because I really do like the energy around it and every once and a while I like to mix things up. (I even became an Emacs user for a year, just to see what the other side looked like!)

I while back I really enjoyed reading Mike Kozlowski’s piece Why Atom Can’t Replace Vim, and I completely agree with the sentiment 100% (even considering the above disclosure!). Emacs is an editor I have enormous respect for, and not just for what it is but the heritage it serves as for so many editors to come after it.

Emacs’ big idea has been thoroughly learned — and how vi’s big idea hasn’t.

From TextMate to SublimeText to Atom, modern editors have all adopted the extensibility lesson so much to heart that it is, essentially, a part of the fabric of what it means to be a (decent) text editor. More or less, you’re either notepad or you’re extendable.

Thank you, Emacs, and all you stand for, for the influence you’ve had on for more developers’ editors than those who use your.

Emacs’ big idea was that it could be modified and extended cleanly.

But, it seems that while the balance between Emacs and Vim in their respective camps has remained steady, there is an obvious place where Emacs won out, even among those who don’t care about either.

Vi’s big idea hasn’t been nearly as influential.

And this is a hurtful truth to agree with, but truth it is. If you aren’t a Vim user, and even if you are, it might be hard to articulate exactly what that Big Idea really is. Mike sums it up nicely.

Vi is fundamentally built on command composability. It favors small, general-purpose commands that can be combined with objects to compose larger commands.

And he wraps up with a note about what is needed to really replace Vim, if any editor ever really will.

A new, shiny, modern editor could one-up Vim by fixing some (or hopefully all) of these issues. But before an editor can replace Vim, it needs to learn everything that 1976 has to teach — not just the lesson of Emacs, but also the lesson of vi.

The lesson I really took from this is something that isn’t entirely obvious at first, but grew out of absorbing this writing and letting it stew with other thoughts in my head about tools like LightTable and the research of Jonathan Edwards.

What I think will really take off is when we are able to reproduce the composable nature of Vim in a tool that is less bound to the limits of ASCII flat files. The composable nature of Vim is perfectly suited to working with scopes of code at levels that really only exist as rules of syntax, and would likely be better bound not in a text editor but an AST editor. I imagine tools that parse and export between source and AST, but never actually give you access to edit text directly. I imagine beyond that formats that serialize ASTs and are never intended for direct editing in tools other than AST editors that parse that binary format.

And I think we’re headed to places where this starts to creep into our world, and the lessons of Vim will be waiting. I am tempted to use the phrase “ahead of its time”, but I won’t. Not because i think it cliche or untrue, but because the more true framing is that it was we who were behind our time.


toddrjen said…
The kate text editor has a vi mode that, as I understand it, is designed to do exactly what you are suggesting.

Popular posts from this blog

CARDIAC: The Cardboard Computer

I am just so excited about this.

CARDIAC. The Cardboard Computer. How cool is that? This piece of history is amazing and better than that: it is extremely accessible. This fantastic design was built in 1969 by David Hagelbarger at Bell Labs to explain what computers were to those who would otherwise have no exposure to them. Miraculously, the CARDIAC (CARDboard Interactive Aid to Computation) was able to actually function as a slow and rudimentary computer. 
One of the most fascinating aspects of this gem is that at the time of its publication the scope it was able to demonstrate was actually useful in explaining what a computer was. Could you imagine trying to explain computers today with anything close to the CARDIAC?

It had 100 memory locations and only ten instructions. The memory held signed 3-digit numbers (-999 through 999) and instructions could be encoded such that the first digit was the instruction and the second two digits were the address of memory to operate on. The only re…

Interrupting Coders Isn’t So Bad

Here’s a hot take: disrupting coders isn’t all that bad.

Some disruptions are certainly bad but they usually aren’t. The coder community has overblown the impact. A disruption can be a good thing. How harmful disruption might be a symptom of other problems.

There are different kinds of disruptions. They are caused by other coders on your team, managers and other non-coders, or meetings throughout the day.

The easiest example to debunk is a question from a fellow developer. Imagine someone walks over to your desk or they ping you on Slack, because they have “one quick question.” Do you get annoyed at the interruption when you were in the middle of something important? You help out your teammate quickly and get back to work, trying to pick up where you left off. That’s a kind of interruption we complain about frequently, but I’m not convinced this is all that bad.

You are being disrupted but your team, of which you are only one member of the whole unit, is working smoothly. You unstuck …

How To Care If BSD, MIT, or GPL Licenses Are Used

The two recent posts about some individuals' choice of GPL versus others' preference for BSD and MIT style licensing has caused a lot of debate and response. I've seen everything as an interesting combination of very important topics being taken far too seriously and far too personally. All involved need to take a few steps back.

For the uninitiated and as a clarifier for the initiated, we're dealing with (basically) three categories of licensing when someone releases software (and/or its code):
Closed Source. Easiest to explain, because you just get nothing.GPL. If you get the software, you get the source code, you get to change it, and anything you combine it with must be under the same terms.MIT and BSD. If you get the software, you might get the source code, you get to change it, and you have no obligations about anything else you combine it with.The situation gets stickier when we look at those combinations and the transitions between them.

Use GPL code with Closed S…