Sunday, January 19, 2014

The power of Eclim vs. the stranglehold of IDEs

It took about a year of my professional programming career for me to grow out of IDEs. At the time I was working on a very large project (read: over a million lines of code) and of course inexperienced to boot. On day one, I was given a netbeans installation, and I was wowed by the code completion.

My first C++ development was done on Code::Blocks, and I believe I used JBuilder on my first java programs. At the time it simply "was the way," because I had followed guides that led me there. I didn't know that it was a giant horrible dominating slow layer on top of powerful highly optimized tools, and besides, I was so much slower to think than to write.

There were a couple things about netbeans that drove me crazy. I found that the project was so big, code completion popups were slower to appear than to type everything out myself. Crashes led to lost work. My favorite though, was new file creation. If you used netbeans to make the file, it would hang for sometimes a couple minutes. However, you could get around this by making the file from a terminal, and netbeans would pick it up right away.

Going without an IDE, a million lines at a time

I went cold turkey one day and cannot have been happier. I learned more than just :q!, :w, and :wq in vim, and found myself with a natural, fully-fledged scripting language beautifully molded into the editor. It takes 15 minutes to create auto-comment commands, helper for internationalizing a template file, and so so much more. I was free.

I found that I was even more obsessed with type-safety, and clear, reliable method names. I learned grep really well, and sed, and find --exec...

Not remembering a method name led to my setting up project documentation generators. Needing to know which classes did what turned me into an encyclopedia of sorts; the other developers would usually ask me about the code in a subsystem that neither of us had touched since last May.

The problem with IDEs is they are written...backwards. The culture of *nix is to make features out of existing tools. IDEs do use existing tools to ease compilation and debugging and more, but usually by, say, pretending .classpath doesn't exist and creating a new, unintuitive, unnecessary graphical editor for a simple xml file. And then, all of the features in powerful mature editors are slowly rebuilt from scratch. IDEs don't care if you love emacs or vim or any other hardcore editors out there, they think they know what you want better than you do.

Eclipse is literally a home-grown window manager, running a home-grown file browser, housing a home-grown editor, with a tremendously complex plugin API if you want to extend it. Plugins are great, but sometimes I just want simple inputs and outputs that I can leverage from my own context.

I tried Vrapper, an eclipse plugin that "vim-like editing" to the main editor, but it had so many issues. Rectangular select didn't work for me, vim-style redo/undo didn't work for me, ^C wouldn't trigger <ESC>, and the various popups at different timing made muscle memory unreliable.

It isn't Vrapper's fault - it is, after all, re-implementing a very complex interface from scratch through plugins to a very complex engine, instead of querying a very complex engine from a already-built complex interface.


Eclim, the best of both worlds

I tip my hat to the creators of Eclim. It has automatic imports, scope-sensitive refactoring, type-safe autocompletion, project tree browsers, error reporting, and provides helper methods to edit .classpath should you desire them. All of these features are simple vim functions, provided by a plugin that talks to a headless eclipse daemon.

Eclim has proven to me in just three days:
  1. that its fast
  2. that its powerful
  3. that it stays out of your way
  4. that it has great docs
  5. that it has very few bugs (error reporting may get out of sync with your edits)
  6. that it has almost every feature you want
  7. that its easy to install
The best part, by far, is that if you have any gripes with the way it does things, you can probably make it work how you want with just a little vimscript knowledge.

We live in a world of awful IDEs and powerful editors, and its about time someone unified them.


  1. Thanks for sharing your knowledge.

  2. Further, it's often when people try old jobs in new ways - that they just make up on the spot without thinking through - that they get hurt too. So pay attention to that little voice inside of you and you'll be much more likely to stay safe!work sharp 3000