5 ms·

I don't code with a debugger, and I know a ton of people who don't either. I think people like me just rely on a REPL, which is enough. I find most debuggers to

I don't code with a debugger, and I know a ton of people who don't either. I think people like me just rely on a REPL, which is enough. I find most debuggers to be intrusive and flow-breaking. I do agree that a lack of both, however, is crazy to think about. Yet I hired a developer not long ago who did basically that while shopping JCL Cobol for a student loans company.

thom 7y ago
You’ve never written a debug print statement?
- icelancer 7y ago
  printf-style debugging counts as an interactive debugger? Then I guess... yes. I just took that phrase as being an actual full-fledged debugger, not irresponsible printing to console (which is what I do).
  - thom 7y ago
    No, I’m saying that in those cases you _should_ be using a debugger, because it’s just so much easier and more powerful. My point being, why do so many people have a day to day workflow inferior to what was available for free decades ago to kids making gorillas throw bananas at each other?
    - icelancer 7y ago
      Oh, I probably should be, yes. But I won't, because I don't like them and never really have. I realize this is probably less productive, but at least I'm self-aware about it. And I don't think it's heresy to say that many people just don't like the current crop of debuggers out there, especially when you write in dynamic (and weakly typed) languages. Which is another bunch of bananas, but sometimes we don't get to pick what code we write in, especially in my industry.
      - thom 7y ago
        Oh I totally agree about the causes, I’m more bemoaning the tooling. I too work in languages sometimes where it’s really hard, which is why I chuckle at what 10-year-old me would think about all the complexity.
    - thom 7y ago
      And this is before even considering how much better Smalltalk and Lisp environments where years before _that_.
    - pjc50 7y ago
      A debugger is helpful if you don't know which value you want and want to go exploring. Print statements are helpful if you want the value at thousands of different points in time - you don't know when you want the value - and want to fish it out later.
      - thom 7y ago
        In that situation you’d generally use conditional breakpoints. If you’re just scrubbing up and down in thousands of lines of output looking for something fishy, that doesn’t seem very productive. I’m also on board with generative testing to find these sorts of edge cases, if relevant.
        pjc50 7y ago
        It's the "how did I get here?" question: you have a clear logfile marker for "something went wrong", such as a stack trace, and then scroll back upwards to determine what went wrong. Can even be a negative, which is incredibly hard to do with breakpoints: "I should be seeing line X after Y or before Z, but it's not there" Can also be a ward against the insecurity of unknown unknowns - where there's a lot of moving parts and the problem isn't well isolated (we'd all like it to be, but maybe previous developers didn't design the system like that) or the OS or one of your libraries is betraying you.
        thom 7y ago
        Sure, I’m not really saying every problem in software can be solved with a debugger. But not being able to easily narrow down which part of a system is breaking an invariant shouldn’t be an everyday occurrence. Obviously shit happens (or happened in the past) and you’ve sometimes gotta do what you gotta do though.
        pjc50 7y ago
        > But not being able to easily narrow down which part of a system is breaking an invariant shouldn’t be an everyday occurrence I think there's a kind of reverse Amdahl's law at work here. Situations where there is a nice clean crash into the debugger that tells you what's going on are easy - so they don't take up much time. Situations where that doesn't work take much longer - maybe the problem doesn't replicate when you're using the debugger. And there have been situations where simply doing the data-gathering to establish that a bug was real consumes weeks. My own personal one of those was missed touchscreen events; because they were so infrequent we eventually had to set up a robot to press the screen 10,000 times, resulting in 9,999 touch events, and record a huge amount of data up and down the stack in order to work out what had happened.
JustSomeNobody 7y ago
I don’t code with a debugger either. If I need to use a debugger to figure out the logic I just wrote then I have failed to make it clean enough to understand.
- klez 7y ago
  Well, shit happens, and you may need to receive inputs that are out of your control, or use libraries that are less then perfect and you need to use intermediate results. In those cases a debugger (or even just strategic prints) can be a godsend.
  - JustSomeNobody 7y ago
    I can use other tools. A good logging framework or wireshark, etc to capture and view data. I won’t use a third party library that is shit.
    - klez 7y ago
      What if you inherited someone else's code? Are you going to change all the libraries because you don't like them? Or even if they use good libraries, how are you going to unravel complex pieces of code? What I'm trying to say is, sometimes you need all the help you can get. And even an awful debugger is better than doing it in your head.
      - JustSomeNobody 7y ago
        I fix other devs code with a debugger. I don’t “code with a debugger” myself. I think it is wrong and lazy to do so. For third party libs I work with the vendor to unshit their shit. Or I switch, yes. I write code that has to run out in BFE for 5-10 years. I can’t be sloppy about it.

