I never encountered anyone in real life who was a huge profiler fan, like they thought it was super necessary, even though I know quite a few who use them (sometimes? Often? I am not sure.). Some people apparently think that's the case and it got me thinking of the subject of profilers and debuggers.
1. Profilers. First off there were no profilers when I learned to program, and none in college. They might have existed yet but at any rate there were none at my school, and I don't think they existed yet. Maybe that colors my feelings a bit. At any rate I don't think they are necessary at all, I don't know of any super awesome programmer with decades of experience who can't live without them, except on the net where that describes everyone.
In theory it's good but I noticed something that I always thought was true of debuggers: laziness. When people WERE using profilers to measure performance it's like a light switch turned off in their head. It's an automatic tool and it leads to an automatic mental process. You find the part that takes the most time and optimize it. But what happens when your part taking the most time is something like string concatenation?! Then you start making a really cool string class that has super fast string concatenation! At least until Graelig finds out about it and stops the madness by helping you find the real problem!
You also conflate things together that are nothing to do with each other. So even if something like stringcat or a less obviously bogus thing like a cos function is taking most of your time, that doesn't mean that all of these calls are equal. It can be the case that only SOME of these are part of the problem. Calling it in one location is find, in another it is not. Because it's not the cos function that's bad, it's something around it that's bad, so to speak.
So there is a negative side, most importantly, though what's the positive? That is where I wrack my brains. I mean, what does it do you can't do yourself, and do better? If you worked from the top down you would easily get to whatever performance bottleneck you have. What case will it make jump out for you that would be hard to find on your own? There is none I can think of. It highlights the most simple cases, which are easy to find anyway, but can actually help conceal the more problematic cases.
2. Debuggers. I touched on this before about laziness. People have been shocked to learn that I have done so much C++ and assembly while never using a debugger until relatively recently.
Well, I don't know the history of debuggers, but they have been around in some form since I learned to program. Man oh man they were crappy though. Extremely crappy and slow, and you could step through things and miss what was going on.
But a lot of people did like them, some swore by them.
The problem I have is, really they don't help with LOGIC per se. What I mean is, if you really make a bug, a serious bug and not some typo, it is going to trace through just fine and you will have to spend a lot of time tracing to spot it. Like if a sort is sorting backwards or something. Like you have the totally wrong approach to solving a problem. Your debugger won't really find this, not easily anyway. You will kind of have to figure this out on your own regardless of what outputs you are looking at.
It does help with the simple cases, but again the simple cases are easy anyway. After you have decent programming experience you usually know what went wrong the instant it goes wrong - for these simple cases I mean. And you just don't make errors like leaving off the i++ on your for loop any more after a certain point anyway it just becomes so automatic.
Your eyes are much better at scanning code than a debugger is at tracing through to just the right spot.
But in time I changed my mind here to some degree. I still think that using the debugger in THAT way is a waste of time exceptfor when you are learning. But debuggers are a lot better now and are quite useful for crash situations, which could be a fair pain at times without them - though again you get used to what's going to cause it and how to avoid getting into those situations. But you could get screwed by say someone else's code that had to work with YOUR code crashing when you use it because they created a bug like failing to initialize something and you inhereted their bug, and 'they' are some OEM in Hong Kong that it costs thousands of dollars to open a support ticket with and always wastes days and days of your time.
For that, modern debuggers are brilliant, and nowadays C++ is almost as pleasant to program for as Java.
Anyone else feel the same? Or is it only pod people left these days?