4 ms·

That's all good, but if the problem itself operates with more data than a human can reasonably operate with, this no longer applies. I do 3D meshes programming

That's all good, but if the problem itself operates with more data than a human can reasonably operate with, this no longer applies. I do 3D meshes programming. The amount of vertices, planes and other geometrical entities that I need to operate with in my algorithms is too big for me to do printf debugging. I can't just look on a long list of 3D vertex coordinates and visualize the mesh they make in my head. Moreover, I had to come with my own 3D visualization tool, once I got fed up with pen and paper for converting 3D coordinates to actual meshes, or using Blender for that. For me, a debugger (and debugging tools in general) is irreplaceable. I'm not saying my field is the most complex one, because it clearly isn't - but in that field, I can't think of any other way I could do what I do.

akkartik 4y ago
But it sounds like you had to come up with your own tools because a debugger wasn't enough? That's my biggest criticism of debuggers having used both approaches: you forget that sometimes you need new tools. Whereas with prints you're constantly building new instrumentation for yourself. https://merveilles.town/@akkartik/106138280776488247 https://merveilles.town/@akkartik/106138280776488247
- CyberDildonics 4y ago
  Whereas with prints you're constantly building new instrumentation for yourself. What does this mean? Formatting text differently is still text, which the parent post was just explaining doesn't cut it.
  - akkartik 4y ago
    I'm constantly finding new places in my program to add prints to. This isn't just copy changes. (Though that has also had a huge impact occasionally in understanding something. Imagine emitting 2 variables and then focusing on 1 of them. A pattern can pop out of a screenful of iterations of a loop when things line up just right.)
    - aidenn0 4y ago
      There are debuggers that will let you halt your program, go back in time, and then print out each place where a specific variable changes. If that's "interacting with your program through a pane of glass" then shrug.
      - akkartik 4y ago
        I'm very happy to hear it! Can you point me at a few of them?
        aidenn0 4y ago
        Mentioned in TFA is "rr"; it serves up to gdb the history of the program and you can use tracepoints (also mentioned in TFA) to essentially retroactively add prints. Gdb is ... not particularly ergonomic, but it is eminently scriptable and writing programs to generate arbitrary logs post-facto is a useful skill. Undo is another one for Linux programs, and I think I've seen developers from them post here.
        akkartik 4y ago
        The big problem with debuggers in my experience is the difficulty of setup. They take a lot of code to build, and if you use a slightly different language or compiler or OS you're SoL. Or at least facing some rabbitholes of unknown depth. The most sophisticated debuggers seem to target C or Lisp. But lately I don't use either. I've never gotten time-travel debugging in gdb to work. And it's been out for more than 10 years at this point. The last time was 2 years ago, so I forget the details. I do love tracepoints in gdb. I've been watching https://rr-project.org https://rr-project.org for a while. The instructions still say, "build from source". I looked at LLDB after your previous comment. Got it installed, but I can't actually get it to set a breakpoint on Linux. The docs seem optimized for Mac. I have no doubt that once you get something set up just right you can do great things with it. But the power to weight ratio seems totally out of whack. Part of the goal of my projects recently has been to show that you can get a bunch of features far more simply if you build on a base of logging. If the programmer is willing to modify the program, a single tool can help debug programs in a wide variety of languages. They just have to follow a common and fairly simple protocol. The big drawback of my approaches is that they don't scale for long runs of huge codebases. That hasn't been an issue for most programs I ever want to debug. Why should I pay the complexity costs of debugging gcc or Firefox for small programs.
- aidenn0 4y ago
  Is your argument "Don't use debuggers because it will prevent you from writing a debugger?"
  - akkartik 4y ago
    I'm not arguing "don't use debuggers." I'm arguing, "don't just use debuggers." I elaborate more on this argument in the first 2 minutes of this 4-minute video: https://handmade.network/snippet/1561 https://handmade.network/snippet/1561
    - aidenn0 4y ago
      That makes sense. I'm also with you in that programmers forget that their development tools are also programs and they can modify and/or make more of them.
- AndriyKunitsyn 4y ago
  I'm not sure I'm following. A visual debugger ticks a lot of boxes for my needs. Not all - some of them I had to tick myself, but I don't think that trying to reinvent the value that's already there in a debugger, would be particularly productive for me. As for "forgetting", I don't think I forgot, because, well, I did make a new tool. The main thing that I wanted to address in the parent comment is that needing tools to debug your code somehow means that the code is a mess - no, sometimes it doesn't.
  - akkartik 4y ago
    > The main thing that I wanted to address in the parent comment is that needing tools to debug your code somehow means that the code is a mess - no, sometimes it doesn't. Ah. I totally agree with that. Or at least, it's the sort of mess I don't know how to avoid yet.
carapace 4y ago
FWIW it sounds to me like you're using what effectively amounts to fancy 3D printf, eh? In other words logging/printf help "visualize" non-geometrical entities.
- AndriyKunitsyn 4y ago
  Not _only_ that. It was an example of how tools help me deal with inherent complexity that cannot be dealt with by "just write better code". I do use debugger. During big fixing, I need answers to various questions, such as: on what halfspace does a vertex lie? Is this point inside that polygon? What is the distance between two points? - and so on. If I didn't have a debugger, I'd have to stop the program, find the distinguishing features of the entities I'm interested in again - and this is often the hardest part, since the same code can be called thousands of times with different data - put printfs, rebuild, relaunch and prepare for another cycle. With a debugger, I just put these questions into LLDB queries - and I get answers. It is so much faster. Would it be possible for me to do my job without all that, using debug prints only? Theoretically, yes. Would it be practical? Absolutely not.
  - carapace 4y ago
    Meaning no disrespect, and I swear I'm not just being contrary for kicks, but it now sounds (to me) like you want to be using Common Lisp? It sounds like you're fighting your tools with your tools.
    - AndriyKunitsyn 4y ago
      Why do you think so? I think I'm pretty comfortable with what I'm doing now, but maybe I don't know something.

