Let's talk IDEs

[Sidoh]

I think those kinds of standards are a little goofy when an IDE can just reformat code to your liking.

We have "standards", but it's really only to avoid conflicts due to formatting.

Depends on the IDE, but yeah, tools are the best way to enforce coding standards.  However, this only works if you have such tools, the tools are configured properly across the entire team, and everyone is using them.

If your IDE can't reformat code, it's not worth using.

Doing those things are much easier than expecting/trusting people to write code to conforming to standards.

[while1]

I don't disagree, but it seems you've obviously never had to work with dinosaurs stuck in their ways, resistant to learning new tools, or on a team where the technical leads use questionable coding standards.

[Sidoh]

Yeah. I'd high-tail out of any work environment like that. All of my engineering coworkers are within 2-3 years of my age and are all really excellent programmers.

[while1]

My new job is much better in this regard- smaller team and much smaller company means less room for dinosaurs not carrying their weight.

I always raise my eyebrows when someone I have to work with isn't a "power user"- meaning they don't customize their workspace, tools, desktop environment, or whatever to be the most efficient and productive (i.e. minimize the amount of repetitive things they have to do).

[Falcon]

Well efficiency and productivity is relative. What you consider efficient might not be the same for someone else. During an internship a few years back I was on a team where my mentor who was like 60 something used vi for coding, yes fucking vi. I asked him why not use an IDE or at least some kind of GUI text editor. He had me sit down with him for a few hours and watch him code. And holy shit was I amazed by how quickly he could navigate around, find stuff, and churn out code. He pretty much knows all of vi's commands by heart and both hands stayed on the keyboard the entire time, no need to move one hand off and use the mouse to navigate.

At that point I realized he was probably just as productive using vi than I was using eclipse, there would be no point in him switching to eclipse or me switching to vi. You simply work with whatever you're most comfortable with, which might be different from someone else but doesn't make it any more or less productive.

[Sidoh]

The thing is, there are IDE plugins that replicate 95% of the needed functionality in vim. I use IdeaVim for IntelliJ.

Yes, you can navigate around a couple of files with great speed and efficiency using only vim, but that's not where the most significant benefit in using an IDE comes from.

There are certain functionalities that IDEs have that stuff like vim just can't have without either (usually both):
a) an obscene amount of overhead involved with setup.
b) clunky, difficult-to-use interfaces.

Here are a few decent examples that illustrate this:

Let's say I'm using only vim while working in a codebase that's spanned by dozens of projects and there's an interface in a project that's upstream of everything else. How would I go about finding all implementations of that interface? In IntelliJ, I put my cursor over the interface and press Ctrl+Shift+7, and BAM. There's a list.

What if I'm missing an import and I didn't feel like thinking about which package LoggerFactory comes from. In IntelliJ, unambiguous imports are automatically added.

What if I want to move a package into a different parent? Click and drag. That's it. No fixing the package declarations or imports. It's all done for me.

Don't even get me started about the interactive debugger that magically interfaces with code external to the project you're working in (i.e., you can add it as a module and add breakpoints in the foreign code).

I'm sure the guy you worked with managed to be very productive just using vim, but I guarantee you he spent a lot of time doing things that an IDE could've take care of for him.

[nslay]

The thing is, there are IDE plugins that replicate 95% of the needed functionality in vim. I use IdeaVim for IntelliJ.

Yes, you can navigate around a couple of files with great speed and efficiency using only vim, but that's not where the most significant benefit in using an IDE comes from.

There are certain functionalities that IDEs have that stuff like vim just can't have without either (usually both):
a) an obscene amount of overhead involved with setup.
b) clunky, difficult-to-use interfaces.

Here are a few decent examples that illustrate this:

Let's say I'm using only vim while working in a codebase that's spanned by dozens of projects and there's an interface in a project that's upstream of everything else. How would I go about finding all implementations of that interface? In IntelliJ, I put my cursor over the interface and press Ctrl+Shift+7, and BAM. There's a list.

What if I'm missing an import and I didn't feel like thinking about which package LoggerFactory comes from. In IntelliJ, unambiguous imports are automatically added.

What if I want to move a package into a different parent? Click and drag. That's it. No fixing the package declarations or imports. It's all done for me.

