The single editor myth(ology)

August 25, 2016

One of the perniciously popular stories that you'll hear people saying and repeating all around the tech world is that you imprint on your first serious editor (or the first editor you master) and you can never really shift to another one. If you start out with GNU Emacs it's absurd to think that you can really move to vim, and vice versa, and so on. Among other things this leads people at the start of their career to worry about what editor to learn and to try to figure out which one they can stay with for a long time.

This story is garbage.

The reality is that editors are tools, just like many other things you use (such as programming languages). Yes, they're complex tools that you spend a lot of time with, but they're still tools. And you can and will learn and use many tools over the course of your career, editors included. It is both absurd and limiting to believe that you can't (or won't) shift tools repeatedly over the course of your career, or to insist that you can't possibly do so. Computing is far too fluid for that (and I say this as someone with an extremely durable environment).

(I lump IDEs in with editors here.)

Also, it's not as if editors and especially the environments that surround them are going to stand still over the multiple decades of your career. Let's take GNU Emacs as an example. The core behavior of GNU Emacs may be thirty or more years old, but the packages and add-ons around it that make up a high quality editing environment have changed, are changing, and will continue changing and evolving in the future. The high quality GNU Emacs environment of 1996 was quite different from the high quality GNU Emacs environment of 2016, and the 2026 version is likely to be different again. Much as with browsers and addons, this effectively creates a different editor over time, albeit one with broad similarities to its past self.

(One obvious thing driving the changes in sophisticated editor environment are the changes in everything else in computing. There was no git or Mercurial in 1996, for example, so there were no packages to smoothly integrate with them.)

So all of these 'single editor' myths are wrong. Your first editor won't be your entire world (although it will inevitably shape your early views of editing and what you like); you can change your main editor over time (and you probably will); it's perfectly possible to be fluent in multiple editors and editing environments at once; and it's even possible to like different editors for different things instead of trying to do everything in one.

There are sensible reasons to focus on a single editor (or a few) instead of flitting around from editor to editor at the drop of a hat, but these are the same reasons that you might focus your programming efforts on a few languages instead of chasing after every interesting seeming one that catches your eye. And if you're so inclined, you might as well try out editors just as you try out programming languages, either to see if you like them or simply to expand your ideas on what's possible and useful.

(I am not so inclined in either editors or programming languages. With editors it generally feels as if there is very little point in exploring a new one, partly because most of my needs are modest and already pretty well met by editors that I already know. But I know that there are people out there who delight in taking new editors out for test drives.)

Written on 25 August 2016.
« Blindly trying to copy a web site these days is hazardous
Why ZFS L2ARC is probably not a good fit for our setup »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Thu Aug 25 23:35:00 2016
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.