Debuggers

[jacob navia]

We know from my last installments, that there are some people here that
go around telling "there is no stack in C", because the word "stack"
doesn't appear in the C standard.

Apparently, more or less the same people, start telling that
it is enough to read the code to be able to debug a program,
without using such low level tools like a debugger.

Having written a debugger, and passed countless hours of my professional
life using those tools (gdb, dbx, msvc, and many others) I am
suprised that people like Mr Bos can say in this forum
that it is sufficient to READ the code to be able to debug it.

> "It is impossible for any human to DEBUG a program written by others
> without a debugger, of course if the program has a certain size
> (bigger than, say, 1500 -2000 lines)"

This was translated by Mr Bos into:

" its author is (by his own admission, in
that other thread) incapable of READING code beyond 2000 lines"

I complained that this was a LIE, i.e. a complete misrepresentation of
what I said.

Mr Heathfield and Mr Bos answered, (in substance) that since I could not
debug a program of more than 1500-2000 lines without a debugger I am
unavle to read it, since if I would be able to read it I would spot
the bug immediately.

Now, question for the people that keep a small part of common sense
here:

Is *reading* a program the *same* as *DEBUGGING* a program?

Are serious people here willing to believe this stories of people
debugging huge code bases without a debugger?

I stay by my position:

A code base bigger than 1500 lines is no longer debuggable in an
abstract sense just by reading code. It needs a debugger.

Note that we suppose a real-time, event-driven code execution,
where you can have faulty libraries, faulty interrupts servicing
programs, etc. ANYTHING.

 

[Johannes Bauer]

Now, question for the people that keep a small part of common sense
here:

Is *reading* a program the *same* as *DEBUGGING* a program?

No it isn't.

Are serious people here willing to believe this stories of people
debugging huge code bases without a debugger?

I am not. While I disagree on some points with your opinion (especially
concerning OS specifics) I have to say I absolutely second your opinion
on this one.

I stay by my position:

A code base bigger than 1500 lines is no longer debuggable in an
abstract sense just by reading code. It needs a debugger.

Absolutely. Sometimes the code might even be shorter, but more
complicated. I've seen race conditions in embedded systems in code which
way even *way* shorter (say 300-500 lines) which were just plain
impossible to find without a good hardware debugger (like a Lauterbach).

Regards,
Johannes

 

[Ben Bacarisse]

Having written a debugger, and passed countless hours of my professional
life using those tools (gdb, dbx, msvc, and many others) I am
suprised that people like Mr Bos can say in this forum
that it is sufficient to READ the code to be able to debug it.

It is obviously sufficient in that people have done so for decades.
There can be a lively argument about whether is it desirable, optimal,
the right way for everyone and so on, but it is undeniably possible.

I did that for living. In the days of punched cards there were no
debuggers (at least not for the likes of me) and inserting print
statements was way too slow. My job was to find the bugs in other
people's programs. Some were several thousand "lines" long.

It is possible and I can't see how you can think it is not.

Now, question for the people that keep a small part of common sense
here:

Is *reading* a program the *same* as *DEBUGGING* a program?

Only of the end result is the elimination of an error (i.e a bug).
Some writing (or punching) is obviously required as well.

Are serious people here willing to believe this stories of people
debugging huge code bases without a debugger?

Honestly, how can you doubt it? You must know that bugs existed
before debuggers and people were, on occasion, able to remove them.

 

[santosh]

We know from my last installments, that there are some people here
that go around telling "there is no stack in C", because the word
"stack" doesn't appear in the C standard.

Apparently, more or less the same people, start telling that
it is enough to read the code to be able to debug a program,
without using such low level tools like a debugger.

Having written a debugger, and passed countless hours of my
professional life using those tools (gdb, dbx, msvc, and many others)
I am suprised that people like Mr Bos can say in this forum
that it is sufficient to READ the code to be able to debug it.



This was translated by Mr Bos into:

" its author is (by his own admission, in
that other thread) incapable of READING code beyond 2000 lines"

I complained that this was a LIE, i.e. a complete misrepresentation of
what I said.

Mr Heathfield and Mr Bos answered, (in substance) that since I could
not debug a program of more than 1500-2000 lines without a debugger I
am unavle to read it, since if I would be able to read it I would spot
the bug immediately.

Now, question for the people that keep a small part of common sense
here:

Is *reading* a program the *same* as *DEBUGGING* a program?

