Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Printf debugging is ok

polymonster.co.uk

Post reply on HN
Print view View original

111–120 of 152 posts

Re: Printf debugging is ok

#111

Post by mark_undoio »

atq2119 wrote: post #76
kadoban wrote: post #9

Earlier quoted context omitted.

Touch typing is objectively better, but 2 finger is enough to have a career at programming, it's not what is going to hold you back. I'd be more concerned about RSI than speed. You _really_ don't need to type fast for programming. If you do, your tools should be helping you do boilerplate more.

The RSI thing is real. Until my late 20s I would type blindly with what I jokingly called 5 and a half fingers. But I did start to notice some strain, which is when I decided to finally teach myself "proper" touch typing. I don't think my typing got meaningfully faster, but it got smoother, and the strain went away.

Getting a split-layout "ergo" keyboard helped me learn to type better back in the day. I could already touch type fast but not with great technique.

When I got a split layout key it became quite apparent that my technique was "weird" - sometimes I'd notice one hand come wandering over to the other side of the keyboard to find a key it was used to pressing. That became easy to correct once it was so visible!

Re: Printf debugging is ok

#112

Post by mark_undoio »

tliltocatl wrote: post #56
invalidname wrote: post #4

Counterpoint: nope. Logging is great for long term issue resolution. There's tracepoints/logpoints which let you refine the debugging experience in runtime without accidentally committing prints to the repo. There are specific types of projects that are very hard to debug (I'm working on one right now), that's a valid exception but it also indicates something that should be fixed in our stack. Print debugging is a ha…

If your code is connected to some external factory, it's impossible to pause on a breakpoint without breaking everything. And no, "just mock it" doesn't work if you have no idea on how the factory actually behaves. Printf is good because it doesn't messes up timing.

