- Sunday, December 03, 2006
The Case for Emacs
When well-seasoned programmers get together to speak of the "good old days", there are a few persistent topics. There are always at least a couple of archaic programming languages ... depending on the number of reminiscing participants, there can even be enough to inspire a game of "I had it worse than you did!". Inevitably, this is followed by some form of reference to ancient multi-user operating systems, mainframes, or -- although increasingly rare -- systems involving punched cards. More often then not, this piece of the conversation will lead to discussions of operating ancient editors via terminals -- with ed nearly always starting that conversation (and earning several grimaces at its first mention).
If you've heard enough of these discussions, as I have, you've surely observed that the tone of these discussions suggests that we are now in a golden age of development tools ... I've been writing software, and hearing these discussions just long enough to start to wonder if these discussions were any different back then (it's all relative, isn't it?). Me? Well, I started this game a bit late relative to most of the "good old days" participants I've observed. They had Pascal, I had VB5 -- they had ed, I had ... well, VB5 ... they had libraries, I had BBSes, they had printed manuals, I had CD documentation ... the list goes on.
The Beginning
I stumbled into programming during high school (I'm excluding the
10 print "derek", 20 goto 10fun that so entertained me in grade school). I was responsible for inputting data penned in by customers entering contests, signing up for mailing lists, etc. into a database. Every time I re-entered the same postal code three times in a row I could feel my brain shrinking.Within the friendly environment that was VBA (in Microsoft Access '95), I managed to script a form into filling in a few fields for me when encountered with one of the most popular postal codes. I was hooked -- entering the addresses had been transformed from mind-numbing boringness to a creative exercise in trying so save as many keystrokes as possible.
My initial fondness for VBA (and Microsoft's influence on programming curricula in the greater Puget Sound area) led me to a Visual Basic programming course at a local community college. I enjoyed it, and it eventually led me to my first programming job (which really was a web design job, but nobody seemed to mind -- perhaps because I was still in high school, or perhaps because I was making $8/hour).
In these early years of my career (before it was officially my career, I should add), there was never a distinction between language, framework or development environment. My language was Visual Basic, I called Visual Basic functions, and I did all of this using a product called Visual Basic ... the explosion of Active Server Pages brought Visual InterDev along for the ride, and C++ tasks were handled by Visual C++. There was always a "right" tool for the job.
A Hot Cup of Java
After a couple of years of making ASPaghetti, I started toying with a language called Java. I use the word "toying" quite intentionally, because at the time my best description of it would have been "language used to make cool buttons on Web pages". I had been quite ignorant of the growing Java juggernaut, but our company had recently bought some Oracle licenses (it was the Dot-Com era, why not?) and it seemed to be the language of choice for folks in that camp.
I quickly moved from "toying" to "using". For a Visual Basic programmer, Java was like heaven -- actually, Java was heaven. After two weeks of using it, I was ready to have the "good old days" conversation about old Visual Basic. Goodbye class modules, hello beans!
One thing that was very different in the Java world, and it was new to me, was choice in environment. In the Microsoft world (and this is still true today), there was a supported development environment released with the language ... in Java, the tutorials were telling me to set a CLASSPATH environment variable (bad advice, by the way --
-cpis much less painful, but I digress) and use the editor of my choice. Using Notepad was fine for my "First Cup of Java", but I knew I'd be needing auto-completion and a "debug toolbar" before long.My quest for the perfect Java IDE never really finished -- I started with Oracle JDeveloper (basically an early version of JBuilder), and later dabbled with VisualAge, Webgain, Netbeans, JBuilder itself, and just about everything else that came around ... I never fell in love with any of them, but most were a pretty nice step up from the development tools I had worked with previously. They all had the basic features I was looking for -- syntax highlighting, intelligent completion, click-to-run, debugging ... none of them stood out, but they were all Good Enough[tm].
The Dark Side
There is a dark side of the programming world. Some are never exposed to it ... some have only had enough exposure to be scared by it. The dark side consists of a wide network of programmers, about 1 to 2 for every 10, who throw away the rules. They run strange operating systems, they spend free time on weekends experimenting with programming languages you've never heard of (Hask-what? Eif-who?) ... and they don't use the same tools that you do, to say the least.
I remember the first time I witnessed a member of this "dark side" in action. I had wandered into the cubicle of one of our recent hires, a long-haired "Unix guy" who was in the midst of a rather furious coding session in a very strange looking editor (Vim, for the curious). Watching him operate his editor was truly an experience. He was working at a pace I'd never seen before, his cursor flying around the buffer like a pinball. I was like a child seeing a magician for the first time (that hat was empty!).
I rudely interrupted his session -- in part to marvel at his proficiency, but also to ask some questions about his current project. He walked me through the code he was working on, and the artistry continued -- he seemed able to will his cursor around the buffer with the power of his stare, as if he was simply "thinking it" there. I'd never seen anything like it -- he wasn't using his editor -- he was his editor.
I was forever changed. I had seen what the dark side was capable of, and I wanted a membership card. Going back to my IDE was a depressing affair -- I tried -- and I tried hard, to replicate the genius I'd just seen. He had clued me in to a couple of his tricks, which I tried to emulate. I took a tour through my IDE playground again, trying to find one that would enable me to perform the magic tricks he executed so effortlessly, but I couldn't.
I spent a week or so trying to convince myself that all of that "other stuff" in my IDE made up for what it lacked in the editing department. I was partially successful -- I mean, my debugger sure looked a lot fancier than his (gdb, for the still curious). That had to count for something. And that intelligent completion -- surely I couldn't live without that, right? Right? Not exactly ...
I made a conscious effort that week to think about each feature as I used it. Intelligent completion? Sure, it was helping me code, but how much? With this in mind, I noticed that I was doing some really idiotic things, like typing
n-eand then waiting a (brief) moment for the completion window, in some cases using my arrow keys to find the appropriate completion, and selecting it. This, as opposed to just finishing the keyword ...x-t... surely, somebody observing from the dark side would be shaking their head at the sight of this. I had to do better. My tools were good, maybe even great, but they still weren't good enough.I Think I Can ...
With the help of a Unix shell account, I decided to take a tour of the dark side. I did a bit of research (Have you heard of this fantastic new search engine called Google? No, no -- l-e ... yeah, that's it -- now search for "cigar!"), and found that the dark side was in the midst of a civil war -- the Emacs-folk vs. the Vi(m) folk. Oh boy ... I was going to have to choose. A bit more reading convinced me that what I was seeking (magical editor powers, that is) could be achieved with either. I'd seen what Vim could do, how about this Emacs thing?
My first experience with both editors was a disaster ... in Vi, I did finally stumble into the proper mode for getting characters into the buffer, but it wasn't a pretty process (and it certainly wasn't intentional). Emacs started out a little better, but I couldn't figure out for the life of me how to quit -- control-s? control-q? And yeah, the fact that I kept toggling flow control on the terminal certainly didn't help. Finally, I figured it out -- control-z! Pressing that makes Emacs go away, problem solved. Alright, time for some magic tricks! Oh, and it took a couple of hours before I realized that I was suspending it rather than quitting. When you're accustomed to control-q,
\C-x\C-cis a long ways away. Fortunately, the tutorial (\C-ht) got that out of the way in a hurry.Armed with some documentation and a bit more time, I ended up giving each editor a fair shake. In no time, I was moving around buffers pretty well in Emacs -- not exactly comfortable, but reaching for my arrow keys less and less (not because it made sense to me, but it had been suggested that this was the path to magic, so I figured I'd try). Vim was starting to become less painful as well, although the mode switching was really causing me to do some amazingly stupid things (something tells me Vim users all have rigorous backup schedules). in any case -- I figured that to become a magician I would need to focus on one editor, and my laziness led me to Emacs (sorry Vim, too much early mode pain).
Magic Tricks
It really didn't take too long to reach my goal -- I had to re-train a lot (OK, nearly all) of my editing instincts, but before long I was performing buffer magic tricks of my own. By this time, I'd found other "dark siders", and I was extracting as much information as I could from them ("Hey, how'd to swap those characters?") ... each tidbit I picked up, I would force myself to use for a day, and inevitably, I'd end up using it 100 times the next week, wondering how I ever lived without it.
That's really the Zen of Emacs. When I encounter people who see me using Emacs, they typically assume that I use it because of its customizability. That's a nice feature, but it's not the reason to use Emacs. The Zen part is all there in the base package -- even without a
.emacsfile (a Lisp file read at startup used to customize Emacs). The "magic tricks" that turn you into an editing wizard aren't really tricks at all -- they're core features. Once you learn these core features, it's astounding the magic you can do -- and you can do it everywhere. You can swap arguments in C the same way you swap words in a text file -- you can autofill your comments just like your paragraphs -- rectangle insertion makes block comments as well as it adds a shared prefix -- dynamic abbrevs (rich, but unintelligent completion) work everywhere -- and all of this stuff works whether you're editing C#, Javascript, CSS, Java, XML, Ruby, Lisp, ... the list goes on. And trust me, these features only sound exotic until you depend on them.That's not to say you can't add useful tricks on top of these core features. The point is, you don't have to. I think a lot of people avoid Emacs because of this misunderstanding. The truth is that Emacs isn't scary -- you don't need to know a thing about Lisp, Emacs Lisp, or Unix (Emacs works wonderfully as a native Windows binary). You don't need to have a
.emacsfile, you don't need a PHD in Parenthesis to be a magician. You do need to give it some time, but it will pay you back.Emacs doesn't seem like much at first. It takes an hour or two to get the basics down, at which point a new user can probably use it with almost-Notepad-level efficiency. It takes a lot more time to get to the next level, but once you do, you can't go back. I remember explaining to an early Emacs user how much I loved prefixed arguments (numeric arguments to alter command behavior). He laughed at me like I was joking. I mean, that's fair -- prefixed arguments do sound like a silly "border feature" if you've never worked with them before. And hey, it took me a while to pick up on them. But now, I use them many times daily.
Stretch Yourself
Another thing you get with Emacs is flexibility. Have you ever wanted to experiment with a new technology, but avoided it because you were too comfortable in your existing programming environment? Come on -- you saw that Ruby on Rails screencast, right? If you're an Emacs user, you can be writing C# on Windows Monday, Ruby on Mac OS Tuesday, and Python on Linux on Wednesday. In each case, there are language-specific tools to use, but the place you spend the most time -- your editor -- is consistent across tools and platforms. Virtually all the time you invested in learning (and customizing) the editor comes along for the ride each time. Emacs lowers the bar.
OK, I know -- you're not convinced. You love -- no, you love your IDE. I've been there. How about 5 years ago, though? Were you using the same IDE? Were you even using the same language? Me neither. How about in 5 years -- do you think you'll be using the same language? The same tool? Really? If you did switch, how much knowledge from your last development environment transferred? You might think that "it doesn't matter" -- heck, I probably would have said the same thing reading this 5 years ago ("bah, I'll just learn a new IDE when I pick that language up"). It's difficult to explain how much you can gain from mastering an editor -- you just have to experience it. Have you ever learned a keyboard shortcut in a program, and wondered how you ever lived without it? Gaining proficiency in Emacs is like that feeling times 1,000. Emacs is never having to press the same button 5 times in a row.
It's powerful, even if it doesn't sound like it. After several years of using Java, I needed to switch to C# for a few projects which integrated with native Windows libraries. My development process hardly changed in the process -- every trick I knew for editing, buffer management, compiling -- it all transferred. With the recent shift towards standards-based Web-centric applications, and working for a startup, I'm writing C#, JavaScript, Java, CSS, C++ and XML regularly -- all within the friendly confines of Emacs. And yes, I'm writing this blog post in Emacs (using a custom RELAX NG Compact schema in NXML mode, for the still curious).
Emacs Hacks
Getting started with Emacs can be a bit intimidating at first. It's a community run by dark-siders, and they have a tendency to assume you're a rocket scientist. Wading through the documentation and getting out of the gates is the hardest part (it was for me -- I'm not even a model rocket scientist). I'm going to dedicate a few posts on this blog (in "hacks" style, sans the book-length depth) to helping you do just that. I'll probably bias it somewhat towards installing and using Emacs on Windows, since it's quite a bit easier on Linux (
apt-get install emacs21doesn't make for a very interesting blog post).If you're not convinced -- I understand. And it doesn't bother me at all. I have nothing against language or environment-specific tools. I use them all the time -- debuggers, static analysis tools, inspectors, refactorers -- you name it. You don't have to dump your IDE -- you can even use them side-by-side if that's more comfortable for you. My point is that mastering a flexible editor (Emacs or otherwise) can make you a more versatile, more productive developer. It might even make you a better developer. No Elisp hacking required.