For some small set of programs it *could* be enough to debug it by
reading it's source.

Are serious people here willing to believe this stories of people
debugging huge code bases without a debugger?

I stay by my position:

A code base bigger than 1500 lines is no longer debuggable in an
abstract sense just by reading code. It needs a debugger.

I would consider the code's complexity and it's interaction with outside
environment rather than merely it's LoC count. A data compression
program for example has a fairly simple I/O logic and it usually not
event driven, so it may be possible to debug it by reading the source
code, even if it were more than a few thousand lines.

Remember, well placed assert and printf can pinpoint out the function
which failed, so you don't always have to read the entire program's
source to debug a failing function.

It depends very much on the nature of the bug. A typo in rather easy to
catch. Something like a buffer overflow is quite a bit harder, without
appropriate tools, particularly if the effects of the overflow are
insidious.

Note that we suppose a real-time, event-driven code execution,
where you can have faulty libraries, faulty interrupts servicing
programs, etc. ANYTHING.

Ah OK. A runtime debugger would be very useful I admit. That's not to
say that specific bugs in specific programs can't also be caught by
other methods.

A combination of assert, printf, unit testing, desk checking and runtime
debugging with a debugger and memory bounds checker ought to catch most
bugs. Use whatever works for the program in hand, IMO.

 

[Richard]

It is obviously sufficient in that people have done so for decades.
There can be a lively argument about whether is it desirable, optimal,
the right way for everyone and so on, but it is undeniably possible.

Swimming the Atlantic is possible. I prefer to fly.

I did that for living. In the days of punched cards there were no
debuggers (at least not for the likes of me) and inserting print
statements was way too slow. My job was to find the bugs in other
people's programs. Some were several thousand "lines" long.

Yawn. Debuggers DO exist now. I started with assembler and no
debugger. So what? We are talking C NOW.

It is possible and I can't see how you can think it is not.

Oh for goodness sake. It is "possible" to do anything. But why bother to
spend weeks finding that in one case its NOT possible? Use the damn
debugger for crying out loud.

Only of the end result is the elimination of an error (i.e a bug).
Some writing (or punching) is obviously required as well.


Honestly, how can you doubt it? You must know that bugs existed
before debuggers and people were, on occasion, able to remove them.

Arrrghhhhhhhhhhhhh!!!!!!!!!!!!!!!!!!!

For the record:

Yes, people CAN find SOME bugs without a debugger.

But WHY would one bother in 99.999% of the times when a debugger is
available.

What is it with CLC and mindless word games all the time? It's surreal.

 

[Richard]

For some small set of programs it *could* be enough to debug it by
reading it's source.

You miss the point. Yes one CAN "debug" when reading but reading is NOT
the same as active debugging.

I would consider the code's complexity and it's interaction with outside
environment rather than merely it's LoC count. A data compression
program for example has a fairly simple I/O logic and it usually not
event driven, so it may be possible to debug it by reading the source
code, even if it were more than a few thousand lines.

Remember, well placed assert and printf can pinpoint out the function
which failed, so you don't always have to read the entire program's
source to debug a failing function.

It depends very much on the nature of the bug. A typo in rather easy to
catch. Something like a buffer overflow is quite a bit harder, without
appropriate tools, particularly if the effects of the overflow are
insidious.


Ah OK. A runtime debugger would be very useful I admit. That's not to

What do you mean, a runtime debugger? Do you use debuggers?

say that specific bugs in specific programs can't also be caught by
other methods.

No one has said anything different.

A combination of assert, printf, unit testing, desk checking and runtime
debugging with a debugger and memory bounds checker ought to catch most
bugs. Use whatever works for the program in hand, IMO.

printf is amateurish and frowned upon. Asserts litter the code
unnecessarily IMO but have their uses.

Remember : the removal or addition in any module of ONE printf could
trigger and entire QA phase.

use a debugger and no changes to the code are required bar compile with
debug info on. Then the bug is found and ONE module is then (generally)
updated to make that fix.

 

[Chris Dollin]

I stay by my position:

A code base bigger than 1500 lines is no longer debuggable in an
abstract sense just by reading code. It needs a debugger.

If you've dropped your "by multiple people" clause, and by "debugger"
you mean what I read most other people as meaning -- something like
gdb, rather than something like fprintf statements -- then your first
sentence may be true, but your second sentence isn't.

(fx:grope)

