2 ms·

Use a debugger, you filthy barbarians. Learn how to step through, set breakpoints, watches, and watchpoints. Learn where to use these tools effectively. Print s

Use a debugger, you filthy barbarians. Learn how to step through, set breakpoints, watches, and watchpoints. Learn where to use these tools effectively. Print statements cannot give you a fine-grained view into the evolution of your program by stepping through, line by line or even instruction by instruction. Debuggers can. Debugging by printf() is only extant because the debugging tools generally available under Unix are stone-knives-and-bearskins compared to other environments (Windows comes to mind).

titzer 3y ago
The superpower of a debugger is watchpoints and inspecting data structures. No need to laboriously write out a rendering of the internal state of a program when you can pop open its objects and look at their state in the debugger. Breakpoints, step-in, step-over, step-out, all good things. That said, a debugger is not a substitute for robust tracing/logging. By the time a program gets mature, it will probably end up being instrumented to generate nice-looking, useful traces. Often, that will be good enough to debug in the future. I just don't understand people who will actively avoid using a tool. Like, I don't get it. Do you trim your lawn with scissors?
evnix 3y ago
The code that we currently write is at a sufficiently high level that we don't need to reach for a debugger. I have a local kubernetes cluster with 10 services running, I usually get to the root of the problem a lot faster with a few log lines than having to figure out how to configure my IDE, run the app in debug mode and get all the debug port mappings right and have the right source mappings configured. If the problem is less around business logic and more around algorithms, that's when I spend time configuring everything and stepping through the debugger.
pengaru 3y ago
This was one of the more interesting parts of John Carmack's interview on Fridman's podcast: https://www.youtube.com/watch?v=tzr7hRXcwkw https://www.youtube.com/watch?v=tzr7hRXcwkw

titzer 3y ago

The superpower of a debugger is watchpoints and inspecting data structures. No need to laboriously write out a rendering of the internal state of a program when you can pop open its objects and look at their state in the debugger. Breakpoints, step-in, step-over, step-out, all good things. That said, a debugger is not a substitute for robust tracing/logging. By the time a program gets mature, it will probably end up being instrumented to generate nice-looking, useful traces. Often, that will be good enough to debug in the future. I just don't understand people who will actively avoid using a tool. Like, I don't get it. Do you trim your lawn with scissors?

evnix 3y ago

The code that we currently write is at a sufficiently high level that we don't need to reach for a debugger. I have a local kubernetes cluster with 10 services running, I usually get to the root of the problem a lot faster with a few log lines than having to figure out how to configure my IDE, run the app in debug mode and get all the debug port mappings right and have the right source mappings configured. If the problem is less around business logic and more around algorithms, that's when I spend time configuring everything and stepping through the debugger.

pengaru 3y ago

This was one of the more interesting parts of John Carmack's interview on Fridman's podcast: https://www.youtube.com/watch?v=tzr7hRXcwkw https://www.youtube.com/watch?v=tzr7hRXcwkw