5 ms·

This makes sense to me for certain types of codebases. I would almost never bother stepping through code I wrote by myself for example. But when I’m working on

This makes sense to me for certain types of codebases. I would almost never bother stepping through code I wrote by myself for example. But when I’m working on large software projects or certain external libraries I tend to encounter bugs or design issues where I realize I made the wrong assumptions about how someone else’s code works in the first place, and a good debugger is very useful in those cases when the problem changes from debugging your own logic to reverse engineering someone else’s.

toastking 8y ago
This is why I think debuggers are necessary. Without being able to see a full stack frame of information about variables it can be extremely difficult to debug when using other people's code. So many errors boil down to assumptions about what is in a value.
- lugg 8y ago
  Why are you giving your functions uncertain data? The first point your code sees uncertain data is the point that it needs to clarify what it has. The only way you get the errors you're talking about is if you ignore the above practice. Garbage in. Garbage out. For code i write, there is usually only one option for what is in a variable, the type of the data i out in there. This is true for dynamic languages as much as static. In some situations I will also allow a null value. All that means is that there was no data, and no default is wanted. Usually, I want a default. Closing off all entry points for uncertain data you need to make assumptions about is the first port of call when dealing with other people's or legacy code. It's the way to reason about code without a debugger. If you can't reason about code without a big question mark above every piece of data you need a debugger.
  - okcando 8y ago
    This amounts to saying that you don't need a debugger if you don't make mistakes. If your mental model of how the code that you're interfacing with works is wrong, then it won't help you. Your data validation will error out and you might find that it was too much too early. Not only do you have logic based on flawed assumptions but check code as well. Understanding the code base you're programming against, that's a skill that can be improved but hoping to guard against all misunderstandings is probably unrealistic. Given that, following a trace may help you identify disagreements with your model more quickly.
    - rbanffy 8y ago
      > This amounts to saying that you don't need a debugger if you don't make mistakes. Not making mistakes certainly saves time. I often use a debugger to inspect variables and check my assumptions about the application state at that point.
    - lugg 8y ago
      Far from it. I am saying you don't need a debugger in the scenario above because the only time you need it in that case is if your inputs can't be trusted. If you control the domain, the only way you can't trust your input is if you fucked up. The answer to that isn't "oh now I need a debugger" the answer is to go clean your code. While I'm here, I'd also like to point out this isn't a "I'm good and your shit" thing I'm describing, this is my day job. I make lazy crap code to get things done, then I go in to modify it and find I can't reason about it, so I go and clean up the mess. Maybe I made it, maybe I didn't, it's besides the point, you have a mess, clean that first, then reach for a debugger. Hell reach for a debugger to help clean up if you need to, just don't sit there and tell me you need a debugger because code inherintly needs to make assumptions about what is in a variable. It doesn't. If it does, it's a code smell. > So many errors boil down to assumptions about what is in a value. Only avoidable errors. They should not be dictating your tools or your language.
  - compiler-guy 8y ago
    https://rachelbythebay.com/w/2018/04/28/meta/ https://rachelbythebay.com/w/2018/04/28/meta/
    - asveikau 8y ago
      I generally like her writing when I come across it, but I disagree with that one. Good programmers are humans and make mistakes, of course. However, that doesn't mean good programmers don't exist or that people can't vary a lot in skill or average quality of output. She is correct that starting with some notion of "good people" is no silver bullet. But the conclusion that "we all suck", I hope that is hyperbole, because it isn't true. (Or maybe: everybody sucks a little bit differently.)
      - deleted 8y ago
        [deleted]
      - lugg 8y ago
        Yea, I find this take on my post odd. I am the first person to understand developers are far from perfect, my self included. But it's just code, you can refactor and learn from mistakes. The thing I don't buy is that this stuff is difficult or that you can't expect good behavior from professionals. Avoiding side effects, or pushing them out to the edge where reasoning about them is clear is something you should have been taught when you got your expensive piece of paper. Likewise, avoiding, mutation, over abstraction, early optimisation, and variable reuse are all really basic shit you need to understand, if you're not hiring for these basic qualities, what the fuck are you hiring for? Good looks?
      - Tempest1981 8y ago
        I interpreted her point as, "don't be overconfident or arrogant", such that you think that everyone else sucks. That you're too good to "lower" yourself to everyone else's level.
    - lugg 8y ago
      I'm sorry did you mean to imply something with that link?
  - pjc50 8y ago
    Ironically kernel space is one of the places where you're more likely to get "wrong" values being teleported in to your program by bits of hardware, kernels running on other cores, and nightmare out-of-spec ACPI BIOSes. An example inconvenient debugging story: https://mjg59.dreamwidth.org/11235.html https://mjg59.dreamwidth.org/11235.html (I don't think DMA triggers hardware watchpoints, but if you set a hardware watchpoint and an an address changes value without hitting a watchpoint you know that something funny is going on)
