Here's another story.
A few weeks ago I was working on dynamic breakpoints for GHC. At that
moment, I was trying to capture the bindings introduced by implicit
parameters in the type of a function, in order to make them available
at a breakpoint site.
Ok, disregard the stuff about me working on dynamic breakpoints. It
is completely orthogonal to what I'm trying to convey here.
So, in order to capture these bindings, I had to introduce some code
in dsBinds, the function that munches type constraints in the GHC
desugarer. Or was it...? Doh, I don't even remember accurately and it
was only a few days ago.
The problem is that this function would build on a lot of
abstractions below it, particularly on a datatype called HsBind.
There were some comments located near the datatype definition trying
to give some insight about its meaning, but they were almost
completely opaque to me. Even more, they referred to a paper, the one
about Static Semantics of Haskell, which, even if interesting, was
discouragingly long.
I was faced with the disjunctive of trying to completely understand
the whole thing, or be more pragmatic and handle only the cases
specific to my problem. A few traces showing me the structure
received at dsBinds were incredibly productive: in a few minutes I
was ready to test my solution.
The morale of the story is, imho, that sometimes the problem is not
Haskell, the language; or C, the language. The problem is complexity
and the size of the programs we are dealing with. It can easily be
the case that you are dealing with code written by another person and
you cannot afford the time necessary to completely understand its
insides.
A good debugger may be counterproductive for issues in your own code,
but it can be immensely helpful in a myriad other situations.
Cheers
pepe
On 06/09/2006, at 16:39, Jón Fairbairn wrote:
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.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
