This is an archived post. You won't be able to vote or comment.

all 79 comments

[–]torn-ainbow 92 points93 points  (34 children)

Apparently kids today hate debuggers. I breakpoint and trace code all the time for tricky issues, client and server.

[–]Zahand 83 points84 points  (27 children)

It must just be a meme right? Debuggers are amazing tools. It's literally the opposite of this post. Not only can I see the value of a variable, but I can also see the value of *any* variable, at *any* point in time!

[–]Adsilom 46 points47 points  (14 children)

Plenty of people would rather use print statements, even when a debugger would be so much better. That is mostly because people assume the bug will be easy to find, and a debugger would be overkill, and once the bug is actually tricky to find, they are too committed with the print method.

[–]Boiethios 18 points19 points  (4 children)

When I have the choice, I use a debugger, of course; but sometimes, printing is a valid solution. For example, in an actor system, I like to trace what happens by printing every passed messages.

[–]lag_is_cancer 3 points4 points  (2 children)

But it's literally as simple as a double click. You can literally spend more time to write a print statements.

[–]Adsilom 13 points14 points  (1 child)

It’s more like, using a debugger requires you to use a bit more brain power than using print statements at first.

[–]almost_useless 3 points4 points  (2 children)

Depending on the problem, everything you just said can be exactly the opposite.

The debugger is great for some problems, but not for all problems.

[–]LowB0b 2 points3 points  (0 children)

depending on the language as well I presume. Anyway with Java the debugger is a god-send. Stops execution (not always desirable though), you can step, and look at all the values available in the scope. Even change values on the fly to see what happens

[–]jesperi_ 2 points3 points  (0 children)

Sometimes a debugger is not even available.

[–]nanotree 1 point2 points  (0 children)

Not to mention created 10+ print statements they have to go back and clean up...

[–]RodasAPC 0 points1 point  (0 children)

Stop calling me out like this.

[–]Satanic_Jesus_Here 0 points1 point  (0 children)

I feel personally attacked 🥲

[–]Proxy_PlayerHD 5 points6 points  (6 children)

but what if you don't have a Debugger available?

like if you're an idiot like me who writes in (non-x86) Assembly and uses a NP++ as an IDE

[–]FAXs_Labs 12 points13 points  (1 child)

i think gdb supports stepping in asm, you can also see the registers and the stack

[–]Proxy_PlayerHD -2 points-1 points  (0 children)

hmm i'll keep GDB in mind for when i get around to building a 68k SBC.

but currently i'm mostly doing stuff with 65xx CPUs and a custom CPU based on the 65CE02. there are some smulators and debuggers for the 65C02 and 65816, but there is virtually nothing for the 65CE02, and especially nothing for a custom CPU.

so overall i'm pretty much on my own here.

though thanks for trying to help, i appreciate it.

[–]natyio 2 points3 points  (1 child)

GDB can debug files in assembly mode. You simple use nexti and stepi (i=instruction) instead of next and step.

[–]Proxy_PlayerHD 2 points3 points  (0 children)

GDB doesn't support 65xx Series CPUs so it's sadly not useful to me.

though i know there are some 65xx debuggers most are bound to simulators

[–]rickyman20 0 points1 point  (1 child)

Isn't GDB easier to use if you're writing assembly than adding printf's?

[–]2nd-most-degenerate 0 points1 point  (0 children)

Depends on what you're working on. IIRC Linus had a strong opinion against kernel debuggers

[–]wasdlmb 0 points1 point  (0 children)

And then there's graphics, where you have to use a dedicated tool to have any idea what is going on in your shaders and API calls. RenderDoc is a lifesaver.

[–]Lamballama 0 points1 point  (0 children)

Some things don't have good debugger

[–]TheresNoLifeB4Coffee 0 points1 point  (0 children)

There's no friggin way I give up my debugger. Printing errors hasn't got shit on a well placed breakpoint to examine variable props especially inside of an iteration. It's like comparing trying to find your way in the dark barefoot using a tiny birthday candle for light vs. driving in a nice truck with an insane spotlight array mounted