Don't even get me started about the interactive debugger that magically interfaces with code external to the project you're working in (i.e., you can add it as a module and add breakpoints in the foreign code).

I'm sure the guy you worked with managed to be very productive just using vim, but I guarantee you he spent a lot of time doing things that an IDE could've take care of for him.

There are few IDEs that can effectively replicate 95% of the functionality of a proper Unix shell.

I swear, I'm appalled that simple and ancient tools like grep, sed, awk, vim, find, sh are still more efficient and effective than modern tools like Windows Explorer and Visual Studio ... granted Visual Studio debugging is nicer than everything else (but gcc is faster at compiling than the pile of crap that VS 2010 is without generating 10GB of compiler metadata).

[Sidoh]

Right, but it's not like you have to pick one. That's kind of my point, actually. Use the right tool for the job. It's completely asinine to not use an IDE if you're working with a large codebase, and it's also pretty stupid to not take advantage of commandline tools where appropriate.

The ancient tools you've mentioned are certainly more efficient for some things. I'd lose a significant chunk of time if I had to commit to using them exclusively, though.

[nslay]

Right, but it's not like you have to pick one. That's kind of my point, actually. Use the right tool for the job. It's completely asinine to not use an IDE if you're working with a large codebase, and it's also pretty stupid to not take advantage of commandline tools where appropriate.

While what you say seems reasonable, I have experience both development environments on a large code base and I disagree here. I observe that an IDE is very helpful if you're unfamiliar with the code base. However, once you're very familiar, you really would be more productive with a Unix shell environment for everything except possibly debugging. Although, from my personal experience, the bugs that stump me are often not easy to work out in a debugger (e.g. the crash occurs several days later, it's a multi-threaded bug, or it's impossibly slow in debug mode).

But this should come as no surprise as big code bases like FreeBSD and Linux are very likely exclusively developed with vim and emacs ...

In the end, I think quirks in the IDE (UI and otherwise) waste unimaginable amounts of time. For example, regenerating a VS 2010 solution from CMake, while VS 2010 is running, causes all sorts of havoc. Having to reload hundreds of projects is much slower than just Task Manager -> Kill devenv -> Start devenv again. This kind of crap man ... it's a big time waster. Not really the IDE's fault, but it takes VS 2010 15 minutes to link one of the executables ... the same code takes just 1-2 minutes to link with gcc. I despise Visual Studio 2010 with a passion (2008 isn't so stupid).

UI quirks in the windowing environment are also huge time wasters. We're just now transitioning to the superior Windows 7, but Windows XP has so many very annoying and time consuming quirks. I feel like 10% of the day is spent waiting for Windows or Visual Studio to do something or working around some quirk ...

The ancient tools you've mentioned are certainly more efficient for some things. I'd lose a significant chunk of time if I had to commit to using them exclusively, though.

Maybe if you wanted a birds eye view of a folder of images ... these tools do nothing for you.  It's really hard to imagine scenarios where you would be wasting any time using these tools.  You would have to write a program or script to accomplish tasks those simple/ancient tools can do for you.

[Sidoh]

While what you say seems reasonable, I have experience both development environments on a large code base and I disagree here. I observe that an IDE is very helpful if you're unfamiliar with the code base. However, once you're very familiar, you really would be more productive with a Unix shell environment for everything except possibly debugging. Although, from my personal experience, the bugs that stump me are often not easy to work out in a debugger (e.g. the crash occurs several days later, it's a multi-threaded bug, or it's impossibly slow in debug mode).

Me too, and I still think it's pretty goofy to not use an IDE.

While I agree that it gets easier as you become more familiar with a codebase, navigation is still significantly more clumsy without a good IDE. It also makes it easier to keep up with a constantly changing codebase.

Yes, a debugger doesn't help a ton in those situations, but that's not really relevant, right? We're talking about tools that improve efficiency, not enable developers to write perfect code.

But this should come as no surprise as big code bases like FreeBSD and Linux are very likely exclusively developed with vim and emacs ...

I don't think I've made the claim that it's impossible, just that it's probably unreasonable. These projects are developed mostly by relative dinosaurs who are probably pretty resistant to using IDEs because they've already invested time in learning how to use an environment that works well for them.

I think that the fact that the average person contributing to the Linux kernel probably doesn't use an IDE (I'm taking your word on that, by the way) is more an artifact of it being the status quo and less so that it's actually a better solution. We might say the same about the quality of the tools available for C, for that matter. (As an aside, I think I'd rather be a goat farmer than develop C/C++ fulltime.)

