Re: Debugging Theory

ikastan@alumnae.caltech.edu (Ilias Kastanas)
22 Sep 1996 17:31:24 -0400

          From comp.compilers

Related articles
Debugging Theory rfraer@sophia.inria.fr (1996-09-15)
Re: Debugging Theory dick@silicon.csci.csusb.edu (1996-09-16)
Re: Debugging Theory jacob@jacob.remcomp.fr (1996-09-17)
Re: Debugging Theory sol!ikastan@uunet.uu.net (1996-09-19)
Re: Debugging Theory johnr@numega.com (John Robbins) (1996-09-19)
Re: Debugging Theory hans@iesd.auc.dk (Hans Huttel) (1996-09-22)
Re: Debugging Theory hans@iesd.auc.dk (Hans Huttel) (1996-09-22)
Re: Debugging Theory ikastan@alumnae.caltech.edu (1996-09-22)
Re: Debugging Theory rtf@world.std.com (1996-09-23)
Re: Debugging Theory jjc@hplb.hpl.hp.com (Jeremy Carroll) (1996-09-25)
Re: Debugging Theory agramesh@sedona.intel.com (1996-09-25)
Re: Debugging Theory mosh@karp.cs.albany.edu (1996-09-29)
| List of all articles for this month |
From: ikastan@alumnae.caltech.edu (Ilias Kastanas)
Newsgroups: comp.theory,comp.compilers
Date: 22 Sep 1996 17:31:24 -0400
Organization: Caltech Alumni Association
Distribution: inet
Expires: September 30, 1996
References: 96-09-051 96-09-076 96-09-091
Keywords: debug, theory

Ranan Fraer (rfraer@sophia.inria.fr) wrote:
@: can anyone please recommend me some good books/papers on debugging theory ?


ilias kastanas 08-14-90 <sol!ikastan@uunet.uu.net> wrote:
> Theory's edict is "you can't"; and practice advises: "don't"!
> ...
> So, no algorithm can tell whether two arbitrary TMs are "the same",
> or, given one TM, produce a "different" one; i.e., you cannot tell whether
> a program does what is wanted... and moreover you cannot change it anyway!
> (At 3 a.m. one might need some wry amusement).
>
> Fortunately in practice we don't face the full situation; still, such
> results support the familiar view: focus on avoiding debugging. We cut it
> down by careful design, good style, formal correctness methods if applica-
> ble, and so on. And an attitude of looking for more.


>[I don't think that was quite the question he asked. There has been some
>interesting work over the years in identifying and classifying bugs. -John]




John is right, there is such work; I have seen some of it, and
anyway I was not out to disparage it. I wouldn't call it 'theory',
but so what -- it is work useful to those engaged in debugging, while
the computability results above certainly aren't. (They just support
'the view').


Yes, I answered not quite the question asked... because I did intend
to say a word for the 'familiar view'. Needless to say I respect the
work on debuggers people do (and I do use it, to be sure!).


Human error, system failings etc happen, noise-like; it's the bug
amounting to a hole in design one tries to avoid. In practice,
requirements and targets often keep on changing, complicating the task
and introducing bugs on their own. No wonder exact information, which
bugs appear in which programs, is hard to come by.


I've noticed that programmers with low experience have problems with
sequential code in ways their counterparts 10 years ago did not. And
many with a fair amount of experience don't grasp event-driven
programming, mo- use clicks or messages or whatever it may be. Is it
the transition from command-line to windows, or from programming in a
language to providing snippets for app generators? Has anybody seen
something like that?


Ilias
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.