The expression “_____ isn’t for everyone” can sound snobbish. For example, if someone says that their favorite wine isn’t for everyone, are they really saying that not everyone has the refined taste that they do? Or if they say their favorite author isn’t for everyone, are they really saying that not everyone is smart enough to appreciate the books they enjoy?
But sometimes the expression is used humbly, as in Brian Carper’s article Emacs isn’t for everyone. There are some arrogant Emacs users out there, but Brian isn’t one of them, at least not as far as I can tell by reading his article. He simply discusses some of the pros and cons of the software and explains why some people would be better served by another tool.
I hope you’ll keep reading even if you have no interest in Emacs. This isn’t a post about Emacs per se. It’s about some of the things the article made me think of.
The majority of software development articles either advocate the author’s tool of choice or complain about a tool the author is forced to use. (See Ford-Chevy arguments in tech for a possible explanation.) Articles that frankly discuss pros and cons are rare. Here’s a sentence from the article I particularly liked.
Mastering an arcane text editor isn’t necessarily going to be on the top of the list of everyone’s goals in life, especially when there are other editors that are easier to use and give you a significant subset of what Emacs would give you.
That’s a far cry from “Maybe you’re not smart enough to use Emacs.”
I also appreciated that the article wasn’t overly pragmatic. It wasn’t just a dry cost-benefit analysis. Brian explains
I didn’t learn Emacs with the goal of being productive. I learned it for the same reason some people build cars in their garages, while most people just buy a one and drive it to and from work every day. … For me, productivity was a beneficial side-effect.
Every once in a while you’ll see someone say they use a tool for fun. For instance, I’ve heard several people say they were burned out on programming until they discovered Perl or Ruby. But it’s far more common for someone to say “This made me more productive.” than to honestly admit “I enjoy tinkering with this.” The two probably go hand in hand: you’ll probably be more productive using a tool you enjoy tinkering with even if in some objective sense it’s inferior to another tool.
> For instance, I’ve heard several people say they were burned out on programming until they discovered Perl or Ruby.
True for me. That’s why I love Python.
My reasoning was similar. I realized I didn’t have a good general-purpose, scriptable editor, and I could see some obvious choices. I chose Emacs not because it was obviously the best, but because it was old and lispy, sounded like loads of fun, and real hackers use it — I’d like to get there someday, and it seems like a good way to learn is to imitate real hackers. I could see that Emacs would do most of what I figured I might need, and added to the above, that satisfied me.
And some people would rather build their own tools than actually use them. I can identify with Terence Parr’s motto:
I program in Haskell because it is fun. I’ll admit though, I learned it for much the same reason the Carper justifies his learning of emacs — because it was fun to tinker around with, and was a source of wonderfully abstract ideas. I’ll definitely be adopting the ‘building a car in your garage’ analogy, when explaining my motivations in the future! If nothing else, it is far more convincing than a 60 second spiel about monads, side-effects and concurrency.
Back when I still had all my teeth and color in my hair I learned EMACS because it was fully funtional on a VT-100 and could be split into multiple buffers, essentially multiple windows you could switch between. Each buffer (window for you youngsters) could edit a file, or run a shell, or run an interpreter, or do email, etc. all at the same time, and all in one session.
For all you fellow old fogies, a bit of nostalgia:
# cat > > ~luser/.cshrc
alias vi 'rm !*;unalias vi;grep -v BoZo ~/.cshrc > ~/.z; mv -f ~/.z ~/.cshrc'
^D