In the end, I think quirks in the IDE (UI and otherwise) waste unimaginable amounts of time. For example, regenerating a VS 2010 solution from CMake, while VS 2010 is running, causes all sorts of havoc. Having to reload hundreds of projects is much slower than just Task Manager -> Kill devenv -> Start devenv again. This kind of crap man ... it's a big time waster. Not really the IDE's fault, but it takes VS 2010 15 minutes to link one of the executables ... the same code takes just 1-2 minutes to link with gcc. I despise Visual Studio 2010 with a passion (2008 isn't so stupid).

Honestly, I have very little experience with windows IDEs. These kinds of things never bother me in a Java environment.

UI quirks in the windowing environment are also huge time wasters. We're just now transitioning to the superior Windows 7, but Windows XP has so many very annoying and time consuming quirks. I feel like 10% of the day is spent waiting for Windows or Visual Studio to do something or working around some quirk ...

The only kinds of things like this that come up for me are more the fault of my desktop environment than the IDE itself. I'm just too lazy to switch off of unity.

Maybe if you wanted a birds eye view of a folder of images ... these tools do nothing for you.  It's really hard to imagine scenarios where you would be wasting any time using these tools.  You would have to write a program or script to accomplish tasks those simple/ancient tools can do for you.

Right, but that was kind of my point, wasn't it? When it's more convenient to use unix tools, then fuckin' use unix tools. But I think it's silly to latch to them and pretend that they're the best solution for every situation.

[nslay]

While what you say seems reasonable, I have experience both development environments on a large code base and I disagree here. I observe that an IDE is very helpful if you're unfamiliar with the code base. However, once you're very familiar, you really would be more productive with a Unix shell environment for everything except possibly debugging. Although, from my personal experience, the bugs that stump me are often not easy to work out in a debugger (e.g. the crash occurs several days later, it's a multi-threaded bug, or it's impossibly slow in debug mode).

Me too, and I still think it's pretty goofy to not use an IDE.

While I agree that it gets easier as you become more familiar with a codebase, navigation is still significantly more clumsy without a good IDE. It also makes it easier to keep up with a constantly changing codebase.

Navigation is already clumsy with an IDE like Visual Studio ... Maybe not for your IDE.

Yes, a debugger doesn't help a ton in those situations, but that's not really relevant, right? We're talking about tools that improve efficiency, not enable developers to write perfect code.

I told you my experience ... they're great if you don't know the code base and that's really about it. The ones I use (all Visual Studio) all have annoying quirks and waste tons of time.

Where do you see improvement in efficiency for your task?

But this should come as no surprise as big code bases like FreeBSD and Linux are very likely exclusively developed with vim and emacs ...

I don't think I've made the claim that it's impossible, just that it's probably unreasonable. These projects are developed mostly by relative dinosaurs who are probably pretty resistant to using IDEs because they've already invested time in learning how to use an environment that works well for them.

You're right, you haven't made this claim. But a lot of developers on the FreeBSD team, for example, are not dinosaurs.

I think that the fact that the average person contributing to the Linux kernel probably doesn't use an IDE (I'm taking your word on that, by the way) is more an artifact of it being the status quo and less so that it's actually a better solution. We might say the same about the quality of the tools available for C, for that matter. (As an aside, I think I'd rather be a goat farmer than develop C/C++ fulltime.)

You're right, I made an empty claim. I'm guessing that most, if not all, kernel developers for either the FreeBSD or Linux do not use an IDE just from the observation that both systems are built with make(1). Besides, there are no project files to open the source tree in any IDE unless an IDE could read Makefiles.

But maybe an IDE really doesn't help with development as much as claimed ... this has been my experience.

