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