The issue is a debugger will trigger every time. In video games at least you have code that runs as over and over again in tick. Putting debugger breakpoints in that would be useless most of the time. Print is where it’s at for ticking/timer debugging.
Many debuggers (at least in the Java world, which is what I’m working with for a living) support more advanced features like only triggering the breakpoint if a certain condition is reached or only every X hits of the breakpoint.
Also, if you try and debug using print in the main game loop, wouldn’t that write so much to console/log that it’s effectively unreadable?
So first, visual studio had that too but the integration with unreal is hit or miss. You can’t really do complex conditions.
Second, you lock it behind a conditional and it’s much easier to read. Like if you want to ensure the force curve of your jump matches what the float curve you give to the designer is set to then printing out and spot checking a few is much better than using float compares that would be broken in the same way in certain platforms where floating point data is interpreted differently. So you are the data on Windows, it’s different on Linux and this you can’t just compare it because it matches just like it would in windows.
Third, if you really want you don’t print to screen instead of log which if you give a key entry, it will just update it rather than spam your screen.
Overall even the most experienced engineers in the games industry uses printing of the values at times. Debuggers are of course still very preferred for most things.
Working with Nordic Semi Bluetooth Stack was like that when working with it a few years ago. If you reach a breakpoint while the Bluetooth stack was running, it would crash the program.
So printf to dump data while it ran and only break when absolutely necessary.
Someone should make that bell curve meme with people using print statements at the newb and advanced level. Debuggers are great but I’d say it’s a 50/50 split for me for debugger vs logger when I’m debugging something.
Similarly, every once in a while I’ll throw warning messages (which I can’t ship) to encourage me to go back and finish that TODO instead of letting it linger.
I found debuggers practically unusable with asynchronous code. If you’ve got a timeout in there, it will break, when you arrive at a breakpoint.
Theoretically, this could be solved by ‘pausing’ the clock that does the timeouts, but that’s not trivial.
At least, I haven’t seen it solved anywhere yet.
I mean, I’m still hoping, I’m wrong about the above, but at this point, I find it kind of ridiculous that debuggers are so popular to begin with.
Because it implies that synchronous code or asynchronous code without timeouts are still quite popular.
I’m sure it is, I’m just not terribly happy about that fact.
Thing is, any code you write ultimately starts via input and funnels into output. Those two ends have to be asynchronous, because IO fundamentally is.
That means, if at any point between I and O, you want to write synchronous code, then you have to block execution of that synchronous code while output is happening. And if you’re not at least spawning a new thread per input, then you may even block your ability to handle new input.
That can be fine, if your program has only one job to do at a time. But as soon as it needs to do a second job, that blocking becomes a problem and you’ll need to refactor lots of things to become asynchronous code.
If you just build it as asynchronous from the start, it’s significantly less painful.
But yeah, I guess, it’s the usual case of synchronous code being fine for small programs, so tons of programmers never learn to feel comfortable with asynchronous code…
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programmerhumor@lemmy.ml
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
Posts must be relevant to programming, programmers, or computer science.
No NSFW content.
Jokes must be in good taste. No hate speech, bigotry, etc.
The issue is a debugger will trigger every time. In video games at least you have code that runs as over and over again in tick. Putting debugger breakpoints in that would be useless most of the time. Print is where it’s at for ticking/timer debugging.
Many debuggers (at least in the Java world, which is what I’m working with for a living) support more advanced features like only triggering the breakpoint if a certain condition is reached or only every X hits of the breakpoint.
Also, if you try and debug using print in the main game loop, wouldn’t that write so much to console/log that it’s effectively unreadable?
So first, visual studio had that too but the integration with unreal is hit or miss. You can’t really do complex conditions.
Second, you lock it behind a conditional and it’s much easier to read. Like if you want to ensure the force curve of your jump matches what the float curve you give to the designer is set to then printing out and spot checking a few is much better than using float compares that would be broken in the same way in certain platforms where floating point data is interpreted differently. So you are the data on Windows, it’s different on Linux and this you can’t just compare it because it matches just like it would in windows.
Third, if you really want you don’t print to screen instead of log which if you give a key entry, it will just update it rather than spam your screen.
Overall even the most experienced engineers in the games industry uses printing of the values at times. Debuggers are of course still very preferred for most things.
Try debugging a distributed embedded real time system which crashes when you are in a breakpoint too long because the heartbeat doesn’t respond
Working with Nordic Semi Bluetooth Stack was like that when working with it a few years ago. If you reach a breakpoint while the Bluetooth stack was running, it would crash the program.
So printf to dump data while it ran and only break when absolutely necessary.
Oh? Another embedded programmer? This behavior pains me as well.
Yeah. I mostly code in C because the tools come natively in C. I also do python and C# to create tools for my embedded projects.
Or just any dpdk program, where any gdb caused slowdown causes the code to “behave as expected”
Because I have nested loops and only want to see certain cases and I’m not smart enough to set up conditional breakpoints or value watching
Programming is also about learning your tools :)
Looks like godot doesn’t have it yet
Value watching is just printf; change my mind
Someone should make that bell curve meme with people using print statements at the newb and advanced level. Debuggers are great but I’d say it’s a 50/50 split for me for debugger vs logger when I’m debugging something.
I honestly need to remember the debugger exists. They weren’t common for interpreted languages when I got started.
because, sometimes, having your program vomit all over your console is the best way to remain focused on the problem.
Similarly, every once in a while I’ll throw warning messages (which I can’t ship) to encourage me to go back and finish that TODO instead of letting it linger.
because sometimes you need to investiagte an issue that happens only on the production machines, and you can’t/shouldn’t setup debugging on those.
I still use print as a quick “debug” its just convenient to have multiple prints in the code when you’re iterating and changing code.
Debugger? I hardly know er
Because it takes 3 hours to reach the error and I’ve got other shit to fix.
You’re gonna want logging in production…
Debugger good for microscopic surgery, log stream good for real time macro view. Both perspectives needed.
I found debuggers practically unusable with asynchronous code. If you’ve got a timeout in there, it will break, when you arrive at a breakpoint.
Theoretically, this could be solved by ‘pausing’ the clock that does the timeouts, but that’s not trivial.
At least, I haven’t seen it solved anywhere yet.
I mean, I’m still hoping, I’m wrong about the above, but at this point, I find it kind of ridiculous that debuggers are so popular to begin with.
Because it implies that synchronous code or asynchronous code without timeouts are still quite popular.
it isn’t?
I’m sure it is, I’m just not terribly happy about that fact.
Thing is, any code you write ultimately starts via input and funnels into output. Those two ends have to be asynchronous, because IO fundamentally is.
That means, if at any point between I and O, you want to write synchronous code, then you have to block execution of that synchronous code while output is happening. And if you’re not at least spawning a new thread per input, then you may even block your ability to handle new input.
That can be fine, if your program has only one job to do at a time. But as soon as it needs to do a second job, that blocking becomes a problem and you’ll need to refactor lots of things to become asynchronous code.
If you just build it as asynchronous from the start, it’s significantly less painful.
But yeah, I guess, it’s the usual case of synchronous code being fine for small programs, so tons of programmers never learn to feel comfortable with asynchronous code…
The debugger can’t handle the chonkers app I work on.
Uhh, I’m too lazy to learn all the GDB commands.
I do automatic testing, debug is a waste of time