akkartik 4y ago

But it sounds like you had to come up with your own tools because a debugger wasn't enough? That's my biggest criticism of debuggers having used both approaches: you forget that sometimes you need new tools. Whereas with prints you're constantly building new instrumentation for yourself. https://merveilles.town/@akkartik/106138280776488247 https://merveilles.town/@akkartik/106138280776488247

CyberDildonics 4y ago
Whereas with prints you're constantly building new instrumentation for yourself. What does this mean? Formatting text differently is still text, which the parent post was just explaining doesn't cut it.
- akkartik 4y ago
  I'm constantly finding new places in my program to add prints to. This isn't just copy changes. (Though that has also had a huge impact occasionally in understanding something. Imagine emitting 2 variables and then focusing on 1 of them. A pattern can pop out of a screenful of iterations of a loop when things line up just right.)
  - aidenn0 4y ago
    There are debuggers that will let you halt your program, go back in time, and then print out each place where a specific variable changes. If that's "interacting with your program through a pane of glass" then shrug.
    - akkartik 4y ago
      I'm very happy to hear it! Can you point me at a few of them?
      - aidenn0 4y ago
        Mentioned in TFA is "rr"; it serves up to gdb the history of the program and you can use tracepoints (also mentioned in TFA) to essentially retroactively add prints. Gdb is ... not particularly ergonomic, but it is eminently scriptable and writing programs to generate arbitrary logs post-facto is a useful skill. Undo is another one for Linux programs, and I think I've seen developers from them post here.
        akkartik 4y ago
        The big problem with debuggers in my experience is the difficulty of setup. They take a lot of code to build, and if you use a slightly different language or compiler or OS you're SoL. Or at least facing some rabbitholes of unknown depth. The most sophisticated debuggers seem to target C or Lisp. But lately I don't use either. I've never gotten time-travel debugging in gdb to work. And it's been out for more than 10 years at this point. The last time was 2 years ago, so I forget the details. I do love tracepoints in gdb. I've been watching https://rr-project.org https://rr-project.org for a while. The instructions still say, "build from source". I looked at LLDB after your previous comment. Got it installed, but I can't actually get it to set a breakpoint on Linux. The docs seem optimized for Mac. I have no doubt that once you get something set up just right you can do great things with it. But the power to weight ratio seems totally out of whack. Part of the goal of my projects recently has been to show that you can get a bunch of features far more simply if you build on a base of logging. If the programmer is willing to modify the program, a single tool can help debug programs in a wide variety of languages. They just have to follow a common and fairly simple protocol. The big drawback of my approaches is that they don't scale for long runs of huge codebases. That hasn't been an issue for most programs I ever want to debug. Why should I pay the complexity costs of debugging gcc or Firefox for small programs.
aidenn0 4y ago
Is your argument "Don't use debuggers because it will prevent you from writing a debugger?"
- akkartik 4y ago
  I'm not arguing "don't use debuggers." I'm arguing, "don't just use debuggers." I elaborate more on this argument in the first 2 minutes of this 4-minute video: https://handmade.network/snippet/1561 https://handmade.network/snippet/1561
  - aidenn0 4y ago
    That makes sense. I'm also with you in that programmers forget that their development tools are also programs and they can modify and/or make more of them.
AndriyKunitsyn 4y ago
I'm not sure I'm following. A visual debugger ticks a lot of boxes for my needs. Not all - some of them I had to tick myself, but I don't think that trying to reinvent the value that's already there in a debugger, would be particularly productive for me. As for "forgetting", I don't think I forgot, because, well, I did make a new tool. The main thing that I wanted to address in the parent comment is that needing tools to debug your code somehow means that the code is a mess - no, sometimes it doesn't.
- akkartik 4y ago
  > The main thing that I wanted to address in the parent comment is that needing tools to debug your code somehow means that the code is a mess - no, sometimes it doesn't. Ah. I totally agree with that. Or at least, it's the sort of mess I don't know how to avoid yet.

carapace 4y ago

FWIW it sounds to me like you're using what effectively amounts to fancy 3D printf, eh? In other words logging/printf help "visualize" non-geometrical entities.

AndriyKunitsyn 4y ago
Not _only_ that. It was an example of how tools help me deal with inherent complexity that cannot be dealt with by "just write better code". I do use debugger. During big fixing, I need answers to various questions, such as: on what halfspace does a vertex lie? Is this point inside that polygon? What is the distance between two points? - and so on. If I didn't have a debugger, I'd have to stop the program, find the distinguishing features of the entities I'm interested in again - and this is often the hardest part, since the same code can be called thousands of times with different data - put printfs, rebuild, relaunch and prepare for another cycle. With a debugger, I just put these questions into LLDB queries - and I get answers. It is so much faster. Would it be possible for me to do my job without all that, using debug prints only? Theoretically, yes. Would it be practical? Absolutely not.
- carapace 4y ago
  Meaning no disrespect, and I swear I'm not just being contrary for kicks, but it now sounds (to me) like you want to be using Common Lisp? It sounds like you're fighting your tools with your tools.
  - AndriyKunitsyn 4y ago
    Why do you think so? I think I'm pretty comfortable with what I'm doing now, but maybe I don't know something.