4 ms·

What a wonderful article. I'm not allowed to forget a lot of this pain. I teach programming, so I see it anew every semester. And of course I still experience

What a wonderful article. I'm not allowed to forget a lot of this pain. I teach programming, so I see it anew every semester. And of course I still experience much of it in my own work. So, yes, let's deal with these issues better. One little disagreement. In the "What?" and "Why?" sections the writer present some ideas for debuggers. While these are good ideas, I prefer to think of the inadequacies of existing debuggers as motivation for good practices: modularity, loose coupling, unit testing, etc. Certainly, it would be nice (say) to be able to examine the entire state of a running program easily. But I would rather code in such a way that I do not need to. So to those who would write the World's Greatest Debugger, I say, "Good for you." But even better would be to turn your efforts to producing languages, libraries, frameworks, and programming environments that make such a debugger superfluous.

jamii 12y ago
> I would rather program in such a way that I do not need (say) to examine the entire state of my code. But if you could examine the entire state, why wouldn't you? People build correct intuitions by comparing their mental model to reality. If you don't ever show see reality, or only peek at it through sprinkled print statements, then it becomes harder to build an accurate mental model. This applies whether we are talking about a beginner trying to understand how pointers work or an expert grappling with a complex system. Programming is always limited by our ability to comprehend complexity. So enabling simpler systems is a win, sure, but so is getting better at understanding things.
- ggchappell 12y ago
  > 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.
  - seanmcdirmid 12y ago
    > 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.
    - lomnakkus 12y ago
      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.
      - seanmcdirmid 12y ago
        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.
        lomnakkus 12y ago
        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.

jamii 12y ago

> I would rather program in such a way that I do not need (say) to examine the entire state of my code. But if you could examine the entire state, why wouldn't you? People build correct intuitions by comparing their mental model to reality. If you don't ever show see reality, or only peek at it through sprinkled print statements, then it becomes harder to build an accurate mental model. This applies whether we are talking about a beginner trying to understand how pointers work or an expert grappling with a complex system. Programming is always limited by our ability to comprehend complexity. So enabling simpler systems is a win, sure, but so is getting better at understanding things.

ggchappell 12y ago
> 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.
- seanmcdirmid 12y ago
  > 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.
  - lomnakkus 12y ago
    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.
    - seanmcdirmid 12y ago
      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.
      - lomnakkus 12y ago
        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.