Re: Disobeying jet engines - why?

In message <fnq85j$7et$1@xxxxxxxx>, Jan Panteltje <pNaonStpealmtje@xxxxxxxxx> writes
On a sunny day (Wed, 30 Jan 2008 07:08:01 -0800) it happened John Larkin
<jjlarkin@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
<4f41q3hq25ra5ld18dfa5jvlcnkge8klnc@xxxxxxx>:

Sometimes the right thing to do is to buy the correct development tool
for the job. Anyone who attempts to write a database from scratch for a
PC wants their head examining (and that was true almost from the early
days of CPM). Same with anyone who attempts to debug embedded code in a
hard RT environment without using the right tools.

Umm, I should have my head examined. Twice.

John

Hey, John, I agree.
Did not want to comment at first, and that is especially about debug.
If you know your code, then you need no debugger! HIGH LEVEL LANGUAGES
LIKE HEX or ASM need no debugger (I ain't kidding).

And what if it is someone else's code (which is frequently the case on large projects) and almost always the case when contracting.

Most I will do in huge programs in C (C++ is not really a language but
a disability, Stroussup did not know how to program, and that is why he created C++),
is add some printf() statements.

What a dinosaur. You might at least use the ASSERT, VERIFY and TRACE macros so thoughtfully provided in modern implementations.

Honestly last time I used a debugger was in 1983? They tried to sell me
all sorts of stuff, ICE, hell, you should be able to understand what is
going on from what happens.

So you come back to a piece of kit that isn't working and have to binary chop to find the failing line of code each time carefully reproducing whatever situation caused it to fail. Or alternatively waiting hours or days for the failure situation to happen again by chance.

The relatively simple post mortem debug tools we had in the mid 80's would log the failing address, failure code, stack top and registers. From that and the link map you could go to the exact failing line of code and knowing how it failed usually work out why.

This method worked to allow the last remaining bugs in the shipped systems to be practically eliminated as the number deployed increased and failures became rarer and rarer. You can even get MS compilers to do this trick now.

I am inclined to agree that there is too much mindlessly watching the screen in a runtime debugger with brain in neutral these days. But that is not the fault of the debugging tools it is the fault of the users.

Regards,
--
Martin Brown

--
Posted via a free Usenet account from http://www.teranews.com

.

Relevant Pages

  • Re: SUnit disappointment
    ... I always press the 'Debug' button in the SUnitBrowser when I'm ... For example when examining a failure in the debugger rather ... I'll often be able to fix the failure in my second ... > Equals verify: object printString with: 'test' ...
    (comp.lang.smalltalk.dolphin)
  • Re: ERR:E:macallanprivatewinceosCOREOSgwewinmgrwmbase.wmbase.
    ... Your second post was better. ... There's a debug check failure and the ... debugger would like to show you the source line. ...
    (microsoft.public.windowsce.platbuilder)
  • Re: The application has requested the Runtime to terminate it in an unusual way, please contact the
    ... Joseph Anderson wrote: ... But the debugger should intercept the failure and let you see where it happens. ... If it only fails in a release build then turn on the generation of debug information in the release build and run the release build in the debugger. ...
    (microsoft.public.vc.mfc)
  • Re: Need help with m_wndStatusBar
    ... Are you able to debug on the machine this is failing? ... something else that is wrong because you are getting this failure ... elsewhere (CFile writing) as well. ...
    (microsoft.public.vc.mfc)
  • cant get jGrasp debugger to step in to function
    ... Hi, I'm calling a method in a class, that is failing to print a line, ... and I want to step into that function to debug it. ... The debugger stays in the calling function. ...
    (comp.lang.java.help)