Part of the tools issue arises because C++ insanely hard to parse (the preprocessor makes it even harder); recovering programmer intention from something that i

Part of the tools issue arises because C++ insanely hard to parse (the preprocessor makes it even harder); recovering programmer intention from something that is "almost" C++ is an exercise in futility. This is, I think, a genuine problem with the language. There are of course good arguments in the "Java wouldn't need such good tools if it was a better language" camp; best of both worlds would be a language that's easy to write tools for but doesn't really need them. With regard to debugging, I think you're being unrealistic. You're comparing debugging on a fully introspective and managed virtual machine to debugging annotated assembly language. Apples & oranges. If a fully managed VM meets your needs, then use it. If it doesn't, well, welcome to low level programming. You also make it sound worse than it is; JVM debuggers aren't perfect either: they debug Java-the-language fine, but other JVM languages are more problematic. Good luck with JNI, too. Likewise, there are C++ debuggers which are STL-aware, and even those that aren't can usually be coaxed into displaying pointers as arrays or as supertype pointers. Using gdb directly is rarely necessary; there are perfectly decent frontends. If you're having problems because you're trying to debug compiler-optimised C++, then you're simply running into the limits of the platform. Debugging post-JIT Java is no fun either.