3 ms·
The primary reason I use print debugging because the UI is consistent across all languages and environments. You can literally just learn the hello world progra
by nromiun 5y ago
The primary reason I use print debugging because the UI is consistent across all languages and environments. You can literally just learn the hello world program of any language or environment (like the Linux kernel) and you are ready to use print debugging.
Compare this to debuggers, you have to learn the special syntax of the debugger, which is usually very different to the host language, and only then can you start doing some actual debugging.
> If the software industry took debugging seriously — instead of just grumbling about the tools and reverting to print debugging (or, at best, building a polished implementation of the features debuggers have had since the 1980s) — and invested accordingly we could make enormous strides, and not many people would feel the need to resort to print debugging.
This doesn't make any sense, people don't "revert" or "resort" to print debugging, they use print debugging because it is so much simpler compared to debuggers. Print debugging is already as simple as it gets, you can't cut any complexity by adding a new tool.
- incrudible 5y ago> Compare this to debuggers, you have to learn the special syntax of the debugger... In VS Code, you get the basic visual debugger UI that has been around for decades, to observe variables, set breakpoints, move about the stack, and step through the code. This works for pretty much all major languages. It's dead simple and easy to learn. It even works over SSH. Now, if you insist on doing everything through a terminal, nothing will save you from a miserable debugging experience.
- Joker_vD 5y agoYeah... every time I tried to use GDB from the terminal, I always felt like I was trying to edit text with ed. Sure, people actually did that, but holy fatcats, even vi would be so much better. You'd think that one of the points of the debugger is to let you easily inspect the program's state, but the default interface is very adept at hiding it.
- db48x 5y agoThe secret to using GDB is to type “layout split” or “layout asm” as your first command.
- rcxdude 5y agoeven so, it can easily be worse than printf debugging, depending what you're trying to investigate. Often those who advocate for always using the debugger say 'well you can just do x to get a printf through the debugger', but that's usually not easy or accessible even in GUI debuggers.
- incrudible 5y agoWith some languages, you can use "logpoints" in VS Code. To be clear, I have no issue with using print statements, but I also maintain a very short build/run cycles.
- nromiun 5y agoI never said debuggers aren't nice. I said that people prefer print debugging because that is a consistent UI across all environments. OP talks about many different debuggers and they all have different UIs. VS Code's debugger is nice, but can you seamlessly plug in rr to get time travel features? What about Pernosco?
- incrudible 5y ago> I never said debuggers aren't nice. I said that people prefer print debugging because that is a consistent UI across all environments. You said debuggers require learning "some special syntax", which is not true. This led me to believe that you weren't aware of things I wrote. > VS Code's debugger is nice, but can you seamlessly plug in rr to get time travel features? I haven't tried that, but apparently it should work: https://github.com/rr-debugger/rr/wiki/Using-rr-in-an-IDE https://github.com/rr-debugger/rr/wiki/Using-rr-in-an-IDE > What about Pernosco? The way I understand what Pernosco is (a recording), I would expect that to work as well.
- nromiun 5y agoWow, I didn't know that VS Code supports rr as well. I will have to try that, thank you. I think you misunderstood my point, there are plenty of good GUI debuggers out there. But they don't support all environments. Some IDEs only support C/C++ or Java or something else. The point is that their support is nowhere near as good as print debugging. From webdev to kernel development the API is nearly the same. Even in VS Code sometimes you have to fall back to the terminal to deal with weird environments. It is never really as "seamless" as print debugging.