"Neil Mitchell"
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@cl.cam.ac.uk http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html (updated 2006-07-14)