Lambda the Ultimate

...you can examine the program at any point during its run, and even run the program backwards.

It would be nice if the debugger were fancy: at least interactive (as in, you can step along with the program, which doesn't appear to be the case with e.g.: Hat?)

In fact, Hat has a variety of interactive tools, but the style of interaction may be different from what you expect in the imperative/OO world. To "step along with" the computation, hat-anim shows you the reduction of a value of your choice. This reveals the non-strict order of evaluation.

However, viewing a trace is not simultaneous with the execution of the program - it is all post-mortem. So "along with" is in the semantic sense, not the practical one.

Pffft

I agree with the goal.

Unfortunately, in actual practice, even the most thoroughly test-driven development will sometimes require the services of an actual debugger on occasion, and on those occasions you'll want a good one—particularly if good language and methodology choices have reduced the need to arising only in extremis.

Is your company hiring? ;> Have you ever had to support someone else's code? Written 5, 10 years ago? In an "obsolete" language? ;))

As it happens I agree with Paul Snively's very reasonable opinion above, but since it's no fun if everyone agrees, and since your response is somewhat provocative I'm replying here.

I said "My biased opinion" when really I should have said "My provocative opinion". I was being intentionally provocative to challenge the idea that debuggers are necessary. Most of my programming these days is in PLT Scheme. I can't think of a time when I have really missed a debugger, including working on multi-threaded programs, and C interfaces. I have done some debugging using print statements and the REPL that a debugger might have made easier. However, when this has occurred it has always been a result of insufficient testing.

To address your questions, the answers are no, yes, yes, and no (though I'm not sure what obsolete means; if you have to program in it, it isn't obsolete surely? Alternatively, all mainstream languages are obsolete as they contain no more recent than 1980s programming language technology.)

To address the question I think you're asking, but haven't asked directly: I still maintain that the development methodology has failed if you find yourself spending a lot of time in the debugger. I don't care if the code was written 5-10 years ago by someone else. It may not be your fault, and you may have to take recourse to the debugger to fix up the mess, but the company has still failed to enforce good development practice. Having done the TDD thing (when I've been allowed) for almost the entire time I've been a professional programmer (no doubt a far shorter time than some of you grey beards) I'm amazed, and somewhat disgusted, that the vast majority of developers think code-and-fix is an acceptable development practice.

I try to use the debugger as little as possible. And I agree that in an ideal world, the time spent in the debugger should approach zero. However, the reality is that *most* programmers simply aren't interested in writing tests that they can get away with not writing, and consequently, their code contains lots of bugs that don't get discovered for many years. When someone else inherits those bugs, a debugger is about the most handy thing to have around.

Here I thought I was actually being pretty good about doing testing, but reading this thread makes me think "I suck." On the other hand, I recently had an experience in genomics where I think I had enough tests - they found the error, after all. However, the test suite could only tell me what was wrong, it could not tell me why it was wrong (new code superceded old code). So I used a debugger. I think it was more efficient than guessing at what new tests to write.

I can belive someone would say, "well, you should have written more tests as you were going along to catch this bug earlier." But I just can't believe that works in every case. Surely we can think of evil cases? And evil cases are not to be disregarded. In my case, the test would first lead one down the wrong road of thinking the new stuff was at fault. Writing ever more tests for the new stuff isn't going to help you figure out that the old stuff must be changed.