Time travel debugging (https://en.wikipedia.org/wiki/Time_travel_debugging) can be good for this situation too because it separates capturing a bug ("recording") and understanding it (the debugging phase, which happens while "replaying").

You don't need to pause anything whilst capturing the bug.

Now, if your code is literally connected to running critical systems in an actual factory then you've probably got additional realtime and safety-critical considerations that might push you towards debugging.

But (for more conventional use cases) time travel debuggers can handle multiple communicating systems without causing timeouts, capture bugs in software that interacts directly with hardware devices, etc. And you don't have to keep rebuilding / rerunning once you've reproduced the bug.

Re: Printf debugging is ok

#113

Post by throwaway2037 »

seanmcdirmid wrote: post #64
kentonv wrote: post #49

If you have a reproducible test case that runs reasonably quickly, then I think printf debugging is usually just as good as a "real" debugger, and a lot easier. I typically have my test output log open in one editor frame. I make a change to the code in another frame, save it, my build system immediately re-runs the test, and the test log immediately refreshes. So when the test isn't working, I just keep adding print…

The crashes/bugs I deal with are rarely straight down failures, they are often the 1 out of 100 runs kind, so printf debugging is the only way to go really. And I used to be big on using debuggers, but now I’m horribly out of practice.

    > they are often the 1 out of 100 runs kind
Can you share an example? In my whole career, I have only seen one or two of them, but most of my work is CRUD type of stuff, not really gaming or systems programming where such a thing might happen.

Re: Printf debugging is ok

#114

Post by throwaway2037 »

forrestthewoods wrote: post #62
seba_dos1 wrote: post #40

Earlier quoted context omitted.

To be frank, I actually find debugger to rarely be useful. When it is useful, it is super useful - but those occasions aren't that numerous, so I can totally believe that many people may get away without learning how to use it. It feels like 90% of my time in gdb is reading backtraces after segfaults, which I wouldn't really consider to be a use of a debugger. I'm still glad I can use it for the other 10%, but it's j…

GDB is a dog shit trash debugger. I keep forgetting that Linux and Mac have shit tools. I suppose if the only debugger available to me were GDB I would also prefer printf debugging! The typical modern dev loves to shit on Windows. But Visual Studio (the adult version, not VSCode) is still a best-in-class debugger. Xcode is bloated as hell but did help me last week. Linux has… poor bastards.

What is wrong with JetBrains' CLion? It is a cross-platform C & C++ IDE. I have used it on Linux, and the GUI-based debugger is so much easier to use compared to GDB from the command line.

Also: Do also say that LLDB is a "dog shit trash debugger"?

Re: Printf debugging is ok

#115

Post by oreally »

The most ideal and default go-to for quick inspections of program flow and variables should always be quick access to a good debugger when possible (ie. one single keystroke).

Everytime you have to do a printf it's a slowdown, and you can't out-argue the fact that you have to type up to 20ish keystrokes and excite a number of brain neuron cells trying to remember what that printf syntax or variable name was. In comparison to a debugger that automatically prints out your call stack and local variables even without you having to prompt them.

Re: Printf debugging is ok

#116

Post by bluenose69 »

Balance is the key, but if I only had a debugger, and not the printf option, I'd be working more slowly and swearing a bit more.

I work in a natural science, and use computing for numerical simulations and data analyses. For coding problems, a debugger is pretty handy. But for finding errors in the underlying mathematics, I tend to rely on a printf -> grep -> analysis chain. This might make files of several hundred Mb in size. The last part is generally done in R, because that lets me apply graphical and statistical methods to discover problematic conditions. Often these conditions do not crop up for quite a long time, and my task will be to find out just what I did wrong, with something like a problematic formulation of boundary condition that created an anomalous signal near an edge of a domain, but only once a signal had propagated from a forcing zone into that region of state space.

Re: Printf debugging is ok

#117

Post by Cthulhu_ »

nxobject wrote: post #50
chrsig wrote: post #19

Earlier quoted context omitted.

eternal september; people new people are continually learning new strategies. You're correct, the real issue comes down to 1. making sure those printf statements don't wind up in prod, spilling potentially sensitive data or corrupting a data stream 2. making sure that non-printf tooling is built so that only printf debugging isn't used We tend to get caught up in false dichotomies.

Re 1: the recent iTerm2 fracas. Yikes. https://news.ycombinator.com/item?id=42579472

oof, iterm's done a few bad releases recently, first with their AI integration and now this sloppiness. I think they're feeling the heat from competitors like Warp, especially now that it's removed the "create an account" barrier to entry.

Re: Printf debugging is ok

#118

Post by fweimer »

shadowgovt wrote: post #24

As with so many categorical guidelines, there are circumstances to use it and circumstances to not. The key insight is that printf() is a heavyweight operation ("What, you want to build a string? A human readable string? Okay, one second, lemme just pull in the locale library..."). If you're debugging something at the business-logic layer, it's probably fine. If you're debugging a memory leak, calling a function that…

Isn't localization triggered for specific format strings only? There are many corner cases when typical printf implementations call malloc, but it's usually not too hard to avoid them.

If you are worried about including and potential side effects from that, you can use __builtin_printf instead.

Re: Printf debugging is ok

#119

Post by ykonstant »

malkia wrote: post #23

25 years ago I worked on a port of PC -> Playstation 1 game. We did not had proper devkits, but the yaroze model ("amateur", allowing for "printf"-debugging of sorts) Long story short, our game worked as long as the printfs we had were kept, we had macro to remove them (in "Release/Ship") but the game crashed. The crash was due to side-effect of printf clearing some math errors.... So here you go!

Seems like printf debugging worked! ＼(≧▽≦)／

Re: Printf debugging is ok

#120

Post by bArray »

Honestly, it's just about doing what is easier at the time. Re-compiling an application in debug can be a pain sometimes, or getting back to a specific state within the application to inspect what is going on. Some have mentioned about hardware (which marches on with or without software running), but similarly part of a system where you only really control one sub-system/interface.

My print statements normally come when "I have no idea why this is breaking", and I start sanity checking the basics to make sure that things I previously thought were true, remain so.

Just recently I was doing something in C after a long time, and had something like this (simplified):

    #include 
    int main(){
      int a = 0; // Input from elsewhere
      switch(a){
        case 0 :
          printf("0\n");
          break;
        defult :
          printf("?\n");
          break;
      }
      return 0;
    }
It was late at night, it compiled, so I knew it wasn't a grammar issue. But after testing with printf()'s I realised that the default case was never being hit and performing the core action. It turns out 'defult' highlights in my editor and compiles fine in GCC. Turns out that any word in that location compiles fine in GCC. Nasty!
Post reply on HN