In the end, I think quirks in the IDE (UI and otherwise) waste unimaginable amounts of time. For example, regenerating a VS 2010 solution from CMake, while VS 2010 is running, causes all sorts of havoc. Having to reload hundreds of projects is much slower than just Task Manager -> Kill devenv -> Start devenv again. This kind of crap man ... it's a big time waster. Not really the IDE's fault, but it takes VS 2010 15 minutes to link one of the executables ... the same code takes just 1-2 minutes to link with gcc. I despise Visual Studio 2010 with a passion (2008 isn't so stupid).

Honestly, I have very little experience with windows IDEs. These kinds of things never bother me in a Java environment.

Lucky you. I have very little experience with IDEs other than Visual Studio.

UI quirks in the windowing environment are also huge time wasters. We're just now transitioning to the superior Windows 7, but Windows XP has so many very annoying and time consuming quirks. I feel like 10% of the day is spent waiting for Windows or Visual Studio to do something or working around some quirk ...

The only kinds of things like this that come up for me are more the fault of my desktop environment than the IDE itself. I'm just too lazy to switch off of unity.

Maybe if you wanted a birds eye view of a folder of images ... these tools do nothing for you.  It's really hard to imagine scenarios where you would be wasting any time using these tools.  You would have to write a program or script to accomplish tasks those simple/ancient tools can do for you.

Right, but that was kind of my point, wasn't it? When it's more convenient to use unix tools, then fuckin' use unix tools. But I think it's silly to latch to them and pretend that they're the best solution for every situation.

Yes, and I hate to sound religious, but they've demonstrated themselves to be the best development tools so far.

Please tell me, where does an IDE help you? I could probably enumerate a list of where, for example, Visual Studio wastes a lot my time. Gosh, nothing like waiting for Visual Studio to "Go to definition" on a template only to have it tell you several minutes later that it couldn't find it. But grep? Grep works!

Maybe your IDE is more responsive and less quirky. It sounds like you're using a Linux development station too.

[Sidoh]

While what you say seems reasonable, I have experience both development environments on a large code base and I disagree here. I observe that an IDE is very helpful if you're unfamiliar with the code base. However, once you're very familiar, you really would be more productive with a Unix shell environment for everything except possibly debugging. Although, from my personal experience, the bugs that stump me are often not easy to work out in a debugger (e.g. the crash occurs several days later, it's a multi-threaded bug, or it's impossibly slow in debug mode).

Me too, and I still think it's pretty goofy to not use an IDE.

While I agree that it gets easier as you become more familiar with a codebase, navigation is still significantly more clumsy without a good IDE. It also makes it easier to keep up with a constantly changing codebase.

Navigation is already clumsy with an IDE like Visual Studio ... Maybe not for your IDE.

Yes, a debugger doesn't help a ton in those situations, but that's not really relevant, right? We're talking about tools that improve efficiency, not enable developers to write perfect code.

I told you my experience ... they're great if you don't know the code base and that's really about it. The ones I use (all Visual Studio) all have annoying quirks and waste tons of time.

IntelliJ is quite responsive. Like I said, the only quirks I run into are more the fault of Swing and Unity than IntelliJ itself. Even still, in the worst case, I restart it after I dock/undock and it performs really well.

Where do you see improvement in efficiency for your task?

I listed a couple of ways already, I think. I'll list more at the bottom of this post.

I can grep for useages/definitions, but I'd much rather press a button and instantly have an answer, wouldn't you? Maybe VS sucks, but IntellJ doesn't have any of the problems you're listing.

You're right, you haven't made this claim. But a lot of developers on the FreeBSD team, for example, are not dinosaurs.

When I say "relative dinosaurs", I mean mostly over 30-35. I think that's pretty much all it takes. If you grow up being a ninja with unix tools, it's hard to justify fumbling around with some new-fangled IDE.

You're right, I made an empty claim. I'm guessing that most, if not all, kernel developers for either the FreeBSD or Linux do not use an IDE just from the observation that both systems are built with make(1). Besides, there are no project files to open the source tree in any IDE unless an IDE could read Makefiles.

Right -- I think was the point I was trying to make. These projects were built before IDEs were worth using. People figured out efficient ways to develop without them. That doesn't mean they wouldn't be better without an IDE -- just means it's probably not worth the investment.

But maybe an IDE really doesn't help with development as much as claimed ... this has been my experience.

I don't think there are many features available in an IDE that can't at least be emulated with unix tools. I just meant to say there are many things that you can do more efficiently (and/or with less setup) with one.

Yes, and I hate to sound religious, but they've demonstrated themselves to be the best development tools so far.

It wouldn't surprise me if IDEs are less helpful for platforms like C/C++. The foundations were probably built long before good IDEs were even possible.

Please tell me, where does an IDE help you? I could probably enumerate a list of where, for example, Visual Studio wastes a lot my time. Gosh, nothing like waiting for Visual Studio to "Go to definition" on a template only to have it tell you several minutes later that it couldn't find it. But grep? Grep works!

Maybe your IDE is more responsive and less quirky. It sounds like you're using a Linux development station too.

That's not a problem with IntelliJ. Go to definition is effectively instantaneous (probably on the order of 10s of milliseconds). Same with find useages, find implements, and so on. I have a reasonably beefy laptop (16GB RAM), so I give IntelliJ a max heap size of 4GB. It keeps an in-memory index (I think it's lazy-loaded from disk) of definitions, files, useages, etc. I'd imagine I have that to thank for its responsiveness.

