Re: What is wrong with Ada?

[Markus E Leypold <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de>]

Jean-Pierre Rosen <rosen@adalog.fr> writes:

> Chad R. Meiners a �crit :
>>> Trace messages are put just to check an hypothesis, and removed
>>> immediately afterwards. Certainly not kept in configuration, and limited
>>> to a couple of lines!
>> I always keep important hypothesis (trace statements) around during
>> development because a particular trace sequence for a particular bug
>> does not ensure full coverage of the the algorithm.  I have needed the
>> same trace statement more than once at different times in some
>> software life cycles.
> Aren't you confusing traces with assertions? I certainly leave
> assertions in my programs (and they call a "failure" procedure if they
> fail, with useful information). But I remove traces as soon I know
> what I was looking for.
>
>>>> and it is much easier to trace through
>>>> the algorithm step by step (using conditional breaks when necessary).
>>> My experience is that recompiling (generally a single body where you
>>> added the trace) is much faster than starting the debugger, setting
>>> breakpoints, skipping lots of unnecessary breaks, and so on.
>> And my experience is that starting a debugger is faster than
>> inserting
>> some verbose trace statements, and then recompiling.  If you are
>> skipping a lot of unnecessary breaks, you are not using the debugger
>> properly.
> OK, take a typical example (of what I am doing, YMMV). In an ASIS
> program (AdaControl of course), I have a failure due to an
> "inappropriate element" to a given call, that I can easily identify
> from the stack trace. That place is called very often, just once in a
> while is the parameter incorrect. With a trace, I just have to read
> the last message befor the failure. But since I don't know beforehand
> how many times the sequence is called before failing, I would have to
> break on any occurrence - maybe hundreds. Not counting the fact that
> it is after I type "continue" that the program fails, and that I know
> that I just restarted from the point where I should have been
> investigating!

That is, why I talkes about "well integrated debuggers". A well
integrated debugger allows one to specify conditions on which the
breaks occur and "knows" enough about the source language to let the
user express conditions in terms of the source language. 

Regards -- Markus