I'd respectfully disagree on VS 6. It was OK for its time, but hardly a piece of art, in my experience.
Please excuse me copying the relevant portion from my other comment.
VS 6's support of C++ back in 2005 wasn't that great, at leat the way I remember it now.
Code navigation was very primitive, and you were lucky if it didn't consider the code too complex to offer any navigation around it at all.
Its built-in debugger often wouldn't let you inspect a string's content because it was just another pointer from the debugger's perspective.
And there was a bug, where the editor would slow down so much it would be littery unusable -- e.g., it'd take a couple seconds to react to a key stroke. The reason was it kept a file with the workspace's (solution in today's terms) code metadata and that file grew too big over time. So you had to remember to delete it regularly.
But VS 6 had a great plugin -- Visual Tomato, if memory serves -- that made things so much better in terms of code navigation/refactoring/etc.
Compared to modern IDEs it won't do very well, but do you remember better alternatives back then, at least if you wanted a "friendly" UI instead of a command line one? Would you choose something different if you go back to 2005? how about 1998?
Oh, back at the time it was a good. IDE. There was also C++ Builder, but it had its own quirks, of course. Picking one of them was, I guess, a matter of personal preference, the project's requirements, etc.
Anyway, I sure see how my comment may sound that way, but I didn't really mean to contrast JB vs others. Comparing a modern IDE to its old version in the context of software bloat is the whole point I'm trying to make.
I think bloat is not the only reason for increased hw requirements. Modern software is often way more capable than its old versions and adding capabilities seems like a good use of added hw power.
I see how my comment may sound that way, but I didn't really mean to contrast JB vs others.
A better idea woud've been comparing a modern version of VS with VS 6, for example.
Anyway, my point is bloat is not the only reason for increased hw requirements. Modern software is often way more capable than the old and adding capabilities seems like a good use of added hw power.
This is a bit similar to the concept of accidental vs inherent complexity in sw engineering. There's accidental bloat and inherent "bloat", so to speak:)
My impression is people don't usually acknowledge the existence of inherent "bloat" in discussions like this one.
Please excuse me copying the relevant portion from my other comment.
VS 6's support of C++ back in 2005 wasn't that great, at leat the way I remember it now.
Code navigation was very primitive, and you were lucky if it didn't consider the code too complex to offer any navigation around it at all.
Its built-in debugger often wouldn't let you inspect a string's content because it was just another pointer from the debugger's perspective.
And there was a bug, where the editor would slow down so much it would be littery unusable -- e.g., it'd take a couple seconds to react to a key stroke. The reason was it kept a file with the workspace's (solution in today's terms) code metadata and that file grew too big over time. So you had to remember to delete it regularly.
But VS 6 had a great plugin -- Visual Tomato, if memory serves -- that made things so much better in terms of code navigation/refactoring/etc.