in reply to My Perl journey begins

Back when I was doing Delphi, I vowed I would never use another language without an integrated debugger. But then I started web development (in Java and C++ actually) and realized that an integrated debugger isn't worth setting up when you're trying to debug incoming web requests. It can be done, but the hassle outweighs the benefit. So I got used to logging. And... logging can be so much better! If you have really good logging (as in, only logging the points of interest and variables of interest, and configurable log levels) on a complex algorithm, you can actually read the log faster than stepping through hundreds of method calls, or walking backward through massive data structures to figure out where the algorithm went wrong. This even carries over to JavaScript, where I've had times that the console.log was more useful than the built-in debugger. Especially when the file has been minified.

I've gotten the most use out of Log::Any. I wrote my own minimalist adapter for it Log::Any::Adapter::Daemontools which can change the log level on the fly in response to SIGUSR1 and SIGUSR2. And then I have written in-house Plack middleware that can change the log level depending on a browser cookie. (I might get that published some day) The end result is that I can set that secret cookie on my browser and then perform actions on the production system and see the full trace output even while other users are hitting the same server and generating minimal log output. (The log output stays in the server logs, so there isn't any security risk in this cookie as there would be if it pushed the logs to the browser.)

The other thing Perl has that kills the need for a debugger is nice easy unit testing. See Test::More or Test2. If you structure your program as a collection of small mostly-independent modules, you can wrap each of them with unit tests and work out all the bugs before you assemble them into anything complicated. It's amazing how few bugs I end up having in the main program if I've fully tested each of the components first. And there's always "perl -d" for debugging the unit tests, if the log wasn't enough.

Replies are listed 'Best First'.
Re^2: My Perl journey begins
by LanX (Saint) on Aug 19, 2022 at 21:54 UTC
    I second your sentiment about print/log debugging plus testing.

    For me personally is the debugger only helpful when dealing with badly documented foreign code, to figure out WHERE and HOW things happen, not necessarily what goes WRONG.

    I.e. tests and logging are missing, and I can't figure out the flow by looking at the code.

    (I also use the Perl-debugger as kind-of REPL to test code snippets, but that's not debugging)

    To my chagrin are most of my colleagues trained from early on to develop with the debugger, because our tool of choice - Komodo - makes it very easy to set a breakpoint at the fringe of the actual code and step thru and see watch expressions.

    Furthermore is F5 set to run inside the debugger, it's F6 for an independent run.

    It's so interwoven, that they don't even know how to use perl -d and its commands. The keep talking about "Komodo's debugger", literally as if Active-State hacked an independent solution.

    This, plus continuous automatic perl -c in the background with underlining of compilation errors (mostly forgotten my declarations) leads to a kind of "try and error" programming mentality.

    Before I started for that client, newbies were told to copy-paste a "working" script and adapt it to their needs, Komodo would just help them underlining problems and help "debugging".

    It's quite hard to convince them that the proactive use of test-suites and logging leads to better results.

    It's basically a question of return of investment...

    Cheers Rolf
    (addicted to the Perl Programming Language :)
    Wikisyntax for the Monastery

[reply]
[d/l]
[select]

In Section Meditations