What is Expressiveness in a Computer Language

[Joe Marshall]

David Hopwood wrote:
> > Joe Marshall wrote:
> >>
> >>I do this quite often.  Sometimes I'll develop `in the debugger'.  I'll
> >>change some piece of code and run the program until it traps.  Then,
> >>without exiting the debugger, I'll fix the immediate problem and
> >>restart the program at the point it trapped.  This technique takes a
> >>bit of practice, but if you are working on something that's complex and
> >>has a lot of state, it saves a lot of time because you don't have to
> >>reconstruct the state every time you make a change.
>
> The problem with this is that from that point on, what you're running
> is neither the old nor the new program, since its state may have been
> influenced by the bug before you corrected it.

Yes.  The hope is that it is closer to the new program than to the old.

> I find it far simpler to just restart the program after correcting
> anything. If this is too difficult, I change the design to make it
> less difficult.

In the most recent case where I was doing this, I was debugging
transaction rollback that involved multiple database extents.  It was
somewhat painful to set up a clean database to the point where I wanted
to try the rollback, and I wanted a pristine database for each trial so
I could examine the raw bits left by a rollback.  It was pretty easy to
deal with simple errors in the debugger, so I chose to do that instead.





>
> > Wow, interesting.
> >
> > (I say the following only to point out differing strategies of
> > development, not to say one or the other is right or bad or
> > whatever.)
> >
> > I occasionally find myself doing the above, and when I do,
> > I take it as a sign that I've screwed up. I find that process
> > excruciating, and I do everything I can to avoid it. Over the
> > years, I've gotten more and more adept at trying to turn
> > as many bugs as possible into type errors, so I don't have
> > to run the debugger.
> >
> > Now, there might be an argument to be made that if I had
> > been using a dynamic language, the process wouldn't be
> > so bad, and I woudn't dislike it so much. But mabe:
> >
> > As a strawman: suppose there are two broad categories
> > of mental strategies for thinking about bugs, and people
> > fall naturally into one way or the other, the way there
> > are morning people and night people. One group is
> > drawn to the static analysis, one group hates it.
> > One group hates working in the debugger, one group
> > is able to use that tool very effectively and elegantly.
> >
> > Anyway, it's a thought.
>
> I don't buy this -- or at least, I am not in either group.
>
> A good debugger is invaluable regardless of your attitude to type
> systems. Recently I was debugging two programs written to do similar
> things in the same statically typed language (C), but where a debugger
> could not be used for one of the programs. It took maybe 5 times
> longer to find and fix each bug without the debugger, and I found it
> a much more frustrating experience.
> 
> -- 
> David Hopwood <david.nospam.hopwood at blueyonder.co.uk>