Well, it all depends where you put your reference, doesn't it? Visual Studio slows me down like hell (that means my head runs in idle while VS is doing weird things). Eclipse isn't that bad, but both are bloated with unuseful crap. Unluckily, everything that is not bloated with unuseful crap will be waved away as being "not professional", whatever that means.

I have tried a few IDEs and stuck with QtCreator, which is lighting fast, faster than my fingers are. It copies many good concepts from Eclipse, like code navigation, but does that with enormous speed. It doesn't brag with 20 menus that each have 50 submenus, but instead supports you invisibly.

There is one disadvantage though: You can't go to fetch coffee when IntelliSense updates..
{"name":"visual-studio-wait.png","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/a\/4\/a4e23e39e3b1c44962ac2eea709414fd.png","w":589,"h":185,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/a\/4\/a4e23e39e3b1c44962ac2eea709414fd"}
Source: http://www.donkitchen.com/2009/07/03/visual-studio-2008-is-a-piece-of-shit/

These are the features I deem mandatory in my code editing program:

• Smart autocompletion + preview documentation

• Goto implementation/goto definition

• Find all references

And another I can live without but is still very useful is support for snippets.

These features are required from a debugger:

• Highlight current line, next(into/over), break, pause, set next instruction etc.

• Watch variables, evaluate expressions, show all local variables

• View Stack

• Watch memory

• Smart breakpoints (break on hit count, when an arbitrary expression is true or an address has been modified)

Other things that are needed:

• Code profiling/coverage

• Source control

Using Visual Studio with Visual Assist X and DevPartner + plugin from your favorite source control has you covered on all fronts, and you can do all of those quickly (There's keyboard shortcuts for everything you need). Incredibuild is also priceless.
I've never run into cases where I feel slowed down by this setup, so I feel that this sort of proves that an IDE is a great way to do your thing.

Of course, my requirements are tainted by what I'm familiar with, so if you've got anything to add to that list or any reservations...

EDIT: Other useful things: (still covered under an IDE)

• I also really like a cpu register/sse/fpu window available in a debugger (with the ability to show assembly code of course).

Not exactly, its a "shortcut" for an often repeating pattern of code.
For example, you might start with the code:

RValue = Foo(x,y,z);
RValue

You highlight the lower RValue and choose the "Check for failure snippet", then it pops a dialog where you enter the text X, hit enter and it automatically inserts:

if (FAILED(RValue))
{
    Logger.Log(X);
    return RValue;
}

You can manually define any code snippet you want to paste, and map it to any name (so you could make so you start typing Try and it will morph it into

try
{

}
catch(exception &e)
{
}
finally
{
}

Or whatever you want.

I guess if you wanted to just use it to manage a library of useful snippets of code you could do that as well :X

</quote>I also really like a cpu register/sse/fpu window available in a debugger (with the ability to show assembly code of course).</quote>
Visual Studio also has those, and they are really useful, I'll add them to my post.
(For those that don't know, just watch "eax" to see eax, and you can hit alt+8 while debugging to debug the assembly code)

By now you should have learnt to take everything I say with a pinch of salt.

I spent nearly a week trying to get someone's EJB project (along with a GWT font-end) to work. Up until then he had been the only person working on it, and had used a million different Eclipse addons. It was a Maven project, but his POM file was a disgusting mess - as bad as the worst ant script I've ever seen (in fact, he had used a library which allowed him to embed bits of ant scripts in his POM file ). It was the most horribly excruciating experience of my life and I ended up giving up and telling him to get it working from a fresh check-out on a fresh machine - which he still hasn't managed to do months later!

So I agree, like anything, it's possible to screw it up if you really try.

http://msdn.microsoft.com/en-us/library/ee662426.aspx

msbuild foo.vcxproj

It works with solutions too. For example:

msbuild allegro.sln

The IDE uses msbuild, so it should be feature complete albeit it probably via switches that are meant to be machine generated.

A graphical UI's biggest strength is the mouse. It's designed first for use with the mouse and the keyboard shortcuts are applied after. I would be fascinated to watch somebody use Visual Studio with the keyboard only because I imagine it would be very obscure and a lot of work. I doubt that anybody really does it. A GUI encourages the mouse and I know that most users predominantly use the mouse with them. Despite using Vimperator first and now Pentadactyl with Firefox, I'm still forced to use the mouse on a regular basis to the point where I often use it even when I don't have to just because it's habit...

It's nice that you imagine that something is hard, but here in the real world it is possible, easy and comfortable. Even I^[1] only use the mouse for highlighting text and for quickly navigating a file^[2]. (and manipulating the source control I guess)

I 3D modeling keyboard shortcuts are essential.
Blender has a steep learning curve, but once you've got the most basic shortcuts down you can work without feeling interrupted every time you need to go through menus to do something.

The key concern with shortcuts is that you don't need to move your eyes away from what you're working on.

It's a culture clash, really.

On one side, there's the IDE crowd, using large, complex, but comfortable tools to make their lives easier. The IDE somewhat prescribes certain aspects of your workflow, project structure, and even team organisation, but as long as you don't try to fight this, and you have sufficient hardware resources to feed the IDE, it can be an extremely productive way of working (I've been there, and it's definitely not bad).

On the other side, there's the UNIX crowd, with their mantras of 'small, sharp tools', textuality, 'do one thing right', etc. etc. The tools are spartanic by themselves, but they do exactly what you tell them, nothing less, nothing more, and they form the building blocks of an incredibly flexible and powerful programming environment.

I could do some things really fast in Visual Studio, and that was great. But other things were excruciatingly hard, and required an obscene amount of repetitive manual work. At one point, I was refactoring a horribly bad class, changing the parameters for the constructor. That class was used just about everywhere, hundreds and hundreds of occurrences of the same constructor, with dozens slight variations, and I had to change them all. I ultimately resorted to using vim for the task.

These days, I don't know where I'd be without vim. Just a few features that make it all worthwhile:

• macros. Utterly awesome. You type qn, where n is a letter of your choice, at which point vim starts recording everything you type, until you hit q again. The n register now contains the key sequence you typed, and by typing @n, you can play it back, feeding the contents of the n register back into vim's command interpreter. But it gets better: if you've made a mistake while recording, you can paste the recorded key sequence into your text, edit it, and yank it back into the same register, and then execute the edited macro.

• shellouts. Almost equally awesome. When vim isn't enough, you can select some text and pipe it through any shell command; the command's output replaces the original text. One of my favorites is :%!xmlindent; another nice one is :%!cat filename - just insert the contents of filename into the current document.

• the gf command - step on a filename, type gf, and bam, you're there.

• ctags - especially when exuberant-ctags is available. It's like a precalculated baseline for intellisense, designed to keep working as much as possible even if the source code changes (and when it is really too outdated, YOU get to decide when to run it again). Combined with vim's built-in autocompletion, it gets pretty close to a proper IDE's autocompletion, but there is zero background activity (by contrast, Netbeans or Visual Studio suck up considerable amounts of CPU cycles just to keep their autocomplete data up-to-date).

Yes.
alt+shift+o - goto file in project. (Hit it, start entering filename and it shows all matches for what you entered so far, hit enter to choose)
alt+o - switch between header and implementation. (essentially if you are viewing foo.c it takes you to foo.h and the other way around.)
alt+g - goto definition/declaration. If you hit this when over a name (variable, function, macro etc.) it will offer to take you to where it is defined or where it is declared (depending on context, and if it can't tell it allows you to choose). This is if course cross-file
alt+left - go back to your previous location. So if you just pressed alt+g to view exactly how that function is defined you can hit alt+left and go back to where you were just using it.
All of these are basic and vital when working with visual studio.

It might help, but it doesn't change the fact I'm bad at remembering them.
I worked an entire semester with Emacs and all I managed to fit in my head is: open/save/copy/cut/paste, and now I don't remember any of it.

Sure, but none of us really know precisely how things work for the other guy, so we can't really compare, and so long as everyone is happy with their way...
How about we agree that doing anything from the command-line in Windows is a disaster

FTFY. I still prefer the command line for most things in Windows (it's a lot faster and more reliable for file operations, for example), but it sucks compared to a UNIX shell.