1. Email Reply from Prof. Wirth
Sent: Tuesday, August 21, 2007 at 06:49:43 PM GMT+2
Subject: Re: Debugger Help
Dear Mr. Sun,
With your letter you raise an old argument. I doubt that I ever said
"A good programmer should not use Debugger",
but rather "A good programmer doesn't need a Debugger".
This was a bit sarcastic, and it was said in the context of teaching and solving exercises.
What I really meant was that one should strive for careful programming,
where every step is done with the certainty that it is correct,
such that at the end the whole program is correct and no search for errors (debugging) is needed.
This is quite possible and is the right way to train programmers.
However, when programs become complex, we fail to be sufficiently careful.
We make errors and must find them. Also this we must learn. But only as a "last resort".
In general, debuggers have become so sophisticated, that programmers cannot live without them.
They make debugging so common-place, that nobody even tries to design a program to
be correct from the start. This is why I exaggerated by saying to the students:
Do try to do without the help of debuggers, at least while solving my simple assignments.
In fact, I believe that the sophisticated tools, along with the very fast processors,
are largely responsible for the wide-spread replacement
of careful design by trial and error techniques. The latter is believed
to be easier and faster. And sophisticated tools are cheaper than
excellent designers. However, they cannot replace them!
To be fair, we must acknowledge another point. Very few programs are
designed from scratch and are thus in the head of an originator.
Mostly, programs grow, and programmers extend existing ones. Unfortunately, they
are often poorly documented, sometimes even wrongly documented.
Then, our work is no longer like "program design". It is rather detecting the
reasoning behind an undocumented text.Then our only resort is inspection and testing.
Then we must use every tool available to conquer the misery.
But as always, the sledgehammer must be used only when finer tools fail.
> 3. An alternative approach not to use Debugger is to insert Printout statements
> into the programs, and eventually build flags into programs to toggle and regulate
> the output finesse. How do you think of this practice?
I often do this, but remove the "debug outputs" when the problem is found.
> 4. I read again your 1984 Turning Award Lecture, and found only one place mentioning
> Debugger: "His efforts (Ken Bowles) to develop a suitable Environment with integrated
> compiler, filer, editor, and debugger caused a breakthrough:..." This sounds that
> the Debugger was appreciated.
Yes it was a big part of the success for the UCSD Pascal System.
Quick turn-around -> quick fixes.
> Also in your talk with Dr. Carlo Pescio (Published in Software Development, Vol. 5 No. 6, June 1997)
> about the 20% / 80% partition of design / debugging time, it seems that
> Debugger was not excluded from daily programming.
I never claimed that the world programs without the support of debuggers.
> In Oberon, I also heard that both a post-mortem Debugger and a runtime debugging facilities
> (BlackBox Component Builder) were implemented.
Blackbox was designed by a company in Zurich, and they were quite successful with their tools.
I hope this clarifies my points of view about programming with or without debuggers.
Sincerely yours,
Niklaus Wirth
2. Email to Prof. Wirth
Sent: Monday, July 30, 2007 at 11:24:11 AM GMT+2
Subject: Debugger Help
Dear Professor Wirth,
My name is Kun Sun, working in a software company with more than 100 developers,
of which many are ETH computer graduates. Recently we have some discussion
on the subject of "Debugger". Some of ETH graduates claim that they do not need
Debugger since Prof. Wirth taught them: "A good programmer should not use Debugger".
I have been involved in the computer field around 25 years, starting from binary programming
to nowadays-symbolic programming, always childishly seeking for the reason.
To this purpose, I would like to have your help on the following points:
1. Why a good programmer should not use Debugger? In which context does it hold?
2. A Debugger (or better called Inspector or Watcher) can reveal the runtime
behaviour of system. In the case of basic (scalar) variables, maybe the
usefulness is not tremendous, but for the composite type, like record, array,
object, XML type, it would be helpful to recognize the inherent state
and detect the side-effect of some code. On the other hand, for the program structure
like: iterative and recursive (specially non tail-recursive), Inspector can aid
in understanding of program logic. Further more, to handle with dynamic code
(program with reflection, indirection, and even string-append generated code),
a Debugger appears to be beneficial.
3. An alternative approach not to use Debugger is to insert Printout statements
into the programs, and eventually build flags into programs to toggle and regulate
the output finesse. How do you think of this practice?
4. I read again your 1984 Turning Award Lecture, and found only one place mentioning
Debugger: "His efforts (Ken Bowles) to develop a suitable Environment with integrated
compiler, filer, editor, and debugger caused a breakthrough:..." This sounds that
the Debugger was appreciated.
Also in your talk with Dr. Carlo Pescio (Published in Software Development, Vol. 5 No. 6, June 1997)
about the 20% / 80% partition of design / debugging time, it seems that
Debugger was not excluded from daily programming.
In Oberon, I also heard that both a post-mortem Debugger and a runtime debugging facilities
(BlackBox Component Builder) were implemented.
Best regards,
Kun Sun
