I'm now back from Hac 07, and I was sharing a room with Pepe, the GHCi Debugger Summer Of Code guy. I got to hear his presentation on the debugger he has completed, and got to see it "in action". He made some interesting comments - that Hat provides a much richer framework, and that when he originally tried to get Hat working he even went as far as replacing his OS (!) to try and get Hat working - but with no luck. He demonstrated his debugger, and the next day, in front of about 10 people I demonstrated Hat.
GHCi Debugger Demonstration
The GHCi debugger is much newer, and not officially released yet. Pepe started off with the demonstration, giving a few examples, but at various points I asked "what if?" questions, all of which he went and did. The debugger worked flawlessly, and produced useful information. It didn't produce as much information as Hat (particularly stack traces were missing), but it was solid and reliable. I only had one major gripe with it - that :quit was used for continuing from a breakpoint - but the next day a patch went in fixing that.
Hat Debugger Demonstration
In return, I tried to go through a pre-scripted demonstration of Hat. However, since the first scripting I had installed GHC 6.6 on the machine, so the compilation took about 100 times longer than I remember - no idea why. When I finally had a Hat file I was able to view it in Visual Hat. I then tweaked the file as people asked various questions - unfortunately that didn't work so well. Various things went wrong. I added a head call, to invoke a pattern match failure. Indeed, it did invoke a pattern match failure, in Hat itself! I tried some other stuff, files kept appearing in the wrong places. Stack traces were coming out not quite as you'd expect them. Everything went wrong.
Some of these issues may well be in the hat-make that I wrote recently and hackily, but others were more fundamental issues in Hat itself.
Conclusion
While Hat is without a doubt more powerful, it looses on reliability. Despite porting Hat to windows, and using Hugs fulltime, GHCi will be my debugger of choice. I don't use Hat because when I've got a bug to fix, I know getting through Hat will take at least an hour, and won't always be possible (Data.Map for example). The GHCi debugger is maybe 10% of Hat in terms of power, but 100% reliability looks like it will make up for this.
Thanks for the optimistic sum up Neil!
ReplyDeleteSince I am null at blogging, it's great to see the GHCi debugger showing up in the blogo-thing.
Yes, back in those days, I was quite desperate for a debugger to help this newbie-me, and Hat was looking sweet. Shamefully I never managed to install it, despite all my OS woes and efforts.
About the GHCi debugger I wouldn't say 100% reliability yet, but we are aiming at it. Another good feature is that "it just works" quality, simply launch ghci with the -fdebugging flag and start setting breakpoints.
Hat has/had the potential of being a much more powerful, feature-complete debugger, but with time and other people contributions, maybe the ghci.debugger will get closer!
It was an enormous pleasure to meet you Neil! Long live the Haskell Hackathon.
Hi Neil - I'm particularly glad to hear your conclusion from this little adventure, because that's exactly what I'd hoped would happen with the GHCi debugger: focus on accessibility, the users will come, and we can add features later.
ReplyDeleteSimon M.
oh! that is interesting:
ReplyDelete"The GHCi debugger is maybe 10% of Hat in terms of power, but 100% reliability looks like it will make up for this."