I dunno, this is all very subjective, and I would like to take to heart the point that there should be way more testing going on, but I just can't buy the mantra that with unit tests you don't need a debugger (but, I also don't buy the mantra that with unit tests you should throw out static type inference and just have dynamic typing for everything).

Please note that there is a gamut and it is all relative - I would totally repeat the comments of "if you are using a debugger then you are not doing things right to begin with" about several developers I've worked with. I'm a hypocrite!

Summary: If somebody says you never need a debugger, I think they are either not working in the kind of systems I am, or they are simply wrong. If somebody says "you should asymptotically never need a debugger because you should write better tests, but sure you might need a debugger for the weird stuff, so I would require one from my development environment, too" then I can get on board with that (but I haven't reached a sufficient plateau re: writing tests).

(I sure wish there were better tools for writing all those tests.)

Don't write tests, generate them!

ProtoQuickCheck.hs.

This is a very short demo of QuickCheck. QC generates test data to see if your conditions hold. QC finds evil cases quickly. Try it!

For more information, read the QuickCheck papers.

I've never wanted to use a debugger, though I have tried debuggers a few times just to see what everyone was talking about. I have worked on large chunks of source.

It's my opinion that test driven development and good unit test coverage means I don't need debuggers, but I don't have any good way to measure the differences.


Whenever I've had good unit test coverage, I was able to quickly track down newfound bugs. The reason for this is that I can extend existing tests to check for the newly found problem, and immediately see which part of the code contains the error. Does anyone here have experience using debuggers together with good unit test coverage? Is it worth it?



As for Haskell debuggers, dumping the state of a running program doesn't help much when the code is executing in an unknown order. Robert Ennals wrote a fork of GHC that used speculative evaluation and include an imperative-style debugger called HsDebug. You can find more info on that in the ICFP2003 proceedings.

A lot depends on why you want a debugger - they're wonderful for finding out that some driver's giving you bogus capacity info, for example, and I suspect a good debugger could make tracking down space leaks in haskell code much easier by allowing the user to see the entire program graph at once.

I do think a huge amount can be done with tests and a good interpreter, though the latter becomes less useful if much of your code is monadic.

AFAIK a main problem with debugging FP languages is that FP code usually relies heavily on tail recursion optimization which makes debugger development harder - but I never developed a debugger myself, so that might as well be nonsense.

I won't call it nonsense, but it's wrong. Tail calls don't offer any implementation difficulties for debuggers. The user-level debugging issues that tail calls create are exactly the same ones that for and while loops create -- the program state changes without changing the control context.

The real reason that FP languages don't have debuggers is mainly just that their developers and users mostly don't use them. AFAIK, Andrew Tolmach built one of the first practical time travel debuggers (ie, with unlimited history and the ability to try alternative paths) for SML/NJ, but as SML/NJ evolved it stopped working and no one really complained. It's just easier to test code interactively, using the toplevel -- and those tests can be turned directly into unit tests, too.

I respect the Ocaml team for keeping their debugger working, but I kind of wonder how many of their users actually use it. I liked having a debugger when programming in C, but have never felt the urge to use the Ocaml debugger.

Yup! Since I have this personal mantra of requiring a debugger, I have been looking into things like F# and Scala. Apparently, I have very bad karma (and very low tolerance) when it comes to installing systems: O'Caml, Mono, Haskell have all failed to install easily and nicely in some fashion or another (sometimes the core language is fine, but then the libraries I want are mismatched). Since I'm on a fringe system (linux ppc) I also had to go through some shenanigans to even just get Java (thanks to IBM I did get something in the end; there's also JamVM and SableVM, by the way).

So right now my favourite is Scala - I would have also tried some form of Lisp or Scheme or whatever, but I personally want static type inference. Also, I don't like the Python whitespace business.

Oh, I do have an actually relevant point to make instead of only whining! It is that I would like to be able to do functional-style programming (isn't that where you hold the gun sideways?) in Scala, but since everything goes through the Java debugger I end up in hell. The Java debugging system doesn't seem to let me do things like set a breakpoint (or step) to see what the return value of a function was. Unless the value gets assigned to a variable, and that variable is further used in the scope, when I step I end up outside the scope and have lost all references, so I can't see what the result was! It is things like that which make me so very sad. (OK, that was more whining.)

Purity helps a lot, you can re-run anything pure as many times as you like. And monadic discipline often helps narrow down which state-like-things are relevant at a given point if any are. Rabid control over side-effects is very much your best friend when it comes to debugging.

My experience with SML was mostly academic, but it always seemed like once I got it properly type checking then the program was correct, right out of the gate! That could have been due to being relatively 'pure' and also due to the typechecking helping work through errors in thought / design? At any rate, I always think back on that experience with fond memories.

I need to get into Haskell more seriously, and get monads into my head, it would seem.

It is commonly observed that once you get past a static polymorphic type checker, your program "just works". I reckon type-checking certainly catches about 90% of the bugs.

But there remain a number of thinko (as opposed to typo) errors which can still survive rigorous type-checking. I have probably written tens of thousands of lines of Haskell code, and pondered many a bug that manifests as wrong runtime output rather than a compile-time error.

As one of the few people who has extensive experience of using the Hat debugger, I can say that I personally find it massively reduces the time taken to find some of these "deep" bugs, by comparison with just staring at the source code. It is usually not a matter of writing test cases - I already have a failing case! The question is usually that the failing case involves some obscure corner behaviour on some data that has already been through 15 transformation phases from the original data entry to the apparent crash/output. It would be quite tedious to attempt to re-construct (by hand) the exact internal data structure values involved here, just to unit-test each module in isolation, with the aim of gradually whittling down the test case to a manageable size, and eventually (one hopes) to an understanding of the problem.

What the debugger gives me, is a context I can explore immediately, with the exact values seen in the failing program run. Exploration means I can follow numerous hypotheses, and get instant feedback on whether the hypothesis is leading me somewhere useful.

To paraphrase Eric Raymond:
"With a decent tracer, all bugs are shallow."

I think that's pretty much the kind of thing I'd been hoping to hear when I initially posted - it really jives with my own experience. (Of course that doesn't mean I don't like or learn from the other comments!)

Having said that, I think it is mostly for situations where you are entirely inside the FP language; there's still a problem when somebody wants to use FP with some other tools; how do you trace what happened when Haskell made an FFI call to your OpenGL system?

I have to admit that "a point that is swimming against the grain" somehow tickled my funny bone as I tried to visualize it. Thanks=)