My Cayenne compiler & linker appear to be roughly 9000 lines (of Cayenne).
[Hmm. OK, there are misleading Web hits for Cayenne; this isn't any of
them. My Cayenne is a Pop11 derivative; Algolish syntax, Lispy datatypes,
open stack for multiple values.]

My Spice-and-ECMAScript compiler/interpreter appears to be roughly 20000
lines of C. [Spice is another Pop11-inspired language, not the circuit
simulator thingy.]

[Neither of these is public; sorry.]

I believe the most I've used a debugger for on those was to get a backtrace
after a coredump.

Note VERY CAREFULLY that I am NOT claiming that either of these is bug-free,
nor am I claiming that using a debugger on either of them would have been
pointless. I'm saying that they WERE developed with such minimal use of
debuggers. Nor were the bugs that manifested particularly hard to find.
The compiler/interpreter did have controllable logging code, which I
wouldn't count as "a debugger" but Jacob might. These were from my pre-TDD
days, so I didn't even have unit tests to comfort me, but I did have
a testbase of sorts.

 

[Joachim Schmitz]

We know from my last installments, that there are some people here
that go around telling "there is no stack in C", because the word
"stack" doesn't appear in the C standard.

Apparently, more or less the same people, start telling that
it is enough to read the code to be able to debug a program,
without using such low level tools like a debugger.

Having written a debugger, and passed countless hours of my
professional life using those tools (gdb, dbx, msvc, and many others)
I am suprised that people like Mr Bos can say in this forum
that it is sufficient to READ the code to be able to debug it.



This was translated by Mr Bos into:

" its author is (by his own admission, in
that other thread) incapable of READING code beyond 2000 lines"

I complained that this was a LIE, i.e. a complete misrepresentation of
what I said.

a lie is very different from a misinterpretatation.

Mr Heathfield and Mr Bos answered, (in substance) that since I could
not debug a program of more than 1500-2000 lines without a debugger I
am unavle to read it, since if I would be able to read it I would spot
the bug immediately.

And in response you called one a liar and the other a moron, which is just
inacceptable behavoir.

Now, question for the people that keep a small part of common sense
here:

Is *reading* a program the *same* as *DEBUGGING* a program?

reading and understanding the code will enable to debug the code.
You need to write/modify the code to debug it, i.e. to remove the bug.
Without reading and understanding the code it won't be possible to find any
bug.

Using a debugger won't debug code (so calling it debugger is a misnomer, the
only real debugger is the editor), at best it'll show where the bug is,
provided (once again) that you read and understand the code.
A debugger may be a great help in finding the bug. On the other hand
sometimes it even hinders finding it.

Are serious people here willing to believe this stories of people
debugging huge code bases without a debugger?

Yes. The ability (or lack thereof) to do this myself isn't relevant to that
believe.

I do know from 1st hand experience that is even possible without reading the
code (well, in this case that guy didn't need to read it it, he knew it,
because he wrote it)

I stay by my position:

A code base bigger than 1500 lines is no longer debuggable in an
abstract sense just by reading code. It needs a debugger.

More importantly it needs a documentation, a description of the
architecture.
Lacking that you can only resort to read the code to reverse engineer that
description

Note that we suppose a real-time, event-driven code execution,
where you can have faulty libraries, faulty interrupts servicing
programs, etc. ANYTHING.

Bye, Jojo

 

[Richard Heathfield]

jacob navia said:

We know from my last installments, that there are some people here that
go around telling "there is no stack in C", because the word "stack"
doesn't appear in the C standard.

To be more precise, the C Standard does not require implementations to use
a stack. If an implementor finds it easier or more robust or more
efficient to provide, say, function calls and auto objects and the like
using some other mechanism, he has the freedom to do that. It is not,
strictly speaking, necessary to understand stacks in order to understand
an ISO C program. That knowledge may or may not be helpful, but it is not
*necessary*. In fact, it can lead to *mis*understandings, as it can cause
people to confuse implementation details with standard C, and that's not a
good thing to do.

Apparently, more or less the same people, start telling that
it is enough to read the code to be able to debug a program,
without using such low level tools like a debugger.

That's misleading. What some people have claimed is that *they* can debug
some proportion of programs (the proportion varies amongst the claimants)
without a debugger. I believe this, because I've done it myself. But
nobody here is claiming that using a debugger is somehow bad or wrong.
Everybody approaches debugging in their own way. Some people find a
debugger useful, and some do not, and some (like myself) find a debugger
useful *some* of the time - at the very least, for getting backtraces.

