> But if you could examine the entire state, why wouldn't you?
Well, I would, of course. As I said, I think his debugger ideas are good ones.
OTOH, there is a limited amount of effort available for improving programming, and I would prefer that such effort be directed toward other ends.
Part of the problem is that, in my experience, debuggers tend to encourage sloppy thinking. And the better the debugger is, the sloppier is the result. Using a debugger, together with thinking hard about a problem, can be a powerful combination. But all too often, I see debuggers used as substitutes for thinking hard; the way debuggers are designed seems to encourage this.
To put it in the terms you used, constructing a mental model and comparing it with what the debugger shows, is a great idea. But in practice, I'm faced with a choice: work on my mental model now or fire up the debugger now. The latter is less taxing, and is often chosen; this is likely harmful in the long run.
> But all too often, I see debuggers used as substitutes for thinking hard; the way debuggers are designed seems to encourage this.
I wish there was a device that would help me think less hard...oh wait, there is! Its called a computer!
The lack of a decent debugging experience in languages like Haskell mandates deep thinking upfront along with powerful bondage-style type systems. I can imagine that a language with a more advanced debugger would push things the other way.
Maybe the "lack of a decent debugging experience" for Haskell is a consequence of there not being much need for one[1]? Have you actually used Haskell for any project of a meaningful-enough size to form an opinon? You sling out these accusations and hyperbole, but you don't seem to back it up with any practical examples.
[1] I couldn't entirely parse your sentence as posted, so please forgive me if I misunderstood it.
This is by design of Haskell, and you aren't arguing with me (beyond being offended by my hyperbole). My trouble with using Haskell on small projects means I would probably never go near it on large projects, it prefers people who "think to program" while I'm more of a "program to think" type.
What were your problems using it on small projects? If it wasn't obvious, "large projects" is a proxy for "have you actually tried to use it at any practical level?". FWIW, I had a lot of difficulty with Haskell at the start, but "easy to learn" doesn't necessarily translate into "a lot of power", but I found that Haskell gave me incredible power at the cost of a steep learning curve. It's not for nothing that they call it the best imperative programming language.
Oh, and don't worry, I would never pull the I'm offended by X card! I don't get offended easily, and I don't think you do either ;). This is all friendly argumentativeness (is that a word?) as far as I'm concerned, I hope you feel the same.
I worked on lots of small haskell projects as a student, wrote ocaml at Jane St and spent the past few years working in clojure full time. I definitely felt the need for a debugger in every one of those languages.
Equational reasoning is useful but it is still reasoning that I have to do. The whole point of having a computer is for it to do some of the thinking for me.
I think there is a certain kind of person naturally attracted to Haskell. I once attended an working group meeting [1] with many of the top Haskell people (e.g. SPJ), and I came to the realization that they were super smart and their brains were just wired very differently from mine. But I also thought a lot of effort was spent on solving problems elegantly in Haskell that were otherwise very easy to solve in other programming environments.
It is not the learning curve that gets me; I know many languages already, some of them with very steep curves. It is the thought processes that the language promotes, the order that it forces me to write my programs, the flow doesn't suit me well. I want the freedom to work at my own rhythm.
For the rest of you, when somebody describes Haskell in this manner you can be assured of a few things.
One, they don't know Haskell better than extremely superficially. Two, they don't understand parametricity and haven't read the papers. Three, they don't know what it's like to do the same kind of work (day-to-day programming) in a dependent type system.
I personally call Haskell's type system "paranoid". Yet I have no difficulty asserting that it's way more flexible than C++'s or even Ocaml's (which makes you route around the value restriction, and the lack of type classes).
I love paranoid type systems: they debug my thinking up front.
Well, I would, of course. As I said, I think his debugger ideas are good ones.
OTOH, there is a limited amount of effort available for improving programming, and I would prefer that such effort be directed toward other ends.
Part of the problem is that, in my experience, debuggers tend to encourage sloppy thinking. And the better the debugger is, the sloppier is the result. Using a debugger, together with thinking hard about a problem, can be a powerful combination. But all too often, I see debuggers used as substitutes for thinking hard; the way debuggers are designed seems to encourage this.
To put it in the terms you used, constructing a mental model and comparing it with what the debugger shows, is a great idea. But in practice, I'm faced with a choice: work on my mental model now or fire up the debugger now. The latter is less taxing, and is often chosen; this is likely harmful in the long run.