thom 7y ago

You’ve never written a debug print statement?

icelancer 7y ago
printf-style debugging counts as an interactive debugger? Then I guess... yes. I just took that phrase as being an actual full-fledged debugger, not irresponsible printing to console (which is what I do).
- thom 7y ago
  No, I’m saying that in those cases you _should_ be using a debugger, because it’s just so much easier and more powerful. My point being, why do so many people have a day to day workflow inferior to what was available for free decades ago to kids making gorillas throw bananas at each other?
  - icelancer 7y ago
    Oh, I probably should be, yes. But I won't, because I don't like them and never really have. I realize this is probably less productive, but at least I'm self-aware about it. And I don't think it's heresy to say that many people just don't like the current crop of debuggers out there, especially when you write in dynamic (and weakly typed) languages. Which is another bunch of bananas, but sometimes we don't get to pick what code we write in, especially in my industry.
    - thom 7y ago
      Oh I totally agree about the causes, I’m more bemoaning the tooling. I too work in languages sometimes where it’s really hard, which is why I chuckle at what 10-year-old me would think about all the complexity.
  - thom 7y ago
    And this is before even considering how much better Smalltalk and Lisp environments where years before _that_.
  - pjc50 7y ago
    A debugger is helpful if you don't know which value you want and want to go exploring. Print statements are helpful if you want the value at thousands of different points in time - you don't know when you want the value - and want to fish it out later.
    - thom 7y ago
      In that situation you’d generally use conditional breakpoints. If you’re just scrubbing up and down in thousands of lines of output looking for something fishy, that doesn’t seem very productive. I’m also on board with generative testing to find these sorts of edge cases, if relevant.
      - pjc50 7y ago
        It's the "how did I get here?" question: you have a clear logfile marker for "something went wrong", such as a stack trace, and then scroll back upwards to determine what went wrong. Can even be a negative, which is incredibly hard to do with breakpoints: "I should be seeing line X after Y or before Z, but it's not there" Can also be a ward against the insecurity of unknown unknowns - where there's a lot of moving parts and the problem isn't well isolated (we'd all like it to be, but maybe previous developers didn't design the system like that) or the OS or one of your libraries is betraying you.
        thom 7y ago
        Sure, I’m not really saying every problem in software can be solved with a debugger. But not being able to easily narrow down which part of a system is breaking an invariant shouldn’t be an everyday occurrence. Obviously shit happens (or happened in the past) and you’ve sometimes gotta do what you gotta do though.
        pjc50 7y ago
        > But not being able to easily narrow down which part of a system is breaking an invariant shouldn’t be an everyday occurrence I think there's a kind of reverse Amdahl's law at work here. Situations where there is a nice clean crash into the debugger that tells you what's going on are easy - so they don't take up much time. Situations where that doesn't work take much longer - maybe the problem doesn't replicate when you're using the debugger. And there have been situations where simply doing the data-gathering to establish that a bug was real consumes weeks. My own personal one of those was missed touchscreen events; because they were so infrequent we eventually had to set up a robot to press the screen 10,000 times, resulting in 9,999 touch events, and record a huge amount of data up and down the stack in order to work out what had happened.

JustSomeNobody 7y ago

I don’t code with a debugger either. If I need to use a debugger to figure out the logic I just wrote then I have failed to make it clean enough to understand.

klez 7y ago
Well, shit happens, and you may need to receive inputs that are out of your control, or use libraries that are less then perfect and you need to use intermediate results. In those cases a debugger (or even just strategic prints) can be a godsend.
- JustSomeNobody 7y ago
  I can use other tools. A good logging framework or wireshark, etc to capture and view data. I won’t use a third party library that is shit.
  - klez 7y ago
    What if you inherited someone else's code? Are you going to change all the libraries because you don't like them? Or even if they use good libraries, how are you going to unravel complex pieces of code? What I'm trying to say is, sometimes you need all the help you can get. And even an awful debugger is better than doing it in your head.
    - JustSomeNobody 7y ago
      I fix other devs code with a debugger. I don’t “code with a debugger” myself. I think it is wrong and lazy to do so. For third party libs I work with the vendor to unshit their shit. Or I switch, yes. I write code that has to run out in BFE for 5-10 years. I can’t be sloppy about it.