Just for good measure, here are more reasons I love using an IDE:

• Generate getters/setters for fields can be done with a few keystrokes. (Alt+N -> type "get" -> Enter -> Select fields -> Enter)
• Code templates are fuckin' amazing. If I want to loop over a structure, I type "iter<tab>", type the name of the variable, and press enter. All of the type information is inferred. These code templates exist for quite a few things. "public static void main(String[] args) { ... }" is "psvm<tab>"
• Searching for files is super easy. Alt+Shift+N, type the name of the file. You can also use camel case so if you want to search for "ReallyReallyRidiculouslyLongClassName", you can just type "RRRL"
• Swapping between recently used files is really an awesome thing, I've found. Alt+E, Enter to go to last recent file. Alt+E brings up a list of the last ~20 open files, and you can type to filter the list.
• Added a constructor parameter? Cursor over it, press Alt+Enter, "bind", Enter to generate a field and assign the variable to the field in the constructor.
• Squiggly red lines to indicate compile errors. I assume you have something like this with whatever you use, but it'd be such a ridiculous pain in the ass to work without them.
• When there's an error, Alt+Enter brings up a context-aware list of possible fixes for it. For example, if something needs a typecast, it'll generate it for you. If you're not handling an error that some method call throws, you can choose to wrap it in try/catch or add it to the method signature.
• Automatically generate implement/override method stubs (Alt+N, "Ov" or "imp", Enter, choose methods to override, Enter)
• Writing a decorator? When you have member that implements/extends the same interface/class that the class you're working in does, you can automatically generate delegate methods for all of them. (Alt+N, "Del", select member to delegate to, select methods to delegate, Enter)

These are just off the top of my head, of course. I should start keeping a list.

[nslay]

I can grep for useages/definitions, but I'd much rather press a button and instantly have an answer, wouldn't you? Maybe VS sucks, but IntellJ doesn't have any of the problems you're listing.

The problem is that Visual Studio does not handle template definitions very well (at all!). When using extraordinarily large code bases like ours, it often doesn't have an answer in the first place.

That's not a problem with IntelliJ. Go to definition is effectively instantaneous (probably on the order of 10s of milliseconds). Same with find useages, find implements, and so on. I have a reasonably beefy laptop (16GB RAM), so I give IntelliJ a max heap size of 4GB. It keeps an in-memory index (I think it's lazy-loaded from disk) of definitions, files, useages, etc. I'd imagine I have that to thank for its responsiveness.

Just for good measure, here are more reasons I love using an IDE:

