4 ms·

That's because many programming environments have not developed their debugging tools and people have accepted it as the mediocre norm. If you're ever tried an

That's because many programming environments have not developed their debugging tools and people have accepted it as the mediocre norm. If you're ever tried an integrated IDE debugger for say debugging variables, I don't think you can possibly say print debugging is better over one keystroke for setting a breakpoint, one keystroke for running the program to the breakpoint, and one gui window that just displays the local values.

wruza 4y ago
Well I can. I’ve used debuggers from my MASM “era” to TP to TC to VB, and then dropped that habit in favor of debug logging entirely. I’d say that if you ever tried an environment where you can have that black text window and dump there whatever you want to, all your I-D-Es start to fidget nervously. But YMMV. print debugging is better over one keystroke for setting a breakpoint A breakpoint is by definition a point in your process where you can inspect things. You can’t inspect the entire path without tediously stepping through it. With debug logging you can see the path, but have to pick what you want to see to not overwhelm yourself with output. For me the latter yields much better results in general.
- oreally 4y ago
  > I’d say that if you ever tried an environment where you can have that black text window and dump there whatever you want to, all your I-D-Es start to fidget nervously. But YMMV. Well these are environments that don't allow nice code editing and debugging. So you've got to work with what you have. Doesn't make it any nicer. Certainly doesn't justify printf debug over other debuggers. > With debug logging you can see the path, but have to pick what you want to see to not overwhelm yourself with output. For me the latter yields much better results in general. Are you seriously suggesting that the time and brainpower it takes to type out the code for the prints for the entire code path, AND figuring out when the logic is for the prints happen is better over a debugger stepping through the code path? This is one of the least meaningful things a programmer could do unless they love typing for the sake of it. It's what I meant by a mediocre norm - you like coding but forget the end goal of it, so you heap lots of unimpactful management layers on top.
  - wruza 4y ago
    I automate it, cause I hate typing too. E.g. double-clicking an identifier (or selecting an expression) and pressing F3 adds the log("<sel>:", <sel>) to the next line automatically. Later I format it as a more meaningful log level/message or <C-/> it out if it was a “silly” loglevel. The ability to program an editor changes how you look at things like that. F3 to list, F2 to saveall, and instantly I see the entire new path of execution, with all insights I’ve thought of at this point. It’s like an interactive debugger, but more interactive in some sense. (I’m also barely typing keywords, e.g. “eafu” means “export async function(|) {|}” and so on.) Well these are environments that don't allow nice code editing and debugging. Idk. While that is true for some envs, I’m able to choose at my job. And what I’m usually choosing isn’t an IDE (emphasis on D). Sometimes I have to work with IDE-oriented envs and sure, there I have to use it because console and dump tools suck, but to me it feels like walking through the mud.
    - oreally 4y ago
      Nice automation, but you've spent extra brainpower programming your editor, pressing F3 on different code paths, so yea the point still stands.
      - wruza 4y ago
        Not going to argue, cause all points were made and the only thing left is to experiment. Maybe I should switch for a week to re-evaluate it in the next program which won’t require detailed retrospectives anyway.

wruza 4y ago

Well I can. I’ve used debuggers from my MASM “era” to TP to TC to VB, and then dropped that habit in favor of debug logging entirely. I’d say that if you ever tried an environment where you can have that black text window and dump there whatever you want to, all your I-D-Es start to fidget nervously. But YMMV. print debugging is better over one keystroke for setting a breakpoint A breakpoint is by definition a point in your process where you can inspect things. You can’t inspect the entire path without tediously stepping through it. With debug logging you can see the path, but have to pick what you want to see to not overwhelm yourself with output. For me the latter yields much better results in general.

oreally 4y ago
> I’d say that if you ever tried an environment where you can have that black text window and dump there whatever you want to, all your I-D-Es start to fidget nervously. But YMMV. Well these are environments that don't allow nice code editing and debugging. So you've got to work with what you have. Doesn't make it any nicer. Certainly doesn't justify printf debug over other debuggers. > With debug logging you can see the path, but have to pick what you want to see to not overwhelm yourself with output. For me the latter yields much better results in general. Are you seriously suggesting that the time and brainpower it takes to type out the code for the prints for the entire code path, AND figuring out when the logic is for the prints happen is better over a debugger stepping through the code path? This is one of the least meaningful things a programmer could do unless they love typing for the sake of it. It's what I meant by a mediocre norm - you like coding but forget the end goal of it, so you heap lots of unimpactful management layers on top.
- wruza 4y ago
  I automate it, cause I hate typing too. E.g. double-clicking an identifier (or selecting an expression) and pressing F3 adds the log("<sel>:", <sel>) to the next line automatically. Later I format it as a more meaningful log level/message or <C-/> it out if it was a “silly” loglevel. The ability to program an editor changes how you look at things like that. F3 to list, F2 to saveall, and instantly I see the entire new path of execution, with all insights I’ve thought of at this point. It’s like an interactive debugger, but more interactive in some sense. (I’m also barely typing keywords, e.g. “eafu” means “export async function(|) {|}” and so on.) Well these are environments that don't allow nice code editing and debugging. Idk. While that is true for some envs, I’m able to choose at my job. And what I’m usually choosing isn’t an IDE (emphasis on D). Sometimes I have to work with IDE-oriented envs and sure, there I have to use it because console and dump tools suck, but to me it feels like walking through the mud.
  - oreally 4y ago
    Nice automation, but you've spent extra brainpower programming your editor, pressing F3 on different code paths, so yea the point still stands.
    - wruza 4y ago
      Not going to argue, cause all points were made and the only thing left is to experiment. Maybe I should switch for a week to re-evaluate it in the next program which won’t require detailed retrospectives anyway.