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

[Falcon]

Isn't IntelliJ for Java only? Or is it extendable like Eclipse? As far as C/C++ IDEs I find that Visual Studio and Qt Creator are the best. Eclipse with C++ plugin on the other hand blows.

[Sidoh]

Isn't IntelliJ for Java only? Or is it extendable like Eclipse? As far as C/C++ IDEs I find that Visual Studio and Qt Creator are the best. Eclipse with C++ plugin on the other hand blows.

The company that makes IntelliJ (JetBrains) makes quite a few language-specific IDEs. I've used RubyMine as well, and it's also pretty awesome. IDEs are always more useful for strongly-typed languages, though...

I know there are plugins that enable their IDEs to be a reasonable C/C++ editor, but I'm sure it's not quite Visual Studio.

The professional version of IntelliJ also manages to be a pretty great IDE for jetty stuff (meaning it's a good HTML, CSS, JavasScript, and JSP editor).

edit: Looks like they're working on a C/C++ IDE.

[Sidoh]

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

Right. I'm sure you know where stuff is. I think what I'm meaning to ask is when you know exactly what file you want to open or definition you want to go to, how do you do it? Do you use visual studio?

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

Well, if a unix shell is actually more efficient for development than an IDE, I'd like to be convinced. So far, I'm not even close.

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.

I don't think caring about performance is binary. I usually care enough about performance to use HashMap over TreeMap, but I rarely see much worth in optimizing the hash function.

Anyway, the equals it generates is generally about as performant as you can hope for, and it'd still be a little annoying to write:

Code: [Select]

  @Override
  public boolean equals(Object o) {
    if (this == o) {
      return true;
    }
    if (o == null || getClass() != o.getClass()) {
      return false;
    }

    TimeSegment that = (TimeSegment)o;

    if (count != that.count) {
      return false;
    }
    if (unit != that.unit) {
      return false;
    }

    return true;
  }

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.

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

Squiggly red lines to me are more of a necessity and less of a fluffy feature. I'd much rather respond to errors as they crop up. Sometimes developing under the assumption that there are no errors leads to big problems and lots of wasted time.

I'd really love to see a development environment that implemented half of the features I listed in any significant capacity. This isn't something you can accomplish by shelling out to the compiler. I'll try to demonstrate.

Let's say I have a Map with String keys and Integer values. If it's the only iterable in scope, this is what I see when I type "iter<tab>":



If I update it to map.entrySet(), this is what I see:



notice that the type is updated automatically. This is really the beauty of these live templates. You see what the code the IDE is generating for you as you update the input. When I press "enter", I'm prompted to enter a name for the iteration variable. The generated name is usually acceptable (although not in this case).


Let's say I have a final member variable that isn't initialized. I can press <Alt>-<Enter> over it and I get this menu:



In this case, the first option is what I want. If I press <Enter>, I get this:



Now let's say I want to delegate the methods that Map declares to the member variable. I can do that by pressing <Alt>-N, typing "del" and pressing <Enter>:



I get this menu, which is a little more useful when there's more than one option:



Then it shows me a list of methods that I could delegate. Let's say I want to delegate everything except for get(Object). There's probably some fancy way to do this with the keyboard, but I'd probably just do <Ctrl>-A to select them all and then delete get, or just Ctrl-Click get:



This is what I get:



Notice this feature is only possible if the editor is aware of what methods Map implements. It'll be able to do this even if the delegate isn't typed as a Map. It just has to be anything that implements Map. The editor is able to infer all of that. It took less than 10 seconds to generate all of that code. You can imagine it'd take a long time to type it manually in the general case, especially if the interface you're writing a delegate for has lots of methods.

[nslay]

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

Right. I'm sure you know where stuff is. I think what I'm meaning to ask is when you know exactly what file you want to open or definition you want to go to, how do you do it? Do you use visual studio?

In Visual Studio, you spend time looking at a long list of files in the Solution Explorer. This is made less worse by grouping the long list of sources into subgroups. Although, seeing that we have so many constituent projects, it's already time consuming to scroll through the list of projects, expand the tree and then further find the source you want! Shell is more efficient here, especially when you know the source tree by heart. Of course, if you had a text filter like you claim IntelliJ has, that would help (although file finding in VS or Windows is slower than Unix find!).

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

Well, if a unix shell is actually more efficient for development than an IDE, I'd like to be convinced. So far, I'm not even close.

And the Unix shell is definitely more efficient than Visual Studio ... by an enormous margin. There's no random freeze-ups, there's no reloading hundreds of projects when you regenerate a solution with CMake, there's no inability to find template definitions, there's no long monolithic list of sources to painstakingly scroll through, there's no 15 minute link time, there's no /MP glitches, there's no false positive red squiggly lines, there's no 10GB metadata files (which matters when you have terabytes of medical images on your drive) ...

But the biggest time wasters in Visual Studio are random freeze-ups and reloading project files. And it performs this way even on a modern OS like Windows Server 2008 on modern hardware (24 cores, 72GB of RAM).

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.

I don't think caring about performance is binary. I usually care enough about performance to use HashMap over TreeMap, but I rarely see much worth in optimizing the hash function.

Then it seems you don't use a hash map for anything performant in the first place.

Anyway, the equals it generates is generally about as performant as you can hope for, and it'd still be a little annoying to write:

Code: [Select]

  @Override
  public boolean equals(Object o) {
    if (this == o) {
      return true;
    }
    if (o == null || getClass() != o.getClass()) {
      return false;
    }

    TimeSegment that = (TimeSegment)o;

    if (count != that.count) {
      return false;
    }
    if (unit != that.unit) {
      return false;
    }

    return true;
  }

That's completely overkill. Nice as it may be that your IDE can fill in some code for you, I'd have do the reverse of implementing operator==: Erase most of that. This is all I'd want:

Code: [Select]

bool operator==(const Thing &clOther) const {
  if (this == &clOther)
    return true;
  // TODO: Fill this in.
  return false;
}
That's not nearly as annoying or time consuming to write as you claim it to be, albeit less convenient than having it already. No living templates needed here.

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.

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

Squiggly red lines to me are more of a necessity and less of a fluffy feature. I'd much rather respond to errors as they crop up. Sometimes developing under the assumption that there are no errors leads to big problems and lots of wasted time.

Or just check to see if it compiles every so often ... you should do that any way, red lines or not. Of course, if you're stupid enough to write 1000 lines without checking if it compiles (even with red lines), you deserve what you get.

I'd really love to see a development environment that implemented half of the features I listed in any significant capacity. This isn't something you can accomplish by shelling out to the compiler. I'll try to demonstrate.

Let's say I have a Map with String keys and Integer values. If it's the only iterable in scope, this is what I see when I type "iter<tab>":



If I update it to map.entrySet(), this is what I see:



notice that the type is updated automatically. This is really the beauty of these live templates. You see what the code the IDE is generating for you as you update the input. When I press "enter", I'm prompted to enter a name for the iteration variable. The generated name is usually acceptable (although not in this case).


Let's say I have a final member variable that isn't initialized. I can press <Alt>-<Enter> over it and I get this menu:



In this case, the first option is what I want. If I press <Enter>, I get this:



Now let's say I want to delegate the methods that Map declares to the member variable. I can do that by pressing <Alt>-N, typing "del" and pressing <Enter>:



I get this menu, which is a little more useful when there's more than one option:



Then it shows me a list of methods that I could delegate. Let's say I want to delegate everything except for get(Object). There's probably some fancy way to do this with the keyboard, but I'd probably just do <Ctrl>-A to select them all and then delete get, or just Ctrl-Click get:



This is what I get:



Notice this feature is only possible if the editor is aware of what methods Map implements. It'll be able to do this even if the delegate isn't typed as a Map. It just has to be anything that implements Map. The editor is able to infer all of that. It took less than 10 seconds to generate all of that code. You can imagine it'd take a long time to type it manually in the general case, especially if the interface you're writing a delegate for has lots of methods.

That's very handy. I could definitely benefit from something like that.

[Sidoh]

In Visual Studio, you spend time looking at a long list of files in the Solution Explorer. This is made less worse by grouping the long list of sources into subgroups. Although, seeing that we have so many constituent projects, it's already time consuming to scroll through the list of projects, expand the tree and then further find the source you want! Shell is more efficient here, especially when you know the source tree by heart. Of course, if you had a text filter like you claim IntelliJ has, that would help (although file finding in VS or Windows is slower than Unix find!).

That's completely ridiculous! I'd never navigate that way. I press Ctrl+Shift+N and type the name of the class/file I want and press Enter. There's no delay... the index makes it functionally instantaneous. Much, much faster than clicking through the source tree... does visual studio really not do that?

And the Unix shell is definitely more efficient than Visual Studio ... by an enormous margin. There's no random freeze-ups, there's no reloading hundreds of projects when you regenerate a solution with CMake, there's no inability to find template definitions, there's no long monolithic list of sources to painstakingly scroll through, there's no 15 minute link time, there's no /MP glitches, there's no false positive red squiggly lines, there's no 10GB metadata files (which matters when you have terabytes of medical images on your drive) ...

But the biggest time wasters in Visual Studio are random freeze-ups and reloading project files. And it performs this way even on a modern OS like Windows Server 2008 on modern hardware (24 cores, 72GB of RAM).

These aren't problems in a Java development environment. This is all the more reason for me to steer clear of C++. I'll actually actively avoid companies that use C++ after hearing about all this nonsense. It sounds absolutely infuriating. I've worked with and been frustrated by small C++ projects; I guess I should've figured those issues would only compound as the codebase gets more complex.

Then it seems you don't use a hash map for anything performant in the first place.

Uh... what? The generated hash function is good enough that it's still O(1) average time (instead of O(log n)). It's still much faster than a TreeMap, especially when the overhead is compounded by many terabytes of data (in groups of up to a few 1000).

Using HashMap along with the auto-generated hashCode provides enough speed improvement to justify using it over TreeMap and implementing compareTo.

As an aside: since every type in the java libraries that you could reasonably expect to implement a reliable hash function does, it's actually a lot easier to design a performant hash funciton in the majority of cases than you'd think.

That's completely overkill. Nice as it may be that your IDE can fill in some code for you, I'd have do the reverse of implementing operator==: Erase most of that. This is all I'd want:

Code: [Select]

bool operator==(const Thing &clOther) const {
  if (this == &clOther)
    return true;
  // TODO: Fill this in.
  return false;
}
That's not nearly as annoying or time consuming to write as you claim it to be, albeit less convenient than having it already. No living templates needed here.

You're only accepting Thing. In Java, equals must accept an arbitrary Object, so to have a completely general equals, it has to consider the type. If you only expect to receive instances of the same object, there's an option for that in the generation window.

In addition, there's no dereferencing in Java. If you want to verify that member variables are equal, you have to do it in the verbose way that the IDE used.

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.

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

Squiggly red lines to me are more of a necessity and less of a fluffy feature. I'd much rather respond to errors as they crop up. Sometimes developing under the assumption that there are no errors leads to big problems and lots of wasted time.

Or just check to see if it compiles every so often ... you should do that any way, red lines or not. Of course, if you're stupid enough to write 1000 lines without checking if it compiles (even with red lines), you deserve what you get.

Right, but that's annoying and inefficient. That's exactly my point. I'm happy to agree that if you don't have reliable red squigglies, you should be manually checking if things compile. However, it's far less annoying to have that information as you type. I almost never have false positives for reasons that wouldn't be present using the build file anyway (need to resolve dependencies, pull changes, etc.)

That's very handy. I could definitely benefit from something like that.

All of the features I listed are, I think. They save a lot of time.

It's not like the IDE does much thinking for you. It just saves you the trouble typing when you know exactly what you want. That's what an IDE should do, I think.

Another handy one: if you want to pull the return value of some method call out into a variable because you've discovered you want to use it in another place, you just put the cursor over it, press Ctrl+Alt+V and type a name for the variable. It also detects places that you've made exactly the same method call and replaces it with the variable.

[nslay]

In Visual Studio, you spend time looking at a long list of files in the Solution Explorer. This is made less worse by grouping the long list of sources into subgroups. Although, seeing that we have so many constituent projects, it's already time consuming to scroll through the list of projects, expand the tree and then further find the source you want! Shell is more efficient here, especially when you know the source tree by heart. Of course, if you had a text filter like you claim IntelliJ has, that would help (although file finding in VS or Windows is slower than Unix find!).

That's completely ridiculous! I'd never navigate that way. I press Ctrl+Shift+N and type the name of the class/file I want and press Enter. There's no delay... the index makes it functionally instantaneous. Much, much faster than clicking through the source tree... does visual studio really not do that?

Once you have a file open, it's given a tab like a browser tab. The problem is, once you have too many of those tabs open ... it's equally burdensome to find. I generally try to remember to close tabs when I'm finished when having to use Visual Studio, otherwise it's really annoying.

And the Unix shell is definitely more efficient than Visual Studio ... by an enormous margin. There's no random freeze-ups, there's no reloading hundreds of projects when you regenerate a solution with CMake, there's no inability to find template definitions, there's no long monolithic list of sources to painstakingly scroll through, there's no 15 minute link time, there's no /MP glitches, there's no false positive red squiggly lines, there's no 10GB metadata files (which matters when you have terabytes of medical images on your drive) ...

But the biggest time wasters in Visual Studio are random freeze-ups and reloading project files. And it performs this way even on a modern OS like Windows Server 2008 on modern hardware (24 cores, 72GB of RAM).

These aren't problems in a Java development environment. This is all the more reason for me to steer clear of C++. I'll actually actively avoid companies that use C++ after hearing about all this nonsense. It sounds absolutely infuriating. I've worked with and been frustrated by small C++ projects; I guess I should've figured those issues would only compound as the codebase gets more complex.

I think with C++11, the future is very bright. All of <algorithm>, for example, becomes practicably useful with lambda expressions. Although, I have mixed feelings about the new template features (because people use templates to do unusual things that are hard to understand ... so-called template meta-programming).

Templates are always troublesome for Visual Studio to deal with (it almost never finds template definitions). It probably gets worse in C++11.

Then it seems you don't use a hash map for anything performant in the first place.

Uh... what? The generated hash function is good enough that it's still O(1) average time (instead of O(log n)). It's still much faster than a TreeMap, especially when the overhead is compounded by many terabytes of data (in groups of up to a few 1000).

And the worst case complexity of hash map is O(n). For a balanced tree, the worst case complexity if O(log n). So if you pick a bad hash function, then a tree theoretically beats your hash map. If your application is performance-sensitive, you really should write your hash function by hand. A default hash function won't generally exploit the structure of your keys.

My impression is that you'd probably not notice a big difference using a TreeMap for casual use ... or if it's only a thousand elements, probably searching an array is substantially faster than either a hash map or a tree map despite having a theoretical complexity of O(n).

Not that any of this matters for casual use of containers ...

Using HashMap along with the auto-generated hashCode provides enough speed improvement to justify using it over TreeMap and implementing compareTo.

As an aside: since every type in the java libraries that you could reasonably expect to implement a reliable hash function does, it's actually a lot easier to design a performant hash funciton in the majority of cases than you'd think.

That's completely overkill. Nice as it may be that your IDE can fill in some code for you, I'd have do the reverse of implementing operator==: Erase most of that. This is all I'd want:

Code: [Select]

bool operator==(const Thing &clOther) const {
  if (this == &clOther)
    return true;
  // TODO: Fill this in.
  return false;
}
That's not nearly as annoying or time consuming to write as you claim it to be, albeit less convenient than having it already. No living templates needed here.

You're only accepting Thing. In Java, equals must accept an arbitrary Object, so to have a completely general equals, it has to consider the type. If you only expect to receive instances of the same object, there's an option for that in the generation window.

operators and inheritance are ugly issues in C++.

In addition, there's no dereferencing in Java. If you want to verify that member variables are equal, you have to do it in the verbose way that the IDE used.

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.

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

Squiggly red lines to me are more of a necessity and less of a fluffy feature. I'd much rather respond to errors as they crop up. Sometimes developing under the assumption that there are no errors leads to big problems and lots of wasted time.

Or just check to see if it compiles every so often ... you should do that any way, red lines or not. Of course, if you're stupid enough to write 1000 lines without checking if it compiles (even with red lines), you deserve what you get.

Right, but that's annoying and inefficient. That's exactly my point. I'm happy to agree that if you don't have reliable red squigglies, you should be manually checking if things compile. However, it's far less annoying to have that information as you type. I almost never have false positives for reasons that wouldn't be present using the build file anyway (need to resolve dependencies, pull changes, etc.)

It's not that bad, Ctrl+F7 just compiles that one source file (rather than the whole project). You can't get away with this when writing templated classes and methods though ... and Visual Studio has a lot of trouble with templates so it always gives false alarms (or nothing). You usually have to wait until you can instantiate the class or method to see if it compiles.

That's very handy. I could definitely benefit from something like that.

All of the features I listed are, I think. They save a lot of time.

It's not like the IDE does much thinking for you. It just saves you the trouble typing when you know exactly what you want. That's what an IDE should do, I think.

Another handy one: if you want to pull the return value of some method call out into a variable because you've discovered you want to use it in another place, you just put the cursor over it, press Ctrl+Alt+V and type a name for the variable. It also detects places that you've made exactly the same method call and replaces it with the variable.

I'm sure Visual Studio can do some of what you described. I just don't know how to use it well enough to do those tricks.

Regarding return types, in C++11, now you can do something like this (which I have mixed feelings about):

Code: [Select]

auto clThing = clOtherThing.DoSomething(); // Return type inferred automatically

clThing.DoSomething();

EDIT: Small English corrections.

[Sidoh]

Once you have a file open, it's given a tab like a browser tab. The problem is, once you have too many of those tabs open ... it's equally burdensome to find. I generally try to remember to close tabs when I'm finished when having to use Visual Studio, otherwise it's really annoying.

Right, but I need to find files that aren't open dozens of times a day. I assume this is the case with you too? Do you really have to poke through the entire source tree any time you want to open a new file?

This isn't really a problem in IntelliJ either. I just leave everything open and press Alt+E, which lists recently opened files. You can then type to filter the list and press enter to open it. I hate using the mouse for this kind of stuff, and I'm really happy that I'm provided with efficient ways to circumvent moving my hand those six inches.

There's no way VisualStudio doesn't have something similar to this. It's too obvious a feature.

I think with C++11, the future is very bright. All of <algorithm>, for example, becomes practicably useful with lambda expressions. Although, I have mixed feelings about the new template features (because people use templates to do unusual things that are hard to understand ... so-called template meta-programming).

Templates are always troublesome for Visual Studio to deal with (it almost never finds template definitions). It probably gets worse in C++11.

Sounds really awful. 

And the worst case complexity of hash map is O(n). For a balanced tree, the worst case complexity if O(log n). So if you pick a bad hash function, then a tree theoretically beats your hash map. If your application is performance-sensitive, you really should write your hash function by hand. A default hash function won't generally exploit the structure of your keys.

My impression is that you'd probably not notice a big difference using a TreeMap for casual use ... or if it's only a thousand elements, probably searching an array is substantially faster than either a hash map or a tree map despite having a theoretical complexity of O(n).

Not that any of this matters for casual use of containers ...

Right, but in practice -- even with these generated hash functions -- a HashMap is much more performant than a TreeMap. It's performance-sensitive in that it's nice if it finishes a little faster. The distribution of group sizes is very widely spread for most data sets. Most reducers will have groups with millions of entries in a group, for example.

Most types used as keys are simple compositions of primitives, so it's quite easy to generate a good hash function algorithmically. It follows widely accepted best practices laid out in Effective Java. If you have a field that isn't a primitive, you can just incorporate the value of that object's hashCode into the return value.

These aren't crappy hash functions that are going to result in the O(n) worst case. In fact, I suspect that they're often better than hand-written hash functions because it's so easy to introduce error with this kind of fiddly nonsense.

operators and inheritance are ugly issues in C++.

Another win for Java (kind of)?

It's not that bad, Ctrl+F7 just compiles that one source file (rather than the whole project). You can't get away with this when writing templated classes and methods though ... and Visual Studio has a lot of trouble with templates so it always gives false alarms (or nothing). You usually have to wait until you can instantiate the class or method to see if it compiles.

I'm sure I'd learn how to function quite well without red squigglies, but I'm quite confident that it saves me many minutes a day by informing me of an error or oversight as soon as it becomes an issue rather than further down the line. You just can't get the same level of granularity if you have to manually kick off the compiler any time you want to check for errors.

This isn't the only advantage to red squigglies, though. Since the java compiler gives more information than just the line number, the IDE can highlight just the problem area, which often helps make the underlying problem a little more obvious.

I'm sure Visual Studio can do some of what you described. I just don't know how to use it well enough to do those tricks.

Regarding return types, in C++11, now you can do something like this (which I have mixed feelings about):

Code: [Select]

auto clThing = clOtherThing.DoSomething(); // Return type inferred automatically

clThing.DoSomething();

EDIT: Small English corrections.

Yuck. That seems like it'd throw many advantages that strong types provide out of the window. I'd much rather rely on my IDE to auto-infer the return type.

Code: [Select]

Thing thing1 = new Thing(new Stuff(1));
Thing thing2 = new Thing(new Stuff(1));

Would yield:

Code: [Select]

Stuff stuff = new Stuff(1);
Thing thing1 = new Thing(stuff);
Thing thing2 = new Thing(stuff);

I don't see much advantage in this "feature", do you? It seems something one would use purely out of laziness, but that's a problem the IDE should be able to take care of without throwing away all of the nice advantages type safety brings.

If the type of a variable is wrong, the IDE should be able to correct it for you. This comes up a lot, now that I think about it. I just cursor over the line with the error, press Alt-Enter, and there's an option to change the type of the variable. Same goes for return types of methods, parameters, etc.

[nslay]

Once you have a file open, it's given a tab like a browser tab. The problem is, once you have too many of those tabs open ... it's equally burdensome to find. I generally try to remember to close tabs when I'm finished when having to use Visual Studio, otherwise it's really annoying.

Right, but I need to find files that aren't open dozens of times a day. I assume this is the case with you too? Do you really have to poke through the entire source tree any time you want to open a new file?

This isn't really a problem in IntelliJ either. I just leave everything open and press Alt+E, which lists recently opened files. You can then type to filter the list and press enter to open it. I hate using the mouse for this kind of stuff, and I'm really happy that I'm provided with efficient ways to circumvent moving my hand those six inches.

There's no way VisualStudio doesn't have something similar to this. It's too obvious a feature.

I think with C++11, the future is very bright. All of <algorithm>, for example, becomes practicably useful with lambda expressions. Although, I have mixed feelings about the new template features (because people use templates to do unusual things that are hard to understand ... so-called template meta-programming).

Templates are always troublesome for Visual Studio to deal with (it almost never finds template definitions). It probably gets worse in C++11.

Sounds really awful. 

It's really not.

And the worst case complexity of hash map is O(n). For a balanced tree, the worst case complexity if O(log n). So if you pick a bad hash function, then a tree theoretically beats your hash map. If your application is performance-sensitive, you really should write your hash function by hand. A default hash function won't generally exploit the structure of your keys.

My impression is that you'd probably not notice a big difference using a TreeMap for casual use ... or if it's only a thousand elements, probably searching an array is substantially faster than either a hash map or a tree map despite having a theoretical complexity of O(n).

Not that any of this matters for casual use of containers ...

Right, but in practice -- even with these generated hash functions -- a HashMap is much more performant than a TreeMap. It's performance-sensitive in that it's nice if it finishes a little faster. The distribution of group sizes is very widely spread for most data sets. Most reducers will have groups with millions of entries in a group, for example.

Most types used as keys are simple compositions of primitives, so it's quite easy to generate a good hash function algorithmically. It follows widely accepted best practices laid out in Effective Java. If you have a field that isn't a primitive, you can just incorporate the value of that object's hashCode into the return value.

These aren't crappy hash functions that are going to result in the O(n) worst case. In fact, I suspect that they're often better than hand-written hash functions because it's so easy to introduce error with this kind of fiddly nonsense.

Fiddly non-sense? You know something about the key space: the distribution and the structure. You're throwing that information away. If you use it, it will almost certainly out-perform a one-size-fits-all solution. The fiddly non-sense is using a generic hash function for everything.

Of course, for casual use, none of this matters ...

operators and inheritance are ugly issues in C++.

Another win for Java (kind of)?

It's not that bad, Ctrl+F7 just compiles that one source file (rather than the whole project). You can't get away with this when writing templated classes and methods though ... and Visual Studio has a lot of trouble with templates so it always gives false alarms (or nothing). You usually have to wait until you can instantiate the class or method to see if it compiles.

I'm sure I'd learn how to function quite well without red squigglies, but I'm quite confident that it saves me many minutes a day by informing me of an error or oversight as soon as it becomes an issue rather than further down the line. You just can't get the same level of granularity if you have to manually kick off the compiler any time you want to check for errors.

This isn't the only advantage to red squigglies, though. Since the java compiler gives more information than just the line number, the IDE can highlight just the problem area, which often helps make the underlying problem a little more obvious.

I'm sure Visual Studio can do some of what you described. I just don't know how to use it well enough to do those tricks.

Regarding return types, in C++11, now you can do something like this (which I have mixed feelings about):

Code: [Select]

auto clThing = clOtherThing.DoSomething(); // Return type inferred automatically

clThing.DoSomething();

EDIT: Small English corrections.

Yuck. That seems like it'd throw many advantages that strong types provide out of the window. I'd much rather rely on my IDE to auto-infer the return type.

Code: [Select]

Thing thing1 = new Thing(new Stuff(1));
Thing thing2 = new Thing(new Stuff(1));

Would yield:

Code: [Select]

Stuff stuff = new Stuff(1);
Thing thing1 = new Thing(stuff);
Thing thing2 = new Thing(stuff);

I don't see much advantage in this "feature", do you? It seems something one would use purely out of laziness, but that's a problem the IDE should be able to take care of without throwing away all of the nice advantages type safety brings.

If the type of a variable is wrong, the IDE should be able to correct it for you. This comes up a lot, now that I think about it. I just cursor over the line with the error, press Alt-Enter, and there's an option to change the type of the variable. Same goes for return types of methods, parameters, etc.

The type is not lost at all. The compiler can infer the type from the return type of DoSomething(). C++11 is still a strongly typed language, it just makes more effective use of the compile-time type information.

[Sidoh]

It's really not.

It sounds really terrible, though. I'm not saying you can't work around it, but it just seems asinine that a developer would have to deal with any of that garbage. Seriously, I'd probably spend 10 extra minutes a day if I had to click through the source tree any time I wanted to open a new file. I generally have around 15k source files loaded. Sure, they're structured in a pretty sane hierarchy, but still: yuck.

The kinds of problems with C++ that you're listing are exactly what I hate about programming. I'd be so frustrated if I had to deal with that kind of crap on a daily basis. I suppose I'd get used to it pretty quickly, but I'd probably always be missing Java...

Fiddly non-sense? You know something about the key space: the distribution and the structure. You're throwing that information away. If you use it, it will almost certainly out-perform a one-size-fits-all solution. The fiddly non-sense is using a generic hash function for everything.

Of course, for casual use, none of this matters ...

It's not casual use, I assure you. There are certainly cases where it matters more to think about the hash function. I've been in that situation and dealt with it appropriately, I think. That being said, this doesn't come up often in contexts I'm very familiar with. Performance matters more than most things at my workplace, but tweaking a hash function is a lot less important than a dozen other optimization efforts. This is often the case with big data problems in general. Improving performance very rarely comes down to these kinds of small optimizations. It's almost always far more valuable to do things like: structure data to exploit sort order, avoid redundant reads over the data, and use approximation techniques like bloom filters and hyperloglog. These are all fairly obvious, of course, but it's pretty easy to introduce problems when working with high-level tools like Cascading.

A HashMap with an auto-generated hashCode is, in my experience, almost always more performant than a TreeMap with a manually constructed compareTo, so there's not really much to discuss on that front.

The type is not lost at all. The compiler can infer the type from the return type of DoSomething(). C++11 is still a strongly typed language, it just makes more effective use of the compile-time type information.

Right, I think that's why I said many of the advantages, and not all of the advantages. Maybe it's not much extra work for an IDE to find/refactor usages of a type under these circumstances, which is part of what I was worried about. It'd also be annoying if you were looking at some code that had one of these auto-inferred type variables where you cared to know what the type of said variable is. You just add an extra level of indirection... I guess the IDE could reveal that for you in place, but at that rate, you might as well just use the IDE to generate the actual type in the first place.

I guess I see some situations in which this might save a little bit of work, but not worth the nonsense, I think.

[Newby]

Not to interrupt you guys or anything, but I found that tmux literally transformed my life with shell productivity. I can argue that I am more productive with this than I am with an IDE, but I won't. I can't remember the last time I used an IDE.

[Falcon]

Not to interrupt you guys or anything, but I found that tmux literally transformed my life with shell productivity. I can argue that I am more productive with this than I am with an IDE, but I won't. I can't remember the last time I used an IDE.

Sounds a lot like screen.

[Newby]

Not to interrupt you guys or anything, but I found that tmux literally transformed my life with shell productivity. I can argue that I am more productive with this than I am with an IDE, but I won't. I can't remember the last time I used an IDE.

Sounds a lot like screen.

That's what I said. Then I discovered the pane feature. Juggling multiple shell sessions has never been the same. IT'S SO FUCKING SIMPLE AND EASY that it sometimes scares me.

[Sidoh]

I've been meaning to give tmux a try, Newby. I'm quite sure it would never replace an IDE, but it sounds like it'll enrich my terminal experience

[Sidoh]

tmux is pretty cool. definitely awesome to have a way to persist terminal layouts.

Newby, do you have any experience with setting up SSH sessions in tmux? I generally have four servers I want open connections with. Unfortunately, I have to use sudo to switch users, so I need to enter my password. I'm not super pleased with my solution, but it works. Any ideas?

[Newby]

Newby, do you have any experience with setting up SSH sessions in tmux? I generally have four servers I want open connections with. Unfortunately, I have to use sudo to switch users, so I need to enter my password. I'm not super pleased with my solution, but it works. Any ideas?

I work with a couple dozen or so servers on the daily. A properly configured config file (in ~/.ssh) is necessary. Not sure what you're getting at with sudo-to-switch-users, you can NOPASSWD sudo for your account or you can put the key in the ~/.ssh/authorized_keys account of the account you want to log in as.

Code: [Select]

$ grep -A 4 whatever.you.want.to.ssh.to ~/.ssh/psuedoconfig
Host whatever.you.want.to.ssh.to
    HostName full.hostname.here
    Port xx
    IdentityFile /path/to/private/key
    User blah
$ ssh whatever.you.want.to.ssh.to

Bam, you're logged in as blah on full.hostname.here with no password intervention. You can even have entries that are the same but with a different identity/username, if you want. I haven't tried it, but I log in as me and don't mind sudo'ing around as I type 140+ wpm... I generally re-type commands/words if I make a typo, it's just faster. So typing "sudo su username -l" and my password? Not a biggie.

I also took it one step further and aliased these.

Code: [Select]

$ alias fullshell='ssh full.hostname.here '
So I can do things like

Code: [Select]

$ fullshell (instantly logged in)
$ fullshell uname -a (runs uname -a on full.hostname.here, returns it)
And other shorthand conventions which are super useful in mass:

Code: [Select]

for host in hostone hosttwo hostthree hostfour; do ssh $host -- <some remote command i want to run on everything>; done

[Sidoh]

Right. I have ssh keys set up so I can get into each of the servers as my account, but there's a single account we use to run most of our hadoop processes, etc. So after logging in, I need to do sudo -u username -s or something like that.

It's not that it takes a lot of time or anything. It'd just be super nice to be able to attach tmux and have all of the sessions already connected.

Right now I'm doing something like this:

Code: [Select]

function tmux-sr() {
  tmux send-keys "lockfile -r 100 $SSH_LOCK \
    && ssh -t $ENTRY_SERVER sudo -K \
    && ssh -t $ENTRY_SERVER \"echo \$(vpn_password) | sudo -u $ENTRY_USER -S -i uptime\" \
    && rm -f $SSH_LOCK \
    && nocorrect ssh -t $ENTRY_SERVER sudo -u $ENTRY_USER -i $*" C-m
}
vpn_password is an alias that extracts my password from the keychain.

This works well enough, but I feel like there has to be a better way.

[Newby]

This works well enough, but I feel like there has to be a better way.

This seemed promising but I haven't tried it myself. Yet!

Also of productive note, totally not about IDEs but related to vim so it's noteworthy: vimium has also increased my productivity, I pretty much only have to use the mouse to navigate webmail* or do mouseovers. Or control Pandora. Thankfully it's a radio and takes care of itself most of the time.

[Sidoh]

This works well enough, but I feel like there has to be a better way.

This seemed promising but I haven't tried it myself. Yet!

Also of productive note, totally not about IDEs but related to vim so it's noteworthy: vimium has also increased my productivity, I pretty much only have to use the mouse to navigate webmail* or do mouseovers. Or control Pandora. Thankfully it's a radio and takes care of itself most of the time.

Right. I'm already doing something like that to set up the pane layouts. The trouble is, some of the panes require that I enter my password in order to complete setup. I'm wondering if there's a reasonably elegant way to do that. What I have now works, but it's a piece of shit mess.

yeah. vimium is pretty cool.

what do you mean webmail*? do you not use gmail? the gmail keyboard shortcuts are pretty great.

edit: lol, i just remembered where you work.

[while1]

I can't stand Eclipse.  Sure it's free, but it has one of the most horrible menu systems out of all IDEs I've ever used... and the way it saves/ stores projects and workspaces makes team development a pain sometimes.  I'll take IntelliJ over Eclipse any day of the week.  JetBrains ranks probably #1 in my book in terms of a company that makes outstanding dev tools/ IDEs.

I agree that Visual Studio is goddamn slow at times.  I've had to kill the devenv.exe countless times and expect to do so countless more.