I believe we agree that you do not see it. :)
> Good thinking and coding does improve kernel quality. Debugger
> certainly does not help if someone cannot code.
And reading glasses won't help someone who can't read. Is your above set of
statements somehow meant to imply that a debugger cannot help someone who CAN
code? (Logic. Logic is good here.)
A similar argument would be "Nobody should own an oven. If you can't cook
you'll just make a mess."
> A debugger can do some good things. Some people argue that it
> improves productivity, which I think may be true under some
> circomstances.
It's a tool. Does anybody really disagree about its nature?
The main purpose of tools is to save time. No tool is a substitute for
skill. it's possible to do everything a debugger can do via printks out to
the printer and having a stack of source code printouts, and doing all your
debugging in pencil. It's also possible to pound in a nail with a rock, if
you think hammers are for sissys.
If you stop and think about it, it's sort of like amish kernel development,
isn't it? (Hey, we've already got the community barn raising aspect. Now
let's outlaw certain construction techniques! :)
> If you work with something like Linux, and compile on something
> better than a 333MHz x86, it probably does not help your
> productivity.
I had the source code to the contractor-produce pile of cruft I worked with
under OS/2. I could even read some of it, given enough time. Trust me, a
source debugger REALLY helped find the differences between what it was
supposed to be doing and what it was actually doing. (Or more accurately,
the few places where what it was supposed to be doing and what it was doing
matched up...)
> This is all wonderful, but has nothing to do
> with the code quality.
I think we agree. So why recommend against debuggers if they save time and
effort while producing patches of equal quality?
> And to think that your users would be happier with a crap produced
> by a debugger touting Windows graduate
Sure, blame the tool. :)
> than with a quality code
> debugged with observation simply defies any reason.
So the state of the running kernel is more observablee without a kernel
debugger than with one?
Debugging means, basically, "this sucker is doing something I didn't expect
it to, and I have to find out what". A debugger is a tool with which to
examine running code. It doesn't help you write the stuff, just examine it.
The proper tool for the proper job...
The unix philosophy has always been to give people enough rope to shoot
themselves in the foot with. I'm just wondering why the exception. (Yes I
read the "bastard" speech. It seemed to boil down to a crude sturgeon's law
filter because Linus was once again being overwhelmed by crap patches (an
annual event around here). Making less than perfect coders code blind won't
increase the quality of anything, but might decrease the quanity. I suppose
that's one way of addressing the problem, but doesn't seem to me to be an
optimal solution...)
> -- Pete
Rob
(P.S. Don't mind me: I have a cold. If the above comes out as anything even
resembling english, I'm ahead of the game...)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/