Having written a debugger,

So have I - albeit a very little one.

and passed countless hours of my professional
life using those tools (gdb, dbx, msvc, and many others) I am
suprised that people like Mr Bos can say in this forum
that it is sufficient to READ the code to be able to debug it.

To debug the program, it is necessary to understand it (or at least that
part of it that is not behaving). To understand it, one must be able to
read it with comprehension. A debugger can be useful in aiding that
comprehension. Nevertheless, not everyone finds it desirable to use a
debugger in order to gain that comprehension. Some people work better with
debuggers, and some work better without them. "Whatever works" is what
matters.

This was translated by Mr Bos into:

" its author is (by his own admission, in
that other thread) incapable of READING code beyond 2000 lines"

I complained that this was a LIE, i.e. a complete misrepresentation of
what I said.

This was all dealt with in that thread.

Mr Heathfield and Mr Bos answered, (in substance) that since I could not
debug a program of more than 1500-2000 lines without a debugger I am
unavle to read it, since if I would be able to read it I would spot
the bug immediately.

This was all dealt with in that thread. Note that you have mischaracterised
your opponents' position by using the word "immediately", and you have
mischaracterised *my* position by saying that I claimed you can't read
code. What I did was explain the reasoning that seemed to me to be
self-evident in Richard Bos's statement. I did not say that you can't read
code. It does seem, however, that you are unable to read (some) Usenet
articles, at least with any sensible level of comprehension.

I would be very surprised to encounter any experienced and competent C
programmer who has not debugged at least one program of greater than 2000
lines without recourse to a debugger, and yet that is what you claimed is
impossible. Presumably you mean that *you* find it impossible. You might
want to consider the possibility that not everybody experiences the same
limitations as you do in the same areas to precisely the same extent.
People are *different*, and some people have better debugging skills than
you. (Likewise, some people have better debugging skills than me.) To call
them liars just for speaking out from their experience is not a good way
to treat people.

Now, question for the people that keep a small part of common sense
here:

Is *reading* a program the *same* as *DEBUGGING* a program?

To *understand* code is to debug it. If you can't read it, you can't
understand it, so you can't debug it. Reading code is a fundamental part
of being a programmer. Now, it may be that you find it easier to read code
in a debugger than in an editor - in which case, fine! Nothing wrong with
that! But just because you do, that doesn't mean that others do.

Are serious people here willing to believe this stories of people
debugging huge code bases without a debugger?
Yes.


I stay by my position:

A code base bigger than 1500 lines is no longer debuggable in an
abstract sense just by reading code. It needs a debugger.

And I know that I /have/ debugged a code base bigger than that, without a
debugger. Therefore, I don't accept your claim, because I know from
personal experience that it isn't correct.

Note that we suppose a real-time, event-driven code execution,
where you can have faulty libraries, faulty interrupts servicing
programs, etc. ANYTHING.

You did not say so in your original claim, so you are now back-pedalling
(which is good, because it shows that you realise your original claim was
wrong). Nevertheless, yes, I've debugged real-time event-driven programs
without using a debugger. Not to show off, not to prove it's possible, but
because it was the quickest way to get the job done. I have *also*
debugged similar programs *with* a debugger. For me, a debugger is *one*
tool in my toolkit, and not one that I use a great deal.

 

[Eric Sosman]

We know from my last installments, [... aggrieved rant snipped ...]

Now, question for the people that keep a small part of common sense
here:

Is *reading* a program the *same* as *DEBUGGING* a program?

No, it is not the *same* (emphasis yours and mine alike).

Are serious people here willing to believe this stories of people
debugging huge code bases without a debugger?

Yes. Perhaps this defines me as "non-serious" in your
estimation, but my employers seem to disagree with you and
I'm not giving back forty years' worth of paychecks on your
say-so.

I stay by my position:

A code base bigger than 1500 lines is no longer debuggable in an
abstract sense just by reading code. It needs a debugger.

No, that's folly. For some programs, even for some programs
shorter than 1500 lines, a debugger can be helpful. But for
most programs, even for some many times longer, interactive
debuggers are a waste of time.

Note that we suppose a real-time, event-driven code execution,
where you can have faulty libraries, faulty interrupts servicing
programs, etc. ANYTHING.

