New Tricks for Old Dogs
"You can't teach an old dog new tricks." Like many senior developers (old dogs), I've been quite happy and productive with Emacs or vi. I could use an IDE if absolutely necessary, but since my management pays me to be productive that always meant going back to my core tool set when the pressure was on.
One reason Emacs (and, to a lesser extend, vi) remained such a productive tool is because I could always configure it to support my work environment. It didn't matter what the project language, source control system, or build tool was -- it just worked. It also didn't impose any of its own abstractions on the project, such as proprietary project file types.
"Wait, Tom, your biography says you are working on NetBeans!" That's true, but a couple of years ago I couldn't use it in my daily work, nor could the rest of my project team at the time. We had a short list of reasons why: it was too slow, the GUI was counter-intuitive, the binary project type couldn't be shared, and the code-completion database wasn't useful since we always ran a pre-release JDK. But the NetBeans team made huge strides with performance in 3.5 (and the work continues), 3.6 saw a very slick windowing system update, and 4.0 has an Ant-based open project system I really like.
Still, I did my NetBeans development using Emacs until a few months ago. What changed things was a very small feature you probably won't find in the marketing blurbs: when editing Java source, you can right-click on any identifier (such as
getToken in this example) and go to its source, its declaration, or search for its usages in other source files:
"Wait, Emacs can do that!" the diehards might shout, and to a certain extent that's true using its tags facility. But there are two reasons why I have never used tags for day-to-day source editing: tags are not syntax-aware, and the tags file needs to be regenerated to stay in sync with the source. You can regenerate tags files in your build, but I never figured out how the Emacs compile command can be tweaked to notify the tags facility that its database has been updated. I'm sure it's just a small amount of ELisp code, but at the end of the day my managers want working Java code, not ELisp.
NetBeans 4.0 addresses both of these issues. First, it leverages javac to provide a very accurate syntactic and semantic map of source files -- it knows what type of identifier my mouse is clicking on and where the source is that resolves it. Second, every time I start up NetBeans, it rescans all my source and class files to rebuild its repository, so that map never gets out-of-date.
Code completion is another IDE feature I never found useful because the database the IDE used for lookup was always out-of-date. But an accurate, complete mapping becomes very addictive to this old dog, causing me to bring the list up even for methods whose parameter list I am pretty sure of: it takes less than a second to get confirmation I remember it correctly, rather than risk a build error later. Oh, but the NetBeans editor uses javac for its background error checking, so all I have to do is stop typing for half a second and any errors will be underlined in red. What's the problem? Just move the mouse over the underlined area, and the javac error text is displayed as a tooltip:
These two features alone are responsible for cutting the number of my edit/build cycles down significantly. I understand that other Java IDEs have similar capabilities, so I am not claiming that NetBeans is the only answer here. But the features now starting to appear in these tools are leaping past what Emacs and other older editors could ever offer. Pretty GUI tricks may not interest old developer dogs, but simple productivity gains like these make us sit up and notice.