[axod]

My IDE is the terminal. I don't want that in a text editor.

I use a text editor to edit text, and a terminal to do everything else.

As long as it can do syntax highlighting, copy paste, line numbering, can show files/dirs in a tree so you can select files easily, I don't want anything else.

Obviously I can understand that other people love clicking on "create a function" in their IDE, or tab completing variable names, or clicking on "build/run". But it's just not for me. Even the quote/bracket auto-insertion in textmate drove me crazy until I disabled it. All that extra crap 'refactor!' 'language bundles' etc.

<anecdotal>

The code I have seen (Java) produced from programmers using IDEs has been universally horrible. Full of duplication useless boilerplate and general rubbish.

</anecdotal>

If you were writing a novel, would you have a menu with common book 'patterns', or tab complete the character names? For me, it interrupts my flow.

There is a popular myth that you 'need' to use an IDE to code Java. Which is just ridiculous. Perhaps it's a self fulfilling prophecy though. Code produced by IDEs isn't nice to look at so you need to edit it in another IDE, or spend an hour cleaning out all the rubbish.

</rant against IDEs which I detest>

[wwortiz]

You are much better of using an IDE with java unless you want to write everything yourself using barebones and then do lookups for obscure bits and pieces that are only a simple completion away in an IDE.

Enjoy your elite way of doing it though.

[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.

[Sandman]

Yeah, well, there were some days when I thanked god for the Eclipse's refactoring capabilities. I had to refactor large amounts of code at one time and had I done it by hand, it would have surely taken a lot more time and would have been a much more tedious process. Not to mention that I would've probably introduced one or two more or less subtle bugs while doing that. This fact alone is enough to make me assured that, when writing code for a large enterprise app, IDEs just can't be beaten.

[axod]

>> "when writing code for a large enterprise app, IDEs just can't be beaten."

For that case, then yes you're probably right. Thank god I don't write 'enterprise apps'. IDE's are good for getting mediocre productivity out of bad programmers.

[ewjordan]

IDE's are good for getting mediocre productivity out of bad programmers.

No, that's what Java is good for.

IDEs are good for maximizing the productivity that any programmer gets out of Java. Otherwise the best Java programmers wouldn't use them.

[axod]

Anecdotal again, but every worthwhile programmer I've known does not use an IDE. But then as I say, a lot of this is semantics. My terminal, and my brain, is my IDE.

[ewjordan]

Anecdotal again, but every worthwhile programmer I've known does not use an IDE.

Not going to touch this other than to note that at Google, IBM, and Sun, most of the Java devs use one of the big 3 (Eclipse, Netbeans, or IntelliJ), you can certainly ask around if you doubt this.

[axod]

I don't really look to big corporations to decide what to use. That was the whole reason I started a company.

Big corporations do things that make sense for big corps. One is to treat programmers like factory workers and have them all use standard coding styles, IDEs, etc. Everyone is just a cog and easily replaceable.