Unless, of course, you have: 1) A large program operating on a large body of data that takes a long time to

debugs logs go to a file, grep and awk let you quickly find things

3) A complex library written by someone else which contains a bug or makes

before calling out print a funtion trace like: function "f" called from "reified location" with arguments ... returned "value"

4) this is what assert statements are for as in:

assert (x>0) function-which-assumes x>0 For large project development - the development cycle should go along these lines... 1) functional specification 2) modularise 3) design interfaces for components 4) build testbench for components 5) code components... I have missed out the iterations for simplicity. Note the testbench should be built before the module - this includes analysis for linear regions and corner cases... The testbench will log each test along with the results. Testbenches should be provided with third party components - if they are not they should be built as part of the development process. I find if you do the above and put adequate debug logging in your code the need for a separate debugger is minimal... To get slightly more technical all the debugger does is run the code with full internal visibility (all states visible) - by adding debug statements you can increase visibility to the same level. logging all these debug outputs to a file gives you the same observability as single stepping, but it is much quicker to run the program at full speed and search the file. Prining out the full program state (or scoped variables) at any point is equivalent to a breakpoint. Consider this as a suggestion of how to cope without a debugger - until you find one you like... Keean.