[AndriyKunitsyn]

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]

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

[AndriyKunitsyn]

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]

> 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.

[aidenn0]

Is your argument "Don't use debuggers because it will prevent you from writing a debugger?"

[akkartik]

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

[aidenn0]

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.

[CyberDildonics]

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]

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]

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]

I'm very happy to hear it! Can you point me at a few of them?

[aidenn0]

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.

[carapace]

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]

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]

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]

Why do you think so? I think I'm pretty comfortable with what I'm doing now, but maybe I don't know something.