Saturday, November 29, 2008

Why I've abandoned Eclipse for Emacs

Maybe this isn't a big surprise. I've always used emacs, even when using Eclipse. I'm used to emacs, and I use it for absolutely everything: shell, mail, task planner and more. For a while, though I did not do most of my Java coding in it. There I mostly used Eclipse, unless I was just doing something quick. After all Eclipse has great tools for refactoring, automatic imports, quick detection and correction of errors, and more. It's a really great product. Not only that, but it's unsurpassed at quick unit test cycles, mostly requiring no complication.

Emacs has none of that.  But it does have a number of things going for it, and because of these things, I've stopped using Eclipse entirely, and have continued to be productive over the last few months using only emacs.  Here's why:
  • Editing.  Emacs is a great editor, unquestionably better at editing than Eclipse. For example, I can do comment formatting extremely quickly in emacs (Meta-q). It's possible to do this Eclipse as well, but it's less flexible and requires more interaction. There are many similar minor things that make emacs a better code editor, as far as textual edits go.
  • Lack of projects.  Emacs is unconstrained. Editing a file for Project A, I can switch to a file in Project B as quickly as I can switch to another file in Project A. Emacs does not care about projects, which means it can't give you all the goodies Eclipse can, but it also doesn't tie you down in the same way Eclipse does. 
  • Speed.  This is probably the most important reasons I've been doing everything in emacs. There are many different kinds of speed, and most of them are important. Emacs, being lightweight in comparison to Eclipse, has greater speed of editing. Eclipse has greater speed in the change/compile/test cycle, which is very important. But the one that seems important to me is that Emacs has no large pauses, where Eclipse does. I switch projects a lot, and every time I do it seems like Eclipse has to build itself for 10 minutes. IntelliJ doesn't have this problem, but that's because it does less up-front work; everything else is slower. When I go work with someone who uses Eclipse, we often spend the first 10 minutes just waiting for Eclipse to build the project. It's very frustrating. If we were using emacs, we would already be on our way.
  • Reliability.  Eclipse is a large moving part, and it is one that seems prone to failure. Once you get burned a couple of times by problems that only are in Eclipse, getting that bit of unpredictability out of the system is a time-saver.  Emacs can get that way too, especially if you use something like jdee-mode.  I like to keep it relatively simple in emacs, though. 
  • It's emacs. This is somewhat tautological, but the truth is that once emacs is handling several important tasks for you, you get more and more benefit by bringing activity into it. This is why I can read a mail in gnus (using nnimap), store it in my to-do list in org-mode, and then find some relevant piece of code in emacs and link it to the task in org-mode. It all fits together beautifully.  And whatever you need is there for you, somewhere.  Writing a javadoc and want to put a diagram in there?  Emacs can make it easy; use artist-mode.  There's so much stuff to discover here.

For programming in Java, I just use java-mode, but I've written a few things to make my life easier. I use anything-mode to quickly go to any Java file, ffap so I can quickly open up include files, and use M-x compile so I can jump to errors. I've also written a little import management system that I'll post on this blog shortly. So I find that I'm reasonably efficient.

All in all, my startup time is much quicker for emacs, but I lose time on editing. I'd recommend emacs over Eclipse if you tend to work on a variety of tasks and you use emacs now. If you spend most of your day writing Java, Eclipse is probably going to be better suited to that.

8 comments:

Mike said...

Have you written the post on the import management system? I'd be interested to read more. (As would, I'm sure, many others.:-)

Andrew Hyatt said...

I haven't done that yet, thanks for reminding me! I'll try and post something about it soon, but I need to open-source it first.

Andrew Hyatt said...

Mike, I've finally done it:
https://github.com/ahyatt/code-imports

Anonymous said...

The only reason I use Eclipse is because it provides you with a dropdown list of methods, variables, etc... as you code.

If emacs did that, I'd gladly switch to it.

Anonymous said...

@Anonymous: look at the eclim and emacs-eclim projects, i didn't try them, but they might work

Chuck said...

I am curious, you say: "All in all, my startup time is much quicker for emacs, but I lose time on editing."

but in your blog you go on at length how much faster emacs is than Eclipse. Do you mean specifically for Java? Would you elaborate?

Andrew Hyatt said...

Chuck, I meant that although basic editing is much quicker and better in emacs, things in Eclipse like autocomplete and inline compilation errors save a lot of time.

These days I still use emacs because it still is faster to do the easy task.

Gino M. said...

Just stumbled on this post in the middle of my 247th Eclipse-emacs vacillation. As you point out, and this blogger states somewhat bluntly, despite the various pros/cons, the biggest barrier for experienced developers seems to be the human nervous system itself.

Each time I start working with emacs again, I try to force myself to learn the default key bindings, thinking that if I were to someday need to use a vanilla emacs installation that knowledge would come in handy. But being so used to Eclipse, the binding and behavior seems awkward and constraining. Old habits die hard. So given how unlikely it is that I'll need to work w/a fresh emacs install, I'm starting to think it would be wise to instead customize emacs to be more compatible with my own finger memory. Although the thought of "Eclipsifying" emacs seems somewhat perverse, perhaps for experienced Eclipse users it would be the best way to leverage their existing conditioning to get the most of out of emacs...