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

Statement Functions

At a small suggestion in #python, I wrote up a simple module that allows the use of many python statements in places requiring statements. This post serves as the announcement and documentation. You can find the release here . The pattern is the statement's keyword appended with a single underscore, so the first, of course, is print_. The example writes 'some+text' to an IOString for a URL query string. This mostly follows what it seems the print function will be in py3k. print_("some", "text", outfile=query_iostring, sep="+", end="") An obvious second choice was to wrap if statements. They take a condition value, and expect a truth value or callback an an optional else value or callback. Values and callbacks are named if_true, cb_true, if_false, and cb_false. if_(raw_input("Continue?")=="Y", cb_true=play_game, cb_false=quit) Of course, often your else might be an error case, so raising an exception could be useful

How To Teach Software Development

How To Teach Software Development Introduction Developers Quality Control Motivation Execution Businesses Students Schools Education is broken. Education about software development is even more broken. It is a sad observation of the industry from my eyes. I come to see good developers from what should be great educations as survivors, more than anything. Do they get a headstart from their education or do they overcome it? This is the first part in a series on software education. I want to open a discussion here. Please comment if you have thoughts. Blog about it, yourself. Write about how you disagree with me. Write more if you don't. We have a troubled industry. We care enough to do something about it. We hark on the bad developers the way people used to point at freak shows, but we only hurt ourselves but not improving the situation. We have to deal with their bad code. We are the twenty percent and we can't talk to the eighty percent, by definition, so we need to impro