bgdam 8y ago
> But when I’m working on large software projects or certain external libraries I tend to encounter bugs or design issues where I realize I made the wrong assumptions about how someone else’s code works in the first place This. A few days ago, I spent a couple of hours trying to get a Jest+Enzyme test to open in chrome inspector, (apparently there's a bug which causes debugger statements in Jest tests to be ignored), because I hit an edge case bug in a method in the Enzyme library. If I had been able to step through it in the debugger, it would have taken me minutes to figure it out, instead I spent a couple of hours going through the codebase and figuring out where to put the log statements.
andyidsinga 8y ago
for that case - rather than resort to the debugger - I've always went through the code, come up with a theory of operation and then and instrumented it with either print statements or a scoreboard style struct in some shared mem to validate.
btilly 8y ago
This is absolutely true. But when everyone starts taking this view on it, the result is that changes get made tactically based on what makes your task work. With no understanding of the overall vision. The result undermines the integrity of the system, and makes debuggers ever more necessary going forward. This is a good point to hold in your mind as you read or re-read Programming as Theory Building by Peter Naur: http://pages.cs.wisc.edu/~remzi/Naur.pdf http://pages.cs.wisc.edu/~remzi/Naur.pdf.
- stcredzero 8y ago
  But when everyone starts taking this view on it, the result is that changes get made tactically based on what makes your task work. With no understanding of the overall vision. The result undermines the integrity of the system, and makes debuggers ever more necessary going forward. I guess the pie in the sky vision is that tactically making your task work somehow becomes harmonized with the overall vision. Extreme Programming was supposed to do this through the high information exchange of pair programming, the constant refactoring, and the practice of there only being 7 or so large scale patterns for the whole of the application. The way this works in most of the real world, is that it's supposed to work like this, but there's no pair programming, and you never get enough time to refactor.
beatgammit 8y ago
Exactly. I mostly use the debugger to see the call stack so I can understand what calls what without having to read everything. I can work backward from the faulty behavior to better understand the context of the issue. I rarely actually fire up the debugger, and I try to refrain from gratuitous prints (though I use them in emergencies or if a debugger isn't convenient). I think this makes me a better programmer, though that's really hard to tell objectively.

toastking 8y ago

This is why I think debuggers are necessary. Without being able to see a full stack frame of information about variables it can be extremely difficult to debug when using other people's code. So many errors boil down to assumptions about what is in a value.

lugg 8y ago
Why are you giving your functions uncertain data? The first point your code sees uncertain data is the point that it needs to clarify what it has. The only way you get the errors you're talking about is if you ignore the above practice. Garbage in. Garbage out. For code i write, there is usually only one option for what is in a variable, the type of the data i out in there. This is true for dynamic languages as much as static. In some situations I will also allow a null value. All that means is that there was no data, and no default is wanted. Usually, I want a default. Closing off all entry points for uncertain data you need to make assumptions about is the first port of call when dealing with other people's or legacy code. It's the way to reason about code without a debugger. If you can't reason about code without a big question mark above every piece of data you need a debugger.
- okcando 8y ago
  This amounts to saying that you don't need a debugger if you don't make mistakes. If your mental model of how the code that you're interfacing with works is wrong, then it won't help you. Your data validation will error out and you might find that it was too much too early. Not only do you have logic based on flawed assumptions but check code as well. Understanding the code base you're programming against, that's a skill that can be improved but hoping to guard against all misunderstandings is probably unrealistic. Given that, following a trace may help you identify disagreements with your model more quickly.
  - rbanffy 8y ago
    > This amounts to saying that you don't need a debugger if you don't make mistakes. Not making mistakes certainly saves time. I often use a debugger to inspect variables and check my assumptions about the application state at that point.
  - lugg 8y ago
    Far from it. I am saying you don't need a debugger in the scenario above because the only time you need it in that case is if your inputs can't be trusted. If you control the domain, the only way you can't trust your input is if you fucked up. The answer to that isn't "oh now I need a debugger" the answer is to go clean your code. While I'm here, I'd also like to point out this isn't a "I'm good and your shit" thing I'm describing, this is my day job. I make lazy crap code to get things done, then I go in to modify it and find I can't reason about it, so I go and clean up the mess. Maybe I made it, maybe I didn't, it's besides the point, you have a mess, clean that first, then reach for a debugger. Hell reach for a debugger to help clean up if you need to, just don't sit there and tell me you need a debugger because code inherintly needs to make assumptions about what is in a variable. It doesn't. If it does, it's a code smell. > So many errors boil down to assumptions about what is in a value. Only avoidable errors. They should not be dictating your tools or your language.
- compiler-guy 8y ago
  https://rachelbythebay.com/w/2018/04/28/meta/ https://rachelbythebay.com/w/2018/04/28/meta/
  - asveikau 8y ago
    I generally like her writing when I come across it, but I disagree with that one. Good programmers are humans and make mistakes, of course. However, that doesn't mean good programmers don't exist or that people can't vary a lot in skill or average quality of output. She is correct that starting with some notion of "good people" is no silver bullet. But the conclusion that "we all suck", I hope that is hyperbole, because it isn't true. (Or maybe: everybody sucks a little bit differently.)
    - deleted 8y ago
      [deleted]
    - lugg 8y ago
      Yea, I find this take on my post odd. I am the first person to understand developers are far from perfect, my self included. But it's just code, you can refactor and learn from mistakes. The thing I don't buy is that this stuff is difficult or that you can't expect good behavior from professionals. Avoiding side effects, or pushing them out to the edge where reasoning about them is clear is something you should have been taught when you got your expensive piece of paper. Likewise, avoiding, mutation, over abstraction, early optimisation, and variable reuse are all really basic shit you need to understand, if you're not hiring for these basic qualities, what the fuck are you hiring for? Good looks?
    - Tempest1981 8y ago
      I interpreted her point as, "don't be overconfident or arrogant", such that you think that everyone else sucks. That you're too good to "lower" yourself to everyone else's level.
  - lugg 8y ago
    I'm sorry did you mean to imply something with that link?
- pjc50 8y ago
  Ironically kernel space is one of the places where you're more likely to get "wrong" values being teleported in to your program by bits of hardware, kernels running on other cores, and nightmare out-of-spec ACPI BIOSes. An example inconvenient debugging story: https://mjg59.dreamwidth.org/11235.html https://mjg59.dreamwidth.org/11235.html (I don't think DMA triggers hardware watchpoints, but if you set a hardware watchpoint and an an address changes value without hitting a watchpoint you know that something funny is going on)

bgdam 8y ago

> But when I’m working on large software projects or certain external libraries I tend to encounter bugs or design issues where I realize I made the wrong assumptions about how someone else’s code works in the first place This. A few days ago, I spent a couple of hours trying to get a Jest+Enzyme test to open in chrome inspector, (apparently there's a bug which causes debugger statements in Jest tests to be ignored), because I hit an edge case bug in a method in the Enzyme library. If I had been able to step through it in the debugger, it would have taken me minutes to figure it out, instead I spent a couple of hours going through the codebase and figuring out where to put the log statements.

andyidsinga 8y ago

for that case - rather than resort to the debugger - I've always went through the code, come up with a theory of operation and then and instrumented it with either print statements or a scoreboard style struct in some shared mem to validate.

btilly 8y ago

This is absolutely true. But when everyone starts taking this view on it, the result is that changes get made tactically based on what makes your task work. With no understanding of the overall vision. The result undermines the integrity of the system, and makes debuggers ever more necessary going forward. This is a good point to hold in your mind as you read or re-read Programming as Theory Building by Peter Naur: http://pages.cs.wisc.edu/~remzi/Naur.pdf http://pages.cs.wisc.edu/~remzi/Naur.pdf.

stcredzero 8y ago
But when everyone starts taking this view on it, the result is that changes get made tactically based on what makes your task work. With no understanding of the overall vision. The result undermines the integrity of the system, and makes debuggers ever more necessary going forward. I guess the pie in the sky vision is that tactically making your task work somehow becomes harmonized with the overall vision. Extreme Programming was supposed to do this through the high information exchange of pair programming, the constant refactoring, and the practice of there only being 7 or so large scale patterns for the whole of the application. The way this works in most of the real world, is that it's supposed to work like this, but there's no pair programming, and you never get enough time to refactor.

beatgammit 8y ago

Exactly. I mostly use the debugger to see the call stack so I can understand what calls what without having to read everything. I can work backward from the faulty behavior to better understand the context of the issue. I rarely actually fire up the debugger, and I try to refrain from gratuitous prints (though I use them in emergencies or if a debugger isn't convenient). I think this makes me a better programmer, though that's really hard to tell objectively.