You can take away my auto complete, performance monitoring and all that jazz but you can’t tell me a debugging system isn’t absolutely essential if you actually want to finish a project in a reasonable amount of time
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.
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).
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.
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.
I know this thread is old. But I disagree with you.
I agree that depending on how you use a debugger, some race conditions might not happen.
However, I don’t agree that debuggers are useless to fix race conditions.
I have a great example that happened to me to prove my point:
As I was using a debugger to fix a normal bug, another quite strange unknown bug happened. That other bug was indeed a race condition. I just never encountered it.
The issue was basically:
A request to initiate a session arrives
That request takes so long that the endpoint decides to shut down the session
A request to end the session arrives
And so handling the session start and session end at the same time resulted in a bug. It was more complicated than this (we do use mutexes) but it was along those lines.
We develop in a lab-like condition with fast networking and computers, so this issue cannot happen on its own. But due to the breakpoint I put in the session initiation function, I was able to observe it. But in a real world scenario it is something that may happen.
Not only that, I could reproduce the “incredibly rare” race condition 100% of the time. I just needed to place a breakpoint in the correct place and wait for some amount of time.
Could this be done without a debugger? Most of the time yes, just put a sleep call in there. Would I have found this issue without a debugger? Not at all.
An even better example:
Deadlocks.
How do you fix a deadlock? You run the program under a debugger and make the deadlock happen. You then look at which threads are waiting at a lock call and there’s your answer. It’s as simple as that.
How do you print-debug a deadlock? Put a log before and after each lock in the program and look at unpaired logs? Sounds like a terrible experience. Some programs have thousands of lock calls. And some do them at tens of times per second. Additionally, the time needed to print those logs changes the behaviour of the program itself and may make the deadlock harder to reproduce.
You are arguing against a strawman. Never have I said in this whole thread debuggers were useless. I made a point to say they are absolutely not essential, and for multithreading issues they can be detrimental.
You can take away my auto complete, performance monitoring and all that jazz but you can’t tell me a debugging system isn’t absolutely essential if you actually want to finish a project in a reasonable amount of time
Why debugger when print?
Embedded systems 😁
That’s what a single red LED is for, right?
Is the single red LED solid, or is it flashing Morse for “please kill me”?
Solid, always on. Whether the code runs or not, you know there’s an error in it so prepare to go through all of it again.
Because I don’t hate myself
javascript moment
It depends on what you do, but generally I can’t argue against a debugger.
gdb works great without an IDE, and many text editors have autocomplete.
Most text editors like vim/emacs/ect have ways of using a debugger.
I remember vim being a bit involved, but the performance was awesome.
But then if you put enough bells and whistles on text editors, do they become an ide?
Yes
9000 IQ programmer starts every project rolling their own debugger instead of dedicating 8GB of RAM to vscode
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.
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.
Saying it is not essential and saying it is generally useless are two very different things.
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).
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.
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.
Most concurrency problems disappear at the pace of a debugger.
I know this thread is old. But I disagree with you.
I agree that depending on how you use a debugger, some race conditions might not happen.
However, I don’t agree that debuggers are useless to fix race conditions.
I have a great example that happened to me to prove my point:
As I was using a debugger to fix a normal bug, another quite strange unknown bug happened. That other bug was indeed a race condition. I just never encountered it.
The issue was basically:
And so handling the session start and session end at the same time resulted in a bug. It was more complicated than this (we do use mutexes) but it was along those lines.
We develop in a lab-like condition with fast networking and computers, so this issue cannot happen on its own. But due to the breakpoint I put in the session initiation function, I was able to observe it. But in a real world scenario it is something that may happen.
Not only that, I could reproduce the “incredibly rare” race condition 100% of the time. I just needed to place a breakpoint in the correct place and wait for some amount of time.
Could this be done without a debugger? Most of the time yes, just put a sleep call in there. Would I have found this issue without a debugger? Not at all.
An even better example:
Deadlocks.
How do you fix a deadlock? You run the program under a debugger and make the deadlock happen. You then look at which threads are waiting at a lock call and there’s your answer. It’s as simple as that.
How do you print-debug a deadlock? Put a log before and after each lock in the program and look at unpaired logs? Sounds like a terrible experience. Some programs have thousands of lock calls. And some do them at tens of times per second. Additionally, the time needed to print those logs changes the behaviour of the program itself and may make the deadlock harder to reproduce.
You are arguing against a strawman. Never have I said in this whole thread debuggers were useless. I made a point to say they are absolutely not essential, and for multithreading issues they can be detrimental.