631

submitted 4 months ago by cows_are_underrated@feddit.org to c/programmer_humor@programming.dev

177 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[-] raspberriesareyummy@lemmy.world 1 points 4 months ago

I think you are not looking at the full picture - there are developments (arguably everything back-end) where a debugging system is absolutely not essential and in many cases (multithreading) outright useless for some types of bugs.

[-] firelizzard@programming.dev 3 points 4 months ago

Feel free to not use a debugger for your software. But I don’t hate myself so I’m going to stick to using one whenever possible.

[-] raspberriesareyummy@lemmy.world 3 points 4 months ago

Saying it is not essential and saying it is generally useless are two very different things.

[-] ThirdConsul@lemmy.zip 3 points 4 months ago

I believe that is a vast minority of developments. And tbh multithreading debugging is a breeze in C# on Rider (except race conditions, those will always be tricky, but also easily identifiable).

[-] raspberriesareyummy@lemmy.world 2 points 4 months ago

And I believe you are very wrong in that belief. However, a reliable statistic is not the first search result that I can find, so we'll have to disregard the disagreement on that point. You lost me at your C# multithreading reasoning though. A debugger will always interfere with the processes you are looking at, hence making debugging of multithreading-related errors a game of whack-a-mole.

[-] ThirdConsul@lemmy.zip 1 points 4 months ago

A debugger will always interfere with the processes you are looking at, hence making debugging of multithreading-related errors a game of whack-a-mole.

It's a very pleasant debugging experience when you can easily switch threads, have them log what happened first, check the variables in the thread at the moment in time it was hit (vs now), etc. etc.