Lambda the Ultimate

Lazy functional languages are notoriously difficult to debug. We had numerous threads on the issues involved and the tools invented to overcome them. Truthfully, I don't I head of a good solution...

(Mind you, I am religious in my disdain for debuggers in general, so I am not the best person to comment on these issues).

I should start by saying that I tend to avoid debuggers for languages other than C/C++. And then I only use them to map seg-faults onto line numbers. For debugging in any language I've always use the "add layers of prints" approach to find the problem. The simple reason for this that I find the interface of writing chunks of code to filter the stream of events that a program creates to be easier than any utility that I've tried to do the same thing.

When you debug-by-printf your first problem disappears. Although you don't know the index within a collection you can display what the item is rather than fighting with references.

Debugging declarative languages tends to be very different. One of the nicest things (and some would say worst) things about Prolog is that you can abuse the procedural semantics to cause side-effects at any point in the execution. In this setting I tend to use the same set of tricks as debugging within an imperative language.

When working in a strongly typed language, such as Haskell, it is not possible to litter the code with IO effects without major rewriting of the functions involved. The main technique in that situation tends to be lifting the function out and testing it in a different context. IE writing a wrapper for the function that allows IO to occur.

In general the only viable approach that I've found for debugging in Haskell is to keep functions small enough that you can debug them in your head. When you hit problems with higher-order code like filtering / mapping it seems to be easiest to split the function into smaller steps and convert your HO operations to map onto Strings that can be output to check each intermediate step.

One general characteristic that I've come across is that weakly typed languages make it easer to debug code, but harder to ensure correctness. Strongly typed languages make it easier to enforce correctness, but more difficult to verify it when something goes wrong. I'm not aware of a functional language that solves this problem; one way would be to have debug statements that act as side-effects on a stream of events. Basically emit statements that are invisible during normal execution of the program, but can be swiched on to examine how execution proceeded.

...to see other comments before chiming in.

First, I tend to agree with your conjecture that debugging is different from designing (in my vocabulary, both are part of the higher activity of developing, but one hopes the latter is a much larger part ;-) Working to conceive an appropriate set of concepts and express them effectively seems to be a different "mental mode" than the detective work of determining why an expression doesn't capture the intended concept. However...

I honestly can't remember the last time I used a debugger. (I admit that it was a normal part of my toolkit in the days when I was writing device drivers for MS-DOS.) And the for-each-in construct has been around for so long (decades at least) that I was just annoyed that Java waited so long to have it.

But since reading your post, I've been pondering the original issue you raised--the interplay between language features and defect diagnosis. I believe that an emphasis on design-for-testability in general (and the use of unit testing specifically) plays a role in the answer. I believe that features of the language that support the creation of "units" of code that can be reasoned about and tested in isolation contribute throughout the development cycle (design, construction, and defect diagnosis/elimination). For example, in Java, it's OO and the ease of developing against interfaces instead of concrete classes. (Of course, quite a few of the patterns common in OO are subsumed by higher-order functions in FP.)

Thinking about my own recent experience, it seems that most defects relating to iterating over a collection have to do with one of the following design errors:

1. Putting an object in the collection that shouldn't have been there to begin with (based on the intended meaning of the collection).
2. Conversely, failing to have included an object that should have been present.
3. Misusing the object obtained from the collection.
4. Failure to maintain state appropriately between successive members of the collection (e.g. incorrectly modifying an accumulating value).
5. Making an incorrect assumption/dependency about the ordering of the collection.

For my education, can you give me a use case for needing to know the index when reasoning about a defect?

I think the best way to see how many items are treated before the bug happens is to have a counter which tells you how many items of the collection were treated. The nice thing is that it can be extended to the parallel case (computations executed on items in parallel).

If you tell the compiler that you want a debug executable it should be easy to add that automatically, however in Java I do not think there is any notion of "debug executable". I have no idea what the bytecode output for a enhanced-for loop looks like and whether it is amenable to that extension.

I've heard that before from some number of people. It has always completely flabbergasted me; I regularly need to use both printf and interactive source debugger style debugging to figure out what the heck is going on / wrong. :-)

It would be interesting (cf. the recent request out of MSR to research people doing FP development, presumably including debugging? or the stuff Brad Myers has done) if there were some long-term on-going research into how people debug, what causes them to. I suspect there are many factors involved in deciding how to approach debugging:

(a) what you are familiar with in terms of tools. i often see Java folks who are apparently afraid / unwilling to use the debugger i think simply because they've never tried it. the thing about using a Java debugger vs. printf is that you can answer more new questions w/out having to restart the system.

(b) what your code base is like. if it doesn't suck a lot then maybe just reasoning about it will work. but if you have stateful gnarly yukky spaghetti code (even in Java, shock!) then it can be harder vs. just doing empirical study.

(c) what language you are using.

(d) what your system is doing; is it batch, or interactive? is it floods of data, or always just waiting for the user to do something? etc.

(e) how you learn as an individual. if i'm trying to fix a bug, i tend to like to be able to see / browse as much data around where i think the bug is as possible, to get a feel for things. i like to have access to any and all data so i can try to get my bearings both in terms of what code is executing, and e.g. where in the input data the 'cursor' is. this can include stupid stuff that should really be assumed to be working like oh does the iterator really work, or whatever vs. leaving all the inner state of the abstractions hidden. (that really drives me nuts in the case that happens a lot with Java of some kind of reflection or aop or lazyness or whatever e.g. with mocking for unit tests, or with xml parsing libraries, etc.)

(f) yadda yadda yadda.

is supposed to allow fine-grained debugging of LINQ queries, including using LINQ in the visualizer.

I came across this talk a while back and found it interesting - Debugging backwards in time by Bill Lewis - a tech talk at Google.

I always write a a log file and then just do this :-
tail -f /log/file/name

and that works for just about any web language on the planet!