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.

Comments

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 Range of Content on Planet Python

I've gotten a number of requests lately to contribute only Python related material to the Planet Python feeds and to be honest these requests have both surprised and insulted me, but they've continued. I am pretty sure they've come from a very small number of people, but they have become consistent. This is probably because of my current habit of writing about NaNoWriMo every day and those who aren't interested not looking forward to having the rest of the month reading about my novel. Planet Python will be getting a feed of only relevant posts in the future, but I'm going to be honest: I am kind of upset about it. I don't care if anyone thinks it is unreasonable of me to be upset about it, because the truth is Planet Python means something to me. It was probably the first thing I did that I considered "being part of the community" when I submitted my meager RSS feed to be added some seven years ago. My blog and my name on the list of authors at Plan

Pythonic Defined

Introduction Losing is Good Strings Dictionaries Conclusion Introduction Veterans and novices alike of Python will hear the term "pythonic" thrown around, and even a number of the veterans don't know what it means. There are times I do not know what it means, but that doesn't mean I can define a pretty good idea of what "pythonic" really means. Now, it has been defined at times as being whatever the BDFL decides, but we'll pull that out of the picture. I want to talk about what the word means for us today, and how it applied to what we do in the real world. Languages have their strengths and their idioms (ways of doing things), and when you exploit those you embrace the heart of that language. You can often tell when a programmer writing in one language is actually more comfortable with another, because the code they right is telltale of the other language. Java developers are notorious for writing Java in every language they get their hands on. Ho