Lambda the Ultimate

Joking aside, I think debuggers are only useful in very specific circumstances, and prefer other techniques for general day to day programming. However, lazy-pure languages make other techniques (e.g, debug prints) problematic as well.

I too avoid using debuggers, prefering to reason about what I wrote. But a good debugger seems important to many people, and is often a pragmatic criterion in language selection.

What I thought was: what kind of tools or techniques could give enough information about the execution of programs as to make debuggers really unnecessary ?

Also, I may be wrong, but I think debuggers aren't studied very much. Is it because it's a solved problem in strict languages ? Or is it because it's not seen as a worthy research topic ?

I think that the reason. It seems like a practical/technincal problem, not something that requires deep research. Obviously, that's not the whole story, and some reasearch is being done. Just not enough.

when I was a Java programmer. Usually I would isolate the bug with a test case, narrow it down with some tests and correct it. Also I used contracts everywhere I could.

I would say that these techniques could make debug virtually unnecessary, but without a correct stack-trace (another thing Fergus complains about) it would be much harder to get around without a debugger.

1. All my ruby code is Test Driven Development, so it is easier to add a test, than use the debugger.
2. The TDD code has far fewer bugs.
3. The compile/link/run cycle time in ruby is zero, therefore it is easier to add a tracing print statements.
4. gdb will print all the instance variables of an object, but c/c++ won't. Ruby has 'pp' which prints recursively dumps an object and its subobjects.
5. Backtraces from C/C++ are only available from within the debugger, wherease I often use this idiom in ruby...

     raise "Whinge" unless assertion
   

   which gives a stacktrace when fired.
6. gdb is an additional language tacked on the side of C/C++. Whereas ruby is very capable of introspection and reflaction. Therefore instead of having a braindead mini-language to use for debugging, you have a "best of breed" scripting language to script your debugging in.

   ie. There is a hard division between the debugging language and the programming language in C/C++/gdb world. In the ruby world ruby _is_ the language of my debugger.

is debugging really necessary or just a way to cope with our inability to reason (by ourselves or with tools) about programs ?

I think there is a lot of truth to that statement. I try to write my programs so that if I am examining about a page of the source code at once, there is enough information contained therein for me to understand what is going on. However, that's not always possible and eventually you get lost.

In general, I don't have problems reasoning about control flow, but rather it's data transformation and/or updating that it's easy to lose track of. I often ask myself "What is the value of variable x at this point?", etc. When that gets too much for me to keep track of and something goes wrong, I may feel the need to start up a debugger.

I am big on contract, as I guess everyone knows. But I have to disagree on this one. Sure, contracts help you assign balme. But then you have a module that breaks and you want to know why. More specifically, you want to know which statement in the code is responsible: where's the bug. And for this people use debuggers, and this is exactly what contracts don't give you.

Obviously, this does not mean contract aren't important, or that I like debuggers...

More specifically, you want to know which statement in the code is responsible...

Well, depending on the granularity of the contract system, you can get close. In Robby Findler's calculus you can associate contracts with individual definitions, so that you can trace blame back to specific functions.

But I think you're right: Robby has indicated in emails that he thinks definition-level contracts are a bad idea and they might remove them from PLT Scheme. I think his and Matthias Felleisen's view is that contracts are more useful for inter-module relationships (e.g., to coordinate efforts between multiple programmers), and that if you want intra-module guarantees you should use something else, like types.

I get the impression that a big practical impediment to intra-module contracts is that they break proper tail-recursion. Steering back towards the topic at hand, this is a problem with stack traces as well, as someone in the thread pointed out. What do people think about the relationship between proper tail recursion and debugging?

It seems certain enforcements imposed by a language for the sake of safety or reasoning can impede the kinds of experimentations we might want to do in development and debugging. Are there useful and perhaps general ways to characterize a distinction between development and production versions of programs? I can think of a number of features you'd like to ease development that you would not want enabled in production, e.g.:

• disabling TCO for full stack traces
• various program instrumentation
• test scaffolding
• adding side-effects to pure code (e.g., lifting pure Haskell functions in the IO monad)

Maybe these are all in the category of "dirty hacks" (which is not Cartesian-closed, I hear). But I can imagine a distinction being useful for AOP.

That's essentially my view as well. There are some exceptions (e.g., inheritance hierarchies are problematic whether inter- or intra- module) but a contract is (a part of) an interface.

This would be perfect for our internal language.

Thank you for the link Daniel.

I think the difficulty was lazy evaluation, not type errors, right? I'd be tempted to agree that laziness hasn't worked out as well in practice as might have been hoped.

Right, I think that's the core problem.

I'd be tempted to agree that laziness hasn't worked out as well in practice as might have been hoped.

Simon Peyton Jones addressed this in his
Haskell restrospective, concluding that although laziness has some attractive properties, it also has problems, and that overall, laziness doesn't "really matter". He says "purity is more important than, and quite independent of, laziness".

Lazy evaluation is making debugging hard, but he's trying to debug a type error, right? (Taking the head of the empty list.)

How is that a "type error" though? Did you mean that you thought it was funny that the type system didn't save him from making such a simple runtime error as taking the head of an empty list? That's an interesting point. I think this may be one of those "human factors" things again - it's so convenient to use lists in Haskell, that one often uses a list where one really should be using a different data type that can't be "empty".

...as Bryn says. Otherwise there would be no need for a debugger; Haskell catches type errors statically. Though I can conceive of a static debugger for static type system, for example:

D. Duggan and Frederick Bent.  Explaining type inference.  Science of Computer Programming, 27,1, June 1996.

Like Bryn said, this error arises precisely because Fergus bypassed the type system. Personally, I never use head, and I'm very careful about non-exhaustive patterns. Often when you have the latter, it means you're using the wrong datatype.

The compiler does detect non-exhaustive patterns; in fact, it emits a warning when it finds one.

You don't need a more expressive type system to catch errors like that with head; all you need is a programmer who is willing to use the tools the language offers him.

As we always can write:


head (x:_) = x
head [] = error "head []"


Where error is polymorphic, so it type-checks and the problem still exists. In the general case the type-system can't forbid an error-like polymorphic expression.

Saying that I agree that incomplete patterns are a source of errors and I don't like the error function as it leads to sloppy error handling in the program.