• Generate getters/setters for fields can be done with a few keystrokes. (Alt+N -> type "get" -> Enter -> Select fields -> Enter)
• Code templates are fuckin' amazing. If I want to loop over a structure, I type "iter<tab>", type the name of the variable, and press enter. All of the type information is inferred. These code templates exist for quite a few things. "public static void main(String[] args) { ... }" is "psvm<tab>"
• Searching for files is super easy. Alt+Shift+N, type the name of the file. You can also use camel case so if you want to search for "ReallyReallyRidiculouslyLongClassName", you can just type "RRRL"
• Swapping between recently used files is really an awesome thing, I've found. Alt+E, Enter to go to last recent file. Alt+E brings up a list of the last ~20 open files, and you can type to filter the list.
• Added a constructor parameter? Cursor over it, press Alt+Enter, "bind", Enter to generate a field and assign the variable to the field in the constructor.
• Squiggly red lines to indicate compile errors. I assume you have something like this with whatever you use, but it'd be such a ridiculous pain in the ass to work without them.
• When there's an error, Alt+Enter brings up a context-aware list of possible fixes for it. For example, if something needs a typecast, it'll generate it for you. If you're not handling an error that some method call throws, you can choose to wrap it in try/catch or add it to the method signature.
• Automatically generate implement/override method stubs (Alt+N, "Ov" or "imp", Enter, choose methods to override, Enter)
• Writing a decorator? When you have member that implements/extends the same interface/class that the class you're working in does, you can automatically generate delegate methods for all of them. (Alt+N, "Del", select member to delegate to, select methods to delegate, Enter)

These are just off the top of my head, of course. I should start keeping a list.

Here are my complaints for your lists:

• OK ...
• OK ...
• But this file and text search feature in Visual Studio is dreadfully slow (find is much faster). It takes minutes for it to find a file or text in a file.
• Visual Studio has tabs for opened buffers. Nice until you have like 20 of them, then it's time consuming to find the file you want to edit. Switching buffers in vim is faster. You can type in a filter, so you don't have this problem.
• OK ...
• Yes, squiggly red lines are nice ... when they don't give false alarms (and they give false alarms a lot in VS).
• I don't think VS has that feature.
• OK ...
• OK ...

(3) and (4) are very time consuming. That and occasional and mysterious VS freeze-ups.

But isn't it interesting that almost everything you've listed has everything to do with text editing and little to do with programming. Granted an IDE is a glorified text editor that can parse a language and communicate with a compiler. Using a powerful text editor like vim or emacs could already do 1, 2, 4, 5, 8, and 9 and probably do it faster and better due to the pure use of a keyboard. Couple this with command line tools and you have a complete development environment. Use Clang over GCC and you have point 7 leaving point 6, definition/declaration lookups and debugging as the only unique conveniences from an IDE.

So would you really think it is goofy to use the Unix shell environment on a large code base over those three conveniences? Indeed, looking up definitions and declarations are useful if you're new to a code base, but if you're already very familiar, you almost never need that anyway. Oh sure, if you call some uncommon function, then maybe it's nice to have at that moment ...

But from what you've described, VS really does suck and IntelliJ is nice.

I know it's hard to enumerate ideas on the spot ... I'm sure you'll expand upon this list.

[Sidoh]

The problem is that Visual Studio does not handle template definitions very well (at all!). When using extraordinarily large code bases like ours, it often doesn't have an answer in the first place.

Out of curiosity, how many lines of code are you talking about? I'm talking about projects that I have a reasonable probability of needing access to on a daily basis.

(3) and (4) are very time consuming. That and occasional and mysterious VS freeze-ups.

I probably use these more than most features available. It'd be a huge pain in the ass to develop without them... if you know exactly what a file is named, how do you find it?

But isn't it interesting that almost everything you've listed has everything to do with text editing and little to do with programming. Granted an IDE is a glorified text editor that can parse a language and communicate with a compiler. Using a powerful text editor like vim or emacs could already do 1, 2, 4, 5, 8, and 9 and probably do it faster and better due to the pure use of a keyboard.

