“Breakpoints are evil: building a half-working solution, running it through breakpoints and tune it until the result matches what you expect is very close to the definitions of cargo-cult programming/programming by coincidence.”

I recently ported a sizeable C# project to F# and then to Scala. During the F# port, I continued using the VS debugger pretty much as I always had for C# — that is, as you describe above — as a coding tool.

For the Scala version, I was using different IDEs, with less familiar debuggers. The available debuggers were perfectly fine, but my unfamiliarity with their user intefaces caused me to rely more on the old-fashioned tools of paying more attention to the code, crafting-in trace points, etc.

At first it was frustrating, but then I noticed something interesting: I didn’t really miss not using a debugger as a coding tool. I re-discovered the fact that I could reason perfectly well about the correctness of the code just by using my brain and experience. Even if I needed to add things like trace points, I was adding them deliberately, as a result of first reasoning about the program, and not as a semi-random probe.

This is not to disparage debuggers, they are still a very, very useful and necessary tool when there is really is a tough bug to be squashed. But they can become a crutch when used in support of trial and error programming.

Which dovetails nicely with another observation I’ve made about F# and Scala: if you can get the IDE warnings to go away, the program nearly always runs correctly. That is, the functional programming aspects of F# and Scala simplify the reasoning about a program to such an extent that most errors are reduced to mere syntax.

In the end I used a ListBox but each row is built with a DrawingVisual instead of a databound ItemsControl. That way there are no tooltip or other nice features, but it’s really fast even with a huge number of items.