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