[axod]

I do :) And I enjoy having nice neat tight code as a result. I don't need the completion, shortcuts etc, because I "know" the code base. Sometimes I need to grep etc, but knowing, and having a handle on the entire codebase is pretty useful for when you need to do big sweeping refactoring.

[Tamerlin]

I use an IDE, and I write clean, tight code. I don't see your point -- part of it is that I have far more important things to do with my life than learn the API, so code completion is a great resource for me when I'm working with 3rd party libraries or Java libraries that I don't use regularly.

Debuggers are another benefit to using an IDE.

Running my app within NetBeans also makes it easier to deploy and launch a web application, so that's another bit of tedium that the IDE alleviates.

For me it's a win-win. It takes care of grunt work, I take care of code.

[axod]

I also hate debuggers. Tried them, don't like them. They're great for when you don't have the source code and need to reverse engineer something, but for finding bugs, I think they're terrible.

Different people like different things though. It sounds like you're doing a very different kind of development than I do - that whole scary J2EE beans webapp enterprisey stuff.

[Tamerlin]

Well, not quite J2EE, but it is Spring based. Spring relies heavily on magic that makes tracing code very difficult without a debugger. It wasn't my choice, and I wouldn't choose it again, but at least it's better than J2EE.

[ewjordan]

And I enjoy having nice neat tight code as a result.

Huh? Being able to look up functions and read the Javadocs without grepping somehow makes code messy, now?

I don't need the completion, shortcuts etc, because I "know" the code base. Sometimes I need to grep etc, but knowing, and having a handle on the entire codebase is pretty useful for when you need to do big sweeping refactoring.

First off, the main reason people like code completion because it saves keystrokes. "syso CTRL+SPACE" is 6 actions, compared to "System.out.println()", which is 20. Not having to wait to compile to see whether doFoo(a,b) takes (Bar,Baz) as its arguments instead of (Baz,Bar)? Priceless...

Putting that aside for the moment...if it's even possible for you to know the entire codebase, then you're really just not working on a substantial enough codebase to understand why people like IDEs for refactoring; your refactorings are not even close to "big" or "sweeping". A heavy duty refactoring might touch a hundred files in a thousand places, and that's where you're going to end up with a lot of pain using grep (esp. since in large enough projects token names tend to get reused, so you really want something that understands the semantics of the language).

If a grep is all you need even in order to browse through functions, then you're probably not leaning on .jar libraries; you're definitely not leaning on any bytecode-only ones.

If you're happy with the command line for compiling + debugging, you've probably got a fairly simple test + deployment process, maybe just pure .java sourcecode with no testing on other devices or strange launch processes required; chances are, you're debugging with System.out.println instead of a debugger. That's fine for simple things, but it can be a major waste of time if you run into more sweeping problems that require a bit more exploration to solve.

Some more (possibly unjustified, to be fair) assumptions: you likely have not needed to profile your code, manage dependencies between different projects that by necessity can't be merged into one, hot-replace bytecode (a crucial feature for big projects), set up and maintain a Maven repo, work with type hierarchies complex enough that to need to check them to make sure you're not breaking things before you make changes, conform to specific code-formatting guidelines, sign .jars, test on different JVMs, work with code rewrite rules, pre-process annotations, maintain different .jar distributions, analyze logical dependencies, inspect generated bytecode, etc.

Yes, each of these individual things is something that you can accomplish with a few shell scripts and some elbow grease, true enough. But plenty of people have to do all of this stuff all the time, working with projects that are too big for one head to handle, and it really helps if you don't have to dig into twenty shell scripts each time you need to change something about your project. It sounds an awful lot like you're suggesting that they're in some way inferior for not wanting to manage all this complexity by hand; that would be a big mistake. Plenty of coders much smarter than you or I rely on IDEs every day to get their jobs done, and they create quite good code.