Re: Practicalities of Ada for app development

["Randy Brukardt" <randy@rrsoftware.com>]

"Adam Beneschan" <adam@irvine.com> wrote in message 
news:afa4c8e4-dba8-460c-877b-a848255c4572@googlegroups.com...
On Thursday, June 21, 2012 10:14:45 AM UTC-7, Randy Brukardt wrote:

>>
>> I'm sure the situation is not the same for everyone, but I'm surprised 
>> that
>> you (Adam) can get much use out of a debugger, since compilers and their
>> tools is definitely one case where a debugger is pretty much worthless 
>> (the
>> only exception being the rare code generation bug).
>
>Well, since I do get a lot of use out of debuggers, the assertion in the 
>second half of
>your sentence is demonstrably false.  I don't understand it, either.  Why 
>would a
>compiler, or a compiler's tools, be of such a substantially different 
>nature than other
>programs, that would make a debugger useful in one situation and useless in 
>another?

Perhaps I'm too tied to the design of our compiler, but it is not practical 
to debug any of our compiler passes other than the first. These are all 
separate programs that take a combination of in-memory input and temporary 
files to run. The first pass could be debugged, but there are never any 
errors in that (its just parsing). The few times I've tried to use a 
debugger on the compiler (to track down hard crashes that I couldn't find 
conventionally), I spend hours creating batch files and one-off harnesses in 
order to be able to run it more than once. (And you *always* have to run it 
more than once.)

Every compiler I'm familar with uses a design like that, so it would be 
complicated and painful to debug the later passes where the errors typically 
are.

>So far, there have been at least a couple general assertions on this thread 
>about the
> uselessness of debuggers (not merely observations based on experience, 
> but assertions
> as if it were a matter of fact), but I haven't seen a good explanation why 
> this assertion
> should be true.  I'm beginning to think that either (1) everyone else's 
> situation is substantially
>different from mine, or (2) I use debuggers in ways that others aren't used 
>to using, or (3) I
> use debuggers that have features that aren't present in debuggers that 
> others are used to
> using.

The latter might be the most likely, at least in my case. I've never had any 
luck with any "advanced" features in debuggers; I barely can get the basic 
ones to work. (Our own debugger is an exception, but it doesn't have any 
"advanced" features, so it doesn't change anything.) I've never gotten 
anything to work in any of the modern Microsoft debuggers, for instance; I 
can't even get them to display a memory location. (I use the debugger from 
Windows NT when I have to do that, because at least I can get basic commands 
to work in it.)

> Maybe we could start by having those who don't think debuggers are useful 
> for Ada answer
> this: what do you think a debugger would be used for, when it *is* useful? 
> If your answer to
> this is a lot smaller then the set of things I think it can be used for, 
> that may help explain why
> there's such a difference of opinion.

The only thing I've ever found a debugger useful for is single-stepping 
and/or executing to breakpoints. You have to do that multiple times before 
you hit on the magic incantation that gets you to that part of the program 
that you need to look at. And you can waste so much time attempting to do 
that that most of the time it is much easier to read the trace log from 
directly above the problem (since it is already built-in to the 
application). Plus adding a few traces, recompiling, rerunning, and looking 
at the results will find the bug before I could have even figured out 
exactly where the breakpoint needs to be.

The only time the debugger hassle is worth it is when the bug is 
sufficiently low-level that you can't debug it at the Ada level (as when a 
register has the wrong value for some reason, causing a hardware fault). And 
that usually takes me many hours (usually an entire working day) for a 
single problem, as opposed to dealing with a problem an hour or so at the 
Ada level.

                                Randy.