🚀 go-pugleaf

In article <46g46d$aeg@fsuj01.rz.uni-jena.de> vkk@rz.uni-jena.de (Karl Kleine) writes:
>Robert Dewar (dewar@cs.nyu.edu) wrote:
>: Ian says:
    <<<lots of stuff deleted>>>
>The point I want to make: I went back from industry to teaching last year,
>and in my introductory programming courses (based onm Modula-2) I do NOT
>introduce a debugger. I insist on CONSTRUCTING programs, not fiddling until
>it works. The debugger is sketched and demonstrated towards the end of term
>with small groups during the practical hands-on sessions. As Robert pointed
>out above, I use the debugger to get a traceback, maybe look at a variable
>value, but then it's reading and understanding the source code again.

This is a practical way to teach an introductory programming course, as many
of the features that make a debugger useful are programming exercises unto
themselves (ie conditional watchpoints.)  There are plenty of times when
one has to walk into a system one did not construct, and for which there is
no architectural specifications to work from.  If you walk into a 30MB source
base under such circumstances, youll want an assortment of tools (debuggers,
code analyzers, etc...) and the knowledge of how to use them.  Stack traces
are nice if your error generates an exception, and printfs can give you some
insight, but neither is a robust way to analyze and debug such a system, and
too few people (particularly in management) appreciate the value of better
tools in such circumstances.

>--
>Prof. Karl Kleine			vkk@rz.uni-jena.de
>Fachhochschule Jena			kleine@fzi.de
>Postfach 100314, D-07703 Jena, Germany	+49-3641-64-3451/-3453 fax -3449

-Steve
-- 
--------------------
When all you own is a hammer, every problem is a nail.  Too
many folks grew up with nothing more than a hammer named U**X...