Senior Java developer, one of the top stackoverflow users, fluent with Java and Java technology stacks - Spring, JPA, JavaEE. Founder and creator of http://computoser.com and http://welshare.com . Worked on Ericsson projects, Bulgarian e-government projects and large scale recruitment platforms. Member of the jury of the International Olympiad in Linguistics and the Program committee of the North American Computational Linguistics Olympiad. Bozhidar is a DZone MVB and is not an employee of DZone and has posted 81 posts at DZone. You can read more from them at their website. View Full User Profile

Why Not Emacs?

12.28.2012
| 9600 views |
  • submit to reddit

 

Every now and then a “hardcore” programmer comes and mocks you for using a “sissy” tool like Eclipse or IntelliJ. Real programmers use emacs and vim. If you are lucky and the other developer has some arguments and social skills, you are not mocked, but rather explained how you are wasting a lot of precious time with your IDE and once you get used to emacs or vim, you’ll realize how irreplaceable they are – it will be like going into the 3rd dimension and wondering how you’ve ever lived in 2D.

Zoom out. Eclipse and IntelliJ are pretty much Java-oriented (though there are plugins for other languages). So if you are using ruby, python, php, or whatever, then probably emacs is the best thing you can get. But let’s see what you absolutely need your editor/IDE to do for Java:

  • debug – number one priority. If you can’t put a breakpoint and run your whole application in order to simulate a specific case, then you are left with poor man’s System.out.println(..)
  • quick navigation through the code – if you can’t go to a class with 5 keystrokes (no mouse), if you can’t go back to where you previously edited, if you can’t see which classes subclass a given class or, most importantly – see which methods call a given method, then your code analyzing efficiency drops remarkably. And in a typical software project you read and analyze existing code way more often than you write new code
  • refactoring – you want to change a name of a method. Add or remove arguments. Move a class to another package. The IDE makes the appropriate changes everywhere in the entire project and you don’t have to go and rename stuff manually (missing some of the occurrences)
  • auto-completion – that’s important, but not because it saves you 4 keystrokes. It shows you the possibilities you have. When you work with an unfamiliar (or forgotten) API, you are not sure which method does exactly what you want. So you experiment by typing a name you suppose you need and read the attached documentation to that method
  • coloring and highlighting- syntax coloring is a basic thing, and is not that important. But highlighting – when you select a variable you must be able to see where it is used.
  • tools support – your project is build and managed with maven. You need your editor to be able to pull dependencies from the repository and attach them to the classpath. You need to be able to save parameterized build configurations as well. You need Tomcat/web server hot-swap/hot-deploy – changed code to be directly replaced at runtime. Checkstyle. Unit-test integration.
  • advanced search and replace – regex search, method search, wildcard search, etc. Priceless in many cases, in which you should otherwise create a separate program that handles to complex find/replacement logic

All of the above are of huge importance to productivity. I wouldn’t drop any of them (especially the “call hierarchy” feature, which shows which methods call a given method). How many of them are supported by Emacs? In its basic form – zero, but that’s not a problem – there’s JDEE, which provides some Java support. Does it provide all of the above? No.

At this point I can safely wrap-up the publication, because I’ve given the answer – I’m not going to use emacs because it doesn’t give me what an IDE does. But I know the arguments that people will bring up, so I’ll add some more paragraphs.

In emacs you can do everything. You can write a Lisp script that sprays pixie dust on the code and makes all bugs disappear. And you can implement anything that’s missing in JDEE. You can. You can also probably write your own servlet container and web framework. But that’s what you do at home, when bored and have nothing else to do. If you are working on a project, you don’t do these things. They take time, and this is time nobody is going to grant you in order to play with your favourite editor. And even if you do, they will be buggy and feature-poor at first.

In emacs you can type code really fast. I don’t know, probably faster than in Eclipse. You can define all sorts of shortcuts, macros and templates and write code blazing fast. And that’s great, if you are a typist. Programming, on the other hand, requires way more thinking and analysis than simply writing code. I don’t know the percentage of time of a developer is needed for the actual typing, but it’s less than 20% for sure. And by the way, you can define templates and shortcuts in eclipse, too.

So, you want me to use an editor that makes me use more time and effort to perform day-to-day development tasks, and to do that I have to spend a lot of time learning and customizing my editor (and then probably store the configuration somewhere safe, so that I can reuse it across computers/jobs)? And I know why you like that. Because it’s tough, challenging, and makes you stand out of the “masses” that use these lame IDEs. It’s not something most people would admit, it’s a psychological effect. And I have no problem with anyone using emacs or vim. Just don’t feel elite for that.

So, why not emacs for me? Because Eclipse is better for Java.

Published at DZone with permission of Bozhidar Bozhanov, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Wal Rus replied on Fri, 2012/12/28 - 3:18pm

Well, I think it all comes down to exercising your memory way more when you use emacs. Since emacs isn't as helpful as Idea/Ecl. at contextual finishing of object, method var names, you tend to use your head more. I use a full fledged IDE but recognize the strength of emacs. Back in the day I used Kawa (as unhelpful as emacs). Using kawa required you to rely on your memory rather than autocomplete (though kawa provided limited autocompete). When  I switched to IDE i felt like the horizon of my design ability and ability to see code shrinked a bit.

Stephane Vaucher replied on Fri, 2012/12/28 - 9:52pm

Vim is useful if you need to remotely modify code without GUI access. Emacs has a Lisp interpreter, so it is potentially more powerful than any IDE out there. For general edition purposes, stick with those two. If you have specific language needs, then go with an IDE with good language support (e.g., that offers the features you mentioned). But, you should always be able to work without your IDE (e.g., know how to compile and deploy your code).

John J. Franey replied on Sat, 2012/12/29 - 4:23pm

Emacs and eclipse do not overlap in features.  There is not an either-or decision.  I've been developing java for 12 years and used emacs on C++ programming for 10 years before that.  I discovered eclipse IDE in 2002, I think, with eclipse 2.0.  I had been using some emacs module for java development (maybe JDEE?).  Even then, I switched eagerly to eclipse for java, but still am fluent in emacs and use it in every case I need a smart, quick editor, for example non-java programming (shell, scripting).

For me, the most attractive feature of eclipse is automatic incremental compiling.  I would have stayed with emacs much longer if I still would have to manually trigger a compile.  Eclipse plugins for other languages can implement automatic incremental compiling, too, and, so for any language I use, if it can benefit from such a feature, and is implemented in eclipse, I will use eclipse.

So, yes, I am not a real programmer.  My brain is too fallible and I don't count on it to catch various errors.  I rely on eclipse to show them to me, and because the ide finds them first, I work faster.   'Computer aided programming' is about letting the strength of the computer make up for the weakness of the human programmer.  If anyone has issue with that, so what?  Are they going to yell if I come into work on a wheel-chair?  I don't have to be concerned with them.

Chris Bilson replied on Sun, 2012/12/30 - 3:52pm

Hi,

First off, from the tone of your blog post, I believe you've been traumatized by encounters with rabid emacs/vim users with poor social skills. Not all of us are like that. In lieu of an actual apology from those who traumatized you, please accept my apology on their behalf. I'm sorry for what happened to you and only hope the perpetrators have since or will soon mature to the point that they quit harassing people about things like this.

In your post you mention several capabilities that IDEs have that are not available in editors like emacs or vim. Some of them are complicated features that I am sure took the IntelliJ/Eclipse developers years to get right (assuming they actually _are_ right), but would be *possible* to implement in text editors. Some of them would be practically impossible (such as graphical visualizations of code structure), or at least not really appropriate for something that defines itself as a "text editor." So the idea of there ever being feature parity between IDEs and text editors is not valid.

You also estimate that developers spend less than 20% of their time actually typing code. I completely agree with this. 

I further submit that the time developers need to spend on _debugging_ code is also far below 20%. I would also extend that to refactoring, looking at inheritance trees, and other activities that we use IDEs for. 

Instead of these activities, developers would be well served by spending more of their time _thinking_ and talking with other developers to find holes in their reasoning about software and how they are going to solve actual problems. Always working in the IDE leads to excessive focus on solutions, and then to solutions to problems created by the first "solutions", then to the problems of those solutions, ad infinitum. 

It's a shame that developers of IDEs haven't spent more time thinking about the actual problems their users have. If they did, I believe they would see that one giant monolithic tool that has every feature a developer might possibly use is not only overkill (how many only ever use a handful of an IDEs features? Why can't I have these features ala carte, in a way I can use them from scripts or other tools?), but also completely misses the mark, since there is no way an IDE can make you stop and think before you create more code you need the same IDE to debug, refactor, visualize, or even understand. Thinking is absolutely the best thing you can do in this situation, and IDEs don't have that feature yet.

I think this may be where some of source of the frustration lies for the editors-over-IDEs crowd lies. It's really very difficult to work on a codebase that was done "all-IDE" without the same IDE (in many cases, event the same _version_ of the IDE.) I've even seen cases where you couldn't build or even _deploy_ the application without using the IDE. Hence text-editor-only developers lower pain threshold and higher whininess factor.

Hopefully we can someday move past this argument, which appears to have achieved some state of zombie-undead-can't-be-stopped, and focus on the real enemy: thoughtlessness.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.