In my experience, software debuggers are even less useful
for this class of problem than for most. (Hardware debuggers
are a different breed of cat altogether.) If you're looking
for a race condition or other timing-dependent glitch, the
"probe effect" of a breakpoint or watchpoint is too disruptive
to be of use; the timing is altered and the problem scurries
away from your gaze. Also, such problems are, by their nature,
hard to reproduce: By the time you realize the problem exists
and start prodding it with a debugger, the moving finger has
moved on.

For such nasties, I've had better success with a two-part
approach: I try to construct proofs of correctness for crucial
sections (the degree of formality of the "proof" may vary),
and I build in some kind of event trace to assist post-mortem
analysis. That is, I use a combination of "reading the code"
and "printf debugging," and I find it more effective than
trying to get a debugger to deliver something useful.

Interactive debuggers are occasionally helpful, sometimes
invaluable. But they are certainly not the only debugging
tools in the chest, nor even the sharpest.

 

[santosh]

You miss the point. Yes one CAN "debug" when reading but reading is
NOT the same as active debugging.

For a simple program mentally working through the source could be
equivalent to running it under a debugger, ignoring the possibility of
errors in code outside the program, the debugger, and the hardware.

<snip>

 

[Richard]

a lie is very different from a misinterpretatation.

Any fool can hide behind that. Bos was telling porkies. He
misinterpreted nothing. How the hell can you misinterpret someone
talking about debugging for someone reading code?

And in response you called one a liar and the other a moron, which is just
inacceptable behavoir.

Is it equally (*)unacceptable to post untruths in order to libel
someone like Jacob and his work?

reading and understanding the code will enable to debug the code.

No one said any different. But swap "enable" to "facilitate".

You need to write/modify the code to debug it, i.e. to remove the bug.

You are actually telling us that one needs to modify code to remove the
bug? Wowola - a true mind altering fact :-;

Without reading and understanding the code it won't be possible to find any
bug.

Wow! The things we learn here. Even if its not 100% true, its close
enough. I have fixed loads of bugs on big systems without understanding
the bigger picture. A debugger allows one to quickly binary chop into
the point causing the issue. Examine localised issue. Alter. Fix. Done.

Using a debugger won't debug code (so calling it debugger is a misnomer, the
only real debugger is the editor), at best it'll show where the bug
is,

What a load of mindless word games. The debugger is a utility to debug
with. You do indeed debug with a debugger. It's why its called a
debugger....

provided (once again) that you read and understand the code.

Which is easier done in context in the debugger on any sizeable code base....

A debugger may be a great help in finding the bug. On the other hand
sometimes it even hinders finding it.

When? Or will you come out with another of these one in a million
situations? Assuming the debugger supports your platform and runtime
type there is no issue generally.

Why do clc members always look for those one in a million urban myth
type examples to back up their extreme views?

Yes. The ability (or lack thereof) to do this myself isn't relevant to that
believe.

Yes it is. Because only from ones own experience can one judge the
claims made by others. And boy are there some claims in clc!

I do know from 1st hand experience that is even possible without reading the
code (well, in this case that guy didn't need to read it it, he knew it,
because he wrote it)

Of course. But not the issue at hand.

More importantly it needs a documentation, a description of the
architecture.

You are now advising on what documentation is needed?

Lacking that you can only resort to read the code to reverse engineer that
description

Huh? What does that have to do with anything discussed here? Debugging
involves reading the code in the debugger at the same time as examining
run time values.

I have modified/fixed loads of code with crappy documentation, by
..... using a debugger to trap the errors, and modifying runtime parameters
to check the extremes - impossible to do efficiently by "reading the
code" only.

These claims are, frankly, ludicrous to the extreme and I for one don't
believe half of them. If they are being serious then they are either
stuck in the past and have no idea what a modern debugger can do or are
purposely dogmatic and losing their companies a whole pile of money by
using their time totally inefficiently.

Yes, I know its not politically correct in clc to question any of the
claims made by clique regulars, but really. Some of the stances taken
here regarding "general practice" are ridiculous.

Of course there are situations where a debugger might not be
perfect. Where a quick glance at the code reveals an obvious error or
where the guy who wrote the code knows off the top of his head where the
error lies. But these are not the general conditions we are
discussing. We are discussing large, foreign code bases.

I know there will be the "are you calling X a liar, you owe him an
apology" crowd culling me now. "Lie" is too big a word - exaggerating
might be more close to the mark.

 

[Richard]

We know from my last installments, [... aggrieved rant snipped ...]