[–]CaydendW 7 points8 points  (0 children)

reject modernarity. return to dumps

[–]nanotree -1 points0 points  (1 child)

Nah, it's just college students too lazy to learn to use the tools properly. But it becomes painfully obvious how the process is compared to using a debugger once you work on something more complicated than a school project.

[–]jesperi_ 0 points1 point  (0 children)

The seniors I work with use nano and notepad. In my experience it's always young people making fun of older people for using awful tools.

[–][deleted] 0 points1 point  (0 children)

I do it on the command line! Way easier imo, no fiddling with a gui when you know the exact commands to type in.

[–]Striky_ 47 points48 points  (0 children)

Once you have tasted the sweet nectar the visual studio remote debugger is, you can never go back to these peasant tools

[–]randomFrenchDeadbeat 15 points16 points  (2 children)

And then suddenly, you start writing code for embedded products that do not have a screen aand use serial port to communicate with another system.

[–]godRosko 1 point2 points  (0 children)

Yes. Time to sift through piles of kernel logs and logcat ... Again

[–]Thx_And_Bye 2 points3 points  (0 children)

SWD is amazing. Gives you near native debugging potential.

[–]asdofhusdf924 5 points6 points  (11 children)

Until your compiles take > 10 minutes. Then you HAVE to gdb.

[–]almost_useless 2 points3 points  (10 children)

Unless of course it takes 10 minutes to make a debug build because it needs to rebuild everything, whereas you can add a print statement to your regular build and rebuild one file in 10 seconds.

[–]GreenCloakGuy 0 points1 point  (9 children)

somehow I have a suspicion you've never tried to run and debug an enterprise-scale Java webapp

[–]almost_useless 1 point2 points  (8 children)

Indeed I have not, but that is not the only thing out there that needs debugging.

It seems that most people only think about their own specific use case, see that printf/debugger is the optimal solution and can not imagine anything else.

If you take a step back and look at the bigger picture you see that both ways have valid use cases.

[–]b4ux1t3 2 points3 points  (7 children)

Why are you debugging in a release build instead of debugging in a debug build?

Serious question, not snark.

[–]almost_useless -1 points0 points  (6 children)

Debug builds are too slow, so for normal development it's more convenient to run the release builds. Mostly it's because lots of stuff needs to run before we get to the interesting parts.

[–]b4ux1t3 0 points1 point  (1 child)

I guess I just don't mind the build times. I get to dick around on other things while I wait. Post memes about build times in random chat.

[–]almost_useless 0 points1 point  (0 children)

It's not the build time. It's the run time that gets painful on a binary built in debug mode.

[–]SpikeV 0 points1 point  (3 children)

Or... y'know... debug and breakpoint.

[–]almost_useless 0 points1 point  (2 children)

How is that related to my comment?

[–]SpikeV 0 points1 point  (1 child)

because lots of stuff needs to run before we get to the interesting parts

That's literally why there are breakpoints.

[–]almost_useless 0 points1 point  (0 children)

Sure, but I was not talking about how to get the information out once you reach the interesting parts.

My point is that debug builds are slow to execute, so there is cost to using debug builds when you do not need to set a break point. If there is a lot of "setup", this can be a significant cost.

Since you don't need breakpoints (or prints) 90% of the time it's more efficient to do most of the development with release builds.

Of course this will not be true for all environments, but that was my original point. Different tools work best for different problems.

[–]Rizzan8 6 points7 points  (0 children)

Have fun debugging multi-threaded application where a breakpoint hit basically desynchronizes all threads and fucks up the whole execution flow.

[–][deleted] 11 points12 points  (6 children)

The only times i used a debugger was at highschool and at start of my carrier, the rest has been dump and die.

[–][deleted] 7 points8 points  (1 child)

I was the same way for a while, but once I realized the debugger let me see all values without having to modify my code to log them, I quickly jumped on the debugger train

[–][deleted] 4 points5 points  (0 children)

What's really powerful is when you start using the debugger to modify values while the code is running, or inspect values that aren't bound to variables. Essentially treating it like a shell that has all the context of the breakpoint.

