[Haskell-cafe] Re: how do you debug programs?

[Jón Fairbairn]

"Neil Mitchell" <ndmitchell at gmail.com> writes:

> Hi
> 
> > But why should c and d exist at runtime? They're only used
> > once each, so the compiler is free to replace f with
> >
> > \a b -> (a+b)+ a*b
> 
> Yes, and if the compiler is this clever, it should also be free to
> replace them back at debug time.

And where does that get us? You snipped the salient bit
where I said that you'd be debugging a different programme.

If the debugger serialises stuff and refers to variables, it
reinforces an imperative view of the world and supports the
erroneous view of variables as things that exist at
runtime. AFAIK, no implementation nowadays compiles to pure
combinators, but such would still be a valid implementation
of Haskell.  You need to develop a way of thinking about
programmes that produces insights that apply to Haskell, not
to a particular implementation.

> 
> > I've said this before, but I think it's worth repeating: in
> > most cases, if you need to debug your programme it's because
> > it's too complicated for you to understand, so the correct
> > thing to do is to simplify it and try again.
> 
> That makes it impossible to ever improve - initially all programs are
> beyond you, and only by pushing the boundary do you get anywhere.

I offer myself as a counter example. I'm not the world's
best Haskel programmer (that might be Lennart?;-), but I
understand it pretty well, I think. At no point have I ever
used a debugger on a Haskell programme. So clearly not
impossible (I didn't come into existence a fully fledged
functional programmer, which is the only other possibility
admitted by your argument).

> As for me, I always write programs I can't understand, and
> that no one else can. Perhaps I understood it when I
> originally wrote it, perhaps not, but that was maybe over
> a year ago.

No comment.

> It's been my experience that debugging is a serious weakness of
> Haskell - where even the poor mans printf debugging changes the
> semantics! And everyone comes up with arguments why there is no need
> to debug a functional language - that sounds more like excuses about
> why we can't build a good lazy debugger :)

It may sound like that to you, but the arguments why
debugging is a bad thing are quite strong.  There are almost
certainly bugs in my Haskell code. Would a debugger help me
find them? Not in the least, because none of the testcases
I've used provokes them. Would it help when one is provoked?
I don't think so, because either the logic is right and
there's a slip up in the coding, which is usually easy to
find from the new testcase, or the logic is tortuous and
needs replacement.

> [Sorry for the slight rant, but I've used Visual Studio C++ so I know
> what a good debugger looks like, and how indispensable they are]

So I'm ranting back at you.  I've used debuggers on C and
other old languages (particularly when writing in assembler)
and indeed they are useful when the language provides so
many opportunities for mistakes. When writing Haskell I've
never felt the need.

Here's a story:

A long time ago, when I was an undergraduate, I encountered
a visitor to the Computing Service who often asked for help
with the idiosyncrasies of the local system. I was happy to
help, though somewhat bemused by all the muttering at his
terminal while he was programming, which involved some sort
of debugging, for sure.  After some weeks he finished his
programme and whatever kept him in Cambridge and
disappeared.  Being curious, I dug (strictly against
regulations) a listing of his programme out of the scrap
bin. It was in PL/I, and several millimetres thick. It took
me quite a while (hours, though, not weeks) to work out what
the programme did, but eventually I understood it well
enough that I could write a version in Algol68 (my favourite
language at the time).  It came to one sheet of listing
paper.  This wasn't because A68 is more expressive than PL/I
(it is, but not by that much), it was because I understood
the problem before I started to write the code.

Now, you could argue that the first programmer spent most of
his time working out what the problem was (it might even be
true, but given that it boiled down to 1 page of A68, I'm
not sure), but my point is that if you proceed by debugging
rather than rewriting, you are likely to end up with this
sort of mess. Personally, I don't mind too much if that kind
of programmer finds Haskell too hard. Elitist? Certainly!
Immorally so? No.

-- 
Jón Fairbairn                                 Jon.Fairbairn at cl.cam.ac.uk
http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html  (updated 2006-07-14)