Re^3: Using the perl debugger to look at a renaming files function

Though I've never met Linus, I suspect retorting to him would be futile, given his parting shot was "Because I'm a bastard, and proud of it!". :) Update: It seems Linus is now a reformed character (from Organizational Culture (Part V): Behavior).

Based on the code you posted, I feel the most relevant quotes for you are from Pike, Martin, and especially Graham-Cumming:

I suspect that the same people who use debuggers all the time are the same people who don't unit test their code

and Conway:

fix the test suite first by adding tests that cause it to fail ... once the test suite is detecting the problem correctly, then you'll be able to tell when you've correctly fixed the actual bug, because the tests will once again fall silent

That is, with clean, well-designed code with unit tests there should be less need to fire up the debugger. I suggest you at least consider the option of replacing hours of never-ending crack-pipe debugging sessions with enjoyable creative hours of Test Driven Development.

Comment on Re^3: Using the perl debugger to look at a renaming files function

Replies are listed 'Best First'.
Re^4: Using the perl debugger to look at a renaming files function by haj (Vicar) on Feb 06, 2021 at 16:21 UTC
That is, with clean, well-designed code with unit tests there should be less need to fire up the debugger. I don't think there's ever a need to fire up the debugger. However, there are occasions where a debugger session might just be the fastest way to narrow down an error. Unit tests and the debugger are by no means an either-or decision. I occasionally work on code written by someone who has retired. Code which doesn't have unit tests and/or isn't well designed and/or hasn't been touched in a decade or so. I could, of course, just argue it's not maintainable (merlyn). But when I'm interested in the code, I'd rather spit into my hands and grab whatever tools might help. The quotes about tracing (merlyn) or stepping through a program (Brian Kernighan and Rob Pike) just miss the point about what debuggers can do. Personally, I'd rather use the debugger than print statements (Daniel Lemire) just because debugging sessions are transient (Brian Kernighan and Rob Pike). I don't want to spend time to format data structures for printing (the debugger does it for free), and I don't want to have to remove the print statements before committing. I agree with most of the quotes that you need to think before starting to debug. But I also think that you need to know the debugger to some extent to decide whether it is a good tool to tackle a problem or not. Learning the debugger is not a waste of time, and it is easier to get started with than e.g. Log::Log4perl or Test-driven development.	[reply]
Re^5: Using the perl debugger to look at a renaming files function (Remote Support) by eyepopslikeamosquito (Archbishop) on Feb 07, 2021 at 04:51 UTC
I don't think there's ever a need* to fire up the debugger* We support a large and complex product, running in many different countries, written in multiple languages, mostly C++. Whenever one of our executables crashes, our software automatically creates a crash dump file. When one of these crash dumps arrives in my in-box, I load it in the debugger (with matching symbols) to try to understand the root cause of the crash. Does that qualify as having a "need" to fire up the debugger? I might add that attaching a debugger to crash dumps is sometimes insufficient to solve the problem, for example when a program crashes because it attempts to access an object that has already been deleted ... which is why we also have a home-grown logging system (similar to Log::Log4perl) so we can see the history of events leading up to the crash. I agree with you that a debugger is just one tool among many, and will sometimes be the most effective tool for the job. The main reason I tried to curb the OP's enthusiasm for the debugger is because I looked at his code. I occasionally work on code written by someone who has retired. Code which doesn't have unit tests and/or isn't well designed and/or hasn't been touched in a decade or so. I could, of course, just argue it's not maintainable (merlyn). But when I'm interested in the code, I'd rather spit into my hands and grab whatever tools might help. Yes, I agree merlyn took an extreme position - perhaps he is one of the few programmers in the world who could challenge the Joel Spolsky wisdom "It's important to remember that when you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time". Or perhaps he was dealing with smallish systems. Rewriting crap from scratch quickly becomes untenable once you go past a million lines of code. BTW, I keep a list of references on the difficult topic of dealing with legacy code. Your liking of the transient nature of debugging sessions baffles me (I may have misunderstood your intent). After all, large successful software is written by teams, over many years ... so I feel it is our duty when faced with nasty debugging problems to make the code better and easier to maintain for our teammates and for those who maintain our code after we leave ... so throwing away the hard-earned insights from an individual's transient debugging session seems unprofessional to me. At a minimum, I would expect some judicious comments and logging that stay with the code.	[reply]
Re^6: Using the perl debugger to look at a renaming files function by haj (Vicar) on Feb 07, 2021 at 10:41 UTC
When one of these crash dumps arrives in my in-box, I load it in the debugger (with matching symbols) to try to understand the root cause of the crash. Does that qualify as having a "need" to fire up the debugger? Ok, so I need to make it clearer: I don't think there's ever a need to fire up the debugger to step through your code. Using a debugger to read a dump file is nothing which applies to the OP's use case and is not the point of the debugger criticism in the famous quotes. Your liking of the transient nature of debugging sessions baffles me (I may have misunderstood your intent). In my experience a debugging session rarely immediately spots the root cause of the problem. I am seeing symptoms, from where I go backward and try to figure out why some data are different than I expect. Often I'm looking at code I'm not familiar with. Occasionally I'm following a red herring. None of this is hard-earned insights: the debugger makes it very convenient. Whatever I learn from looking at the wrong places is nothing worth to keep for posterity. The make-the-code-better stuff starts when I've cornered the root cause, because only then I know what actually adds value to the code.	[reply]