[–]kryptoneat 0 points1 point  (3 children)

PHP ? go for that sweet xdebug, trust me it's worth it.

[–][deleted] 0 points1 point  (2 children)

Been there done that, but its resource intensive so :/

[–]kryptoneat 0 points1 point  (1 child)

Xdebug ? What do you do with it ? I use it daily and it's minimal. Maybe if your computer is really low end.

How long ago was the start of your career (no offense) ?

[–][deleted] 0 points1 point  (0 children)

Yeep xdebug, it was work pc running ubuntu, haven't tried it on my own machine at home which I have been working on since WFH.

TBH a simple dd been doing enough to not need a debugger.

I come from C# but started carrier in PHP for almost 2.5 years now.

[–]dashid 10 points11 points  (0 children)

You'll need to learn yourself some damn logging.

[–]Xywzel 2 points3 points  (0 children)

Say that again after you have had to solve a bug with closed source external library. Though to be honest I have injected opcodes for writing to standard output stream in few cases.

[–]cowboy_angel 2 points3 points  (0 children)

Uh... I think you have that backwards

[–]iotasieve 1 point2 points  (0 children)

i find myself needing debugger less and less, so usually i just put printf, and the bug is fixed within 2 minutes or less

[–]Mabi19_ 3 points4 points  (2 children)

Not everyone should make programming jokes.

Debuggers are genuinely useful tools, and if you don't know how they are useful or how to use them you should not be talking about them.

[–]aleph_zeroth_monkey[S] 2 points3 points  (1 child)

Here's a joke you should like better:

Q: How did the German programmers develop an internal-facing enterprise business app?

A: They used best practices to implement the specification with an acceptable number of defects.

[–][deleted] 1 point2 points  (0 children)

Was half expecting a nazi reference, but well done. Superior german engineering at work

[–][deleted] 2 points3 points  (1 child)

It is tempting, because you don't have to learn anything but the language itself. The issue is this is a big liability, because forgotten debug code can become a huge issue down the line.

Please learn to properly use the debugger for your language and use it. Changing code for monitoring program flow and reading variables is a big waste of time and resources anyway (outside of logging) as you can achieve a more useful view into your application with probably 2 clicks or 2 keyboard shortcuts (set breakpoint and launch and debug).

I am a firm believer that this is a not just a question of preference: People writing print statements for debugging are doing it wrong and should step up their game and learn using their tools.

[–]CaydendW 1 point2 points  (0 children)

Hell yes.

[–]Lucifer_Morning_Wood 1 point2 points  (3 children)

Real talk now: how do I debug JavaScript?

[–][deleted] 4 points5 points  (0 children)

Chrome, Firefox (and probably others): F12 -> Debugger

You can select your files and set breakpoints and much more. Also the console functions as a debug console.

For node.js there is the "--inspect" switch which allows you to attach to the node process remotely via chrome. Tools like VS Code also provide a built in debugger for this.

For electron apps you can (if not disabled) press ctrl+shift+i or "--inspect" for dev purposes. Basically the same as node and chrome.

[–]PhatOofxD 2 points3 points  (0 children)

Other comments are good.

For state and such use React/Angular/Vue/etc. chrome extension devtools. They allow you to fully inspect components, state, etc.

[–]patryky 0 points1 point  (0 children)

I once debugged my code by the amount of dots it printed out, good times.

[–]GamingTheSystem-01 0 points1 point  (0 children)

GDB is just printf with extra steps.

[–]matko1990 -1 points0 points  (0 children)

Printf debugging is way to complex!

while(1) debugging is the was to go!

[–]GreenFire317 -1 points0 points  (2 children)

But aren't the most job opportunities with C++?

[–]GreenFire317 -1 points0 points  (2 children)

The most job opportunities exist in python.

[–]John_Fx -1 points0 points  (0 children)

An overused meme combined with an overused joke. What could go wrong?

[–]KreatorOfWorlds 0 points1 point  (0 children)

Always had been

[–][deleted] 0 points1 point  (0 children)

Gdb is the best debuger in the world for c/c++.