They're not, though. The majority of the examples I listed require that the IDE be capable of inferring things only possible if it does some pretty deep language-level analysis. These aren't things you could easily implement with a vim plugin. (And for the record, I almost never use the mouse while programming. That's actually why I listed the keyboard shortcuts for the examples I gave. If I missed any, it was only out of laziness.)

For example, code templates aren't usually just macros. I guess IntelliJ likes to call them "live templates". The one I use most often is "iter<tab>". It generates this code:

Code: [Select]

for (<Type> <inferred variable name> : <...> ) {
}

It puts your cursor where "..." is. As you update it, a context / locality sensitive dropdown menu appears as you type, of course. More importantly, it also updates the type and name of the variable.

The implement/delegate methods are similarly not just keyboard-triggered text barf. It requires that the editor be aware of fancy language-level analysis that would be a marvelous pain in the ass to implement as effectively in a vim plugin.

If you can show me a "non-IDE" environment that has features like the ones I'm listing, please show me. Perhaps I'm not doing these features justice, but they would not be easy to implement. And why would I want to do that when IntelliJ does them so well already?

Another I forgot: generate equals/hashCode. In most cases, a very formulaic implementation is all you want. The IDE does it for you:

Code: [Select]

@Override
  public int hashCode() {
    int result = (int)(count ^ (count >>> 32));
    result = 31 * result + (unit != null ? unit.hashCode() : 0);
    return result;
  }

Couple this with command line tools and you have a complete development environment. Use Clang over GCC and you have point 7 leaving point 6, definition/declaration lookups and debugging as the only unique conveniences from an IDE.

Like I mentioned up there, I don't think I did the features justice. They're not something you could implement reliably without doing pretty complicated analysis of the codebase you're working with. And when you're working with a large codebase, the only way these things could function responsively is if there's a project-wide (multi-module) in-memory index.

So would you really think it is goofy to use the Unix shell environment on a large code base over those three conveniences? Indeed, looking up definitions and declarations are useful if you're new to a code base, but if you're already very familiar, you almost never need that anyway. Oh sure, if you call some uncommon function, then maybe it's nice to have at that moment ...

I think you're not giving the things I've listed enough credit. Each one saves me between 5 seconds and 2 minutes with each use, depending on the instance. For emphasis: I really don't think that these features are as readily replicated with command line tools as you seem to be suggesting. Fundamentally, I think an IDE should minimize the amount of time you spend programming where your typing speed is the bottleneck. Before becoming proficient with IntelliJ, it happened pretty often that I knew exactly what I wanted to type, but I'd have to spend several minutes minutes typing it. That doesn't happen nearly as often now.

Like I said, please show me a vim environment that works as well and I'd actually give serious consideration into using it.

But from what you've described, VS really does suck and IntelliJ is nice.

I haven't used VS on a big codebase before. I used it for some personal C# projects a while ago and it seemed nice, but I'll be happy to take your word that it sucks. IntelliJ is pretty fuckin' awesome.

I know it's hard to enumerate ideas on the spot ... I'm sure you'll expand upon this list.

It is, but I'm quite convinced that most of the items on the list I provided could not be implemented in a reliable and performant way using command line tools. When it comes down to it, the best thing is that I can do all of this stuff out of the box. I don't have to collect dozens of plugins and scripts just to get an environment that might work well enough that I don't spend every moment I'm programming missing IntelliJ

[nslay]

The problem is that Visual Studio does not handle template definitions very well (at all!). When using extraordinarily large code bases like ours, it often doesn't have an answer in the first place.

Out of curiosity, how many lines of code are you talking about? I'm talking about projects that I have a reasonable probability of needing access to on a daily basis.

I've never counted the lines of code, but it's a large machine learning and computer vision codebase used to build the tools used worldwide in hospitals (quite literally, not exaggerated) ... I don't know what else I could possibly tell you without divulging too much information other than to give you the impression of a mature decade-old code base used to solve a variety of medical imaging problems.

(3) and (4) are very time consuming. That and occasional and mysterious VS freeze-ups.

I probably use these more than most features available. It'd be a huge pain in the ass to develop without them... if you know exactly what a file is named, how do you find it?

We have a convention for how sources are organized in the tree. I normally know exactly where to look just from the functionality I need.

I normally need to find some text or function definition in one of those files rather than a file itself ...

But isn't it interesting that almost everything you've listed has everything to do with text editing and little to do with programming. Granted an IDE is a glorified text editor that can parse a language and communicate with a compiler. Using a powerful text editor like vim or emacs could already do 1, 2, 4, 5, 8, and 9 and probably do it faster and better due to the pure use of a keyboard.

They're not, though. The majority of the examples I listed require that the IDE be capable of inferring things only possible if it does some pretty deep language-level analysis. These aren't things you could easily implement with a vim plugin. (And for the record, I almost never use the mouse while programming. That's actually why I listed the keyboard shortcuts for the examples I gave. If I missed any, it was only out of laziness.)

For example, code templates aren't usually just macros. I guess IntelliJ likes to call them "live templates". The one I use most often is "iter<tab>". It generates this code:

Code: [Select]

for (<Type> <inferred variable name> : <...> ) {
}

It puts your cursor where "..." is. As you update it, a context / locality sensitive dropdown menu appears as you type, of course. More importantly, it also updates the type and name of the variable.

The implement/delegate methods are similarly not just keyboard-triggered text barf. It requires that the editor be aware of fancy language-level analysis that would be a marvelous pain in the ass to implement as effectively in a vim plugin.

If you can show me a "non-IDE" environment that has features like the ones I'm listing, please show me. Perhaps I'm not doing these features justice, but they would not be easy to implement. And why would I want to do that when IntelliJ does them so well already?

I'm not trying to convince you to use a non-IDE environment. I was only arguing that a Unix shell environment is more efficient for development than an IDE. We've established that Visual Studio is the culprit of my findings (which I thought was the gold standard for IDEs).

Another I forgot: generate equals/hashCode. In most cases, a very formulaic implementation is all you want. The IDE does it for you:

Code: [Select]

@Override
  public int hashCode() {
    int result = (int)(count ^ (count >>> 32));
    result = 31 * result + (unit != null ? unit.hashCode() : 0);
    return result;
  }

I don't normally have to write hash functions. If I didn't care about performance, I'd just use std::map and write a less than operator. If I cared about performance, I would try to derive a hash function myself that wouldn't likely collide and plug it into std::unordered_map.

Although, some code templates could be useful. Nifty.

Couple this with command line tools and you have a complete development environment. Use Clang over GCC and you have point 7 leaving point 6, definition/declaration lookups and debugging as the only unique conveniences from an IDE.

Like I mentioned up there, I don't think I did the features justice. They're not something you could implement reliably without doing pretty complicated analysis of the codebase you're working with. And when you're working with a large codebase, the only way these things could function responsively is if there's a project-wide (multi-module) in-memory index.

I'm sure you'll think of a convincing example. Just remember I'm not trying to convince you to use a non-IDE environment.

So would you really think it is goofy to use the Unix shell environment on a large code base over those three conveniences? Indeed, looking up definitions and declarations are useful if you're new to a code base, but if you're already very familiar, you almost never need that anyway. Oh sure, if you call some uncommon function, then maybe it's nice to have at that moment ...

I think you're not giving the things I've listed enough credit. Each one saves me between 5 seconds and 2 minutes with each use, depending on the instance. For emphasis: I really don't think that these features are as readily replicated with command line tools as you seem to be suggesting. Fundamentally, I think an IDE should minimize the amount of time you spend programming where your typing speed is the bottleneck. Before becoming proficient with IntelliJ, it happened pretty often that I knew exactly what I wanted to type, but I'd have to spend several minutes minutes typing it. That doesn't happen nearly as often now.

Like I said, please show me a vim environment that works as well and I'd actually give serious consideration into using it.

But from what you've described, VS really does suck and IntelliJ is nice.

I haven't used VS on a big codebase before. I used it for some personal C# projects a while ago and it seemed nice, but I'll be happy to take your word that it sucks. IntelliJ is pretty fuckin' awesome.

I know it's hard to enumerate ideas on the spot ... I'm sure you'll expand upon this list.

It is, but I'm quite convinced that most of the items on the list I provided could not be implemented in a reliable and performant way using command line tools. When it comes down to it, the best thing is that I can do all of this stuff out of the box. I don't have to collect dozens of plugins and scripts just to get an environment that might work well enough that I don't spend every moment I'm programming missing IntelliJ

But I'm still convinced that a lot of the text-related functionality you listed can already be done with vim or emacs. And kind of cheating, plug clang into vim (since clang is modular and exposes its parser API), and you could pretty much do anything text-related you listed in vim with C or C++ ... actually on that thought, I just found this:
http://www.vim.org/scripts/script.php?script_id=3302

That apparently even does red squiggly lines ...

I still think it's cheating in the sense that vim is given more context than a normal text editor.

Will I use it in vim? Probably not ...