Deprecated: Assigning the return value of new by reference is deprecated in /home/edelabar/ on line 472

Deprecated: Assigning the return value of new by reference is deprecated in /home/edelabar/ on line 487

Deprecated: Assigning the return value of new by reference is deprecated in /home/edelabar/ on line 494

Deprecated: Assigning the return value of new by reference is deprecated in /home/edelabar/ on line 530

Strict Standards: call_user_func_array() expects parameter 1 to be a valid callback, non-static method GoogleSitemapGeneratorLoader::Enable() should not be called statically in /home/edelabar/ on line 311
Hammering Screws: Programmers and Tool Blindness at Eric DeLabar

Hammering Screws: Programmers and Tool Blindness

screws.jpgIn my last post I told a half-truth by ending with “If you need me I’ll be uninstalling Eclipse.” Honestly, I only removed it from my laptop because I rarely do any real Java development directly on my laptop, and should I need a quick code editor I have TextMate which handles most of my coding needs pretty simply. However, the commotion that the statement caused is what I’m going to address in this post.

If all you have is a hammer, everything looks like a nail.
-Bernard Baruch

To continue with my tools theme I’m going to address what I’ll call “tool-blindness,” the mentality that the tools you have and know how to use are perfect for every situation. In other words, if the tools you have require you to hammer screws then by-god you’re going to hammer screws.

Recently there has been a grass-roots, developer movement at my employer to switch from Ant to Maven. I love Maven, it’s leaps and bounds better than the way we were using Ant. (Notice I didn’t say Ant in general, I’m only planning on starting one holy-war with this post!) My last four projects have used Maven, and it makes the build and deploy process significantly easier, especially when it comes to dependancy management. However, everyone’s favorite Java IDE does not play well with Maven because Maven’s standard directory layout is significantly different from Eclipse’s convention. People have attempted to alleviate this problem by using the M2 plug-in and following the instructions here, but the result still feels like you’re forcing Eclipse to do something it doesn’t want to. Add that to the fact that the version of Eclipse we’re using crashes at least once a day, and you should be able to see why I’m looking for alternatives.

In short, our metaphorical hardware (the build process) has changed from nails to screws and our hammer (Eclipse) is no longer the best tool for the job. However, we’re still using the hammer because it’s what everyone knows how to use and only a few of us are not tool-blind enough to look for something else. It also doesn’t help that the alternatives that play nicely with Maven, namely IntelliJ IDEA and Textmate-and-a-shell are not “free as in beer.”

As I mentioned in the comments of my last post, Eclipse has been feeling a little more like this tool than this one. So maybe it’s time to ask which tool you really want on your tool belt.

In an interesting turn of events, Alex Vazquez over at Wufoo/Particletree is going through the same process with a different perspective. Alex is moving, based in part by recommendation and in part by language choice, from Java on Eclipse to PHP on Textmate, and he seems to be liking it so far. Alex does, however, sum up Eclipse rather nicely, and coincidentally within my theme:

The right development environment can save a programmer countless hours and is like a hammer in the carpenter’s tool belt. Since my background was in Java, my preference was for large sledge hammers and my development environment of choice was the de facto Java IDE Eclipse. It has a number of amazing features like autocomplete, refactoring and hundreds of plugins for every task imaginable. It’s no secret Java requires mountains of code, but Eclipse was made to move mountains.
-Alex Vazquez

I think Alex really nails (pardon the pun) the fact that if you’re going to be doing Java Enterprise development you need an IDE that can handle it. You need something that generates the code and provides the re-factoring tools and autocompletion to make it possible to “move mountains.” However I’d like to pose a question to all Java developers who use Eclipse; how much of Eclipse do you really use? Besides re-factoring, code completion/generation, and cvs/svn/scm integration, is there anything else you couldn’t live without? Anything else that Textmate doesn’t do? (Besides run on Windows, we’ll save that tool for a different day.) Look at all of the stuff Eclipse does that you don’t use, is the added bulk really worth it? How much memory is your Eclipse process using right now? (Mine’s got ~254MB, 5x more than the next largest memory footprint, and my Eclipse process is basically idle.) Just my two cents, please form your own opinions, after all I’m just a kid who couldn’t possibly have any experience.

3 Responses to “Hammering Screws: Programmers and Tool Blindness”

  1. Roosevelt:

    I’ve always used the claw hammer VS pneumatic nailer analogy instead, but the point is still there. :)

    June 20, 2008 5:56 am

  2. Jim Bastard:

    Eclipse takes up a monster amount of memory. I’ve fallen back to using Dreamweaver just because its relatively lightweight and has intellisense for the DOM.

    June 25, 2008 3:34 am

  3. me:

    Thing i use in eclipse every day:
    -Auto-Build & run our webserver & build-path management [although build-paths are a tedious chore]

    -ctrl-click on a varible or type to see the code automatically and not have to go through tons of directory hunting for it. This is a huge timesaver.

    -ctrl-shift-t / ctrl-shift-r are similar to the ctrl-click

    -Auto-complete/Inline-documentation can be an enormous timesaver and you don’t find it in non-ide type editors like textmate.

    -Inline error & warning higlighter & problem’s browser. If I make a mistake, it’s highlighted right away. It of course doesn’t catch all problems, but it catches a lot of the small goofups that can really consume time when you forgot that semi-colon or something similar and have to go through another save-build-run-wait-wait-wait-error to have the problem blow up in your face.
    -A full featured debugger.
    -Litter your code with TODO comments and you have an automatic todo list!
    - The code outline can be useful at times (although textmate has this one)
    - The easy to use multi-directory/file diffing tools
    - The built in scm management tools — Occasionally, I also use the save history tools built in for more granular reverting.
    - And the basic features you mentioned.

    There are several features that I would use in eclipse, but don’t work with our particular software setup (we use the obscure resin server w/ struts 1.1 vs. tomcat w/ spring for example, which remove a bunch of eclipse feature ), or there are better tools to deal with the specific part, like cssedit2 for css editing.

    We don’t use the profiler since we don’t really have speed problems with our web apps.

    The only really bad thing about eclipse is it’s heavyweight nature. If eclipse wasn’t memory and processor intensive and was developed with a better gui, would you really care about using eclipse? No! It would completely pure awesome. Are there new features you can use to improve it? Of course!

    August 22, 2008 12:20 am

Trackback URI | Comments RSS

Leave a Reply