Now, question for the people that keep a small part of common sense
here:

Is *reading* a program the *same* as *DEBUGGING* a program?

No, it is not the *same* (emphasis yours and mine alike).

Are serious people here willing to believe this stories of people
debugging huge code bases without a debugger?

Yes. Perhaps this defines me as "non-serious" in your
estimation, but my employers seem to disagree with you and
I'm not giving back forty years' worth of paychecks on your
say-so.

I stay by my position:

A code base bigger than 1500 lines is no longer debuggable in an
abstract sense just by reading code. It needs a debugger.

No, that's folly. For some programs, even for some programs
shorter than 1500 lines, a debugger can be helpful. But for
most programs, even for some many times longer, interactive
debuggers are a waste of time.

You are trolling and I claim my 5 dollars.

What an absolutely mind blowingly ridiculous claim.

"For MOST programs an interactive debugger is a waste of time."

I've read some nonsense in my time but you surely top it.

The sad thing is that I think you are serious. Even worse would be if
you expect any experienced programmer other than the clc mob to believe
you.

 

[Richard]

For a simple program mentally working through the source could be
equivalent to running it under a debugger, ignoring the possibility of
errors in code outside the program, the debugger, and the hardware.

<snip>

Once again : yes. For a very small short lived program yes it is almost
the equivalent. For anything of substance it is not. The eyes miss
things in printed code that a colour coded debugger output would make
very obvious.

I'm not sure why you make this fairly obvious and trivial point.

 

[Richard Heathfield]

Eric Sosman said:

jacob navia wrote:


Yes. Perhaps this defines me as "non-serious" in your
estimation, but my employers seem to disagree with you and
I'm not giving back forty years' worth of paychecks on your
say-so.

"Mediocrity does not see higher than itself." - Sir Arthur Conan-Doyle

 

[jacob navia]

Eric Sosman said:


"Mediocrity does not see higher than itself." - Sir Arthur Conan-Doyle

Well this explains a lot of your behavior then...

 

[Ben Bacarisse]

Swimming the Atlantic is possible. I prefer to fly.

Oh for goodness sake. It is "possible" to do anything.

So why reply to me? It was Jacob that claimed something was
impossible. Why not reply to him saying "anything is possible"? I am
*not* saying that is was easy or desirable or my preferred option,
just that this is what people had to do.

Yawn. Debuggers DO exist now. I started with assembler and no
debugger. So what? We are talking C NOW.

Curiously, my second job was porting Unix (user-space utilities) to a
new micro-coded architecture. The debugger (sdb at the time) was last
on the porting list because it needed micro-code and compiler support
that could not be made available until later. We (a team of three)
had to do the port and debug the code (including a large CAD
application) without a debugger. These things happen (or at least
they did, once) and it just seems absurd to say that it is
impossible. Most of this was C code, in case there is any chance or
marginal topicality left.

Arrrghhhhhhhhhhhhh!!!!!!!!!!!!!!!!!!!

Does that mean you can't find a counter-argument? It was Jacob that
made the absolutist claim which has obvious counter-examples. All I
did was point that out.

What is it with CLC and mindless word games all the time? It's
surreal.

Did Jacob not mean "impossible"? If you think he was playing word
games by saying that when he did not mean it, then I am with you --
people should not do that. If someone claims X is impossible and
you've done X, would you just let it go lest you be accused of playing
word games?

 

[Richard Tobin]

Did Jacob not mean "impossible"?

He was exaggerating. There was some truth in what he said, but he
overstated it. There's no point basing a long argument on something
like that.

-- Richard

 

[CBFalconer]

.... snip ...

Now, question for the people that keep a small part of common
sense here:

Is *reading* a program the *same* as *DEBUGGING* a program?

Who knows. We do know, however, that it is extremely easy to drive
you into a paroxysm, where you run off and create new threads,
totally unlinked to the old thread, to carry your opinion. You may
notice that the prime effect of this is to clutter up the
newsgroup, usually with something that is off-topic to begin with,
and often carries evil insults. Your 'new thread creation'
tendency also makes it awkward for sensible readers to PLONK all
those threads.

You will notice that this, although carrying a revised title, is
still linked to your new thread (check the references line).

 

[Nick Keighley]

He was exaggerating.  There was some truth in what he said, but he
overstated it.  There's no point basing a long argument on something
like that.

he's a computer programmer posting to a technical forum.
Perhaps he should learn to be more precise.