I posted a earlier blog about wanting support for managed co-routines in the next version of VS. Interestingly enough, that didn't garner much interest. Instead, what seemed to pique people was the fact that i really don't use a debugger when developing managed code. It wasn't a boast, just something I'm observed. The single highest contributing factor is probably that i develop in a completely different way between managed/unamanaged code. Because unmanaged code (C++) is so high maintenance I tend to code in way that allows me to implement the logic i want as quickly as possible with unnecessary overhead. High maintenance in this sense refers not to conceptual complexity, but purely from a coding complexity stand point. The need to maintain header/implementation files. The enormous amount of error handling and keeping track of memory that I have to do in unmanaged code leads me to normally create large methods with a lot of logic in them that i end up needing to debug to understand.
Refactoring that code into something simpler and more maintainable is extremely hard to do because you can't just extract methods (or any other number of refactorings) because in general you end up having to do a lot of extra effort yourself to handle a lot of the nasty stuff that the runtime does for you autimatically now.
With managed code I tend to write smaller, simpler objects with simple messages that are easy to understand and verify. Tracking a bug down is usually quite simple because you'll either have an exception, or you can pretty easily figure out where the error occurred. Fixing the bug is just a matter of asking: "ok, who could have called this with the wrong values", sitting and mulling on it, and then, in a gestalt flash realizing the issue, fixing it, rerunning and having everything work fine.
I've also noticed this when coding in a functional language. Except the difference is much more marked in that case. Generally if the code compiles then it's correct. And if it's not it's very very obviously not. i.e. on the first input to the system it will be clear the whole thing is borked.
Maybe I do actually use a debugger on my code. Except that the debugger is more a function of a good compiler/runtime/unit tests than an actual tool that i fire up. What does the debugger get me? A callstack... which is probably not useful because my methods shouldn't really care about who called them. Values of variables... which is usually not to useful because I should understand what the values could be through the use of immutable objects which validate at construction time and method that validate upon entry.
Is it just me, or are there others out there who have found that they use a debugger less and less (or not at all)?