http://www.perlmonks.org?node_id=1203761


in reply to Re: Modern Perl 4th Edition
in thread Modern Perl 4th Edition

This node falls below the community's threshold of quality. You may see it by logging in.

Replies are listed 'Best First'.
Re^3: Modern Perl 4th Edition (on Debuggers)
by eyepopslikeamosquito (Archbishop) on Nov 19, 2017 at 07:10 UTC

    There is no chapter about Perl ability to call C

    What I love about Modern Perl is that I can throw it at an accomplished programmer and they can "get" Perl really quickly. Because it is short. And well-written. And doesn't waste time on beginner stuff. So I personally applaud chromatic for focusing on the core language.

    Note that calling C from Perl (and vice versa) is covered in Extending and Embedding Perl (a 384 page book focusing just on that topic).

    There is no chapter about Perl debugger
    From one point of view, using tools -- such as a debugger, or profiler, or IDE, or refactoring browser, or static code analyser, or memory/cache/heap/thread checker, or code coverage analyser, or pod coverage analyser, or code formatter, or documentation generator, or ...) -- is not part of the language itself, and so has no place in a book focusing on that. Well, that is presumably the view taken by Modern Perl and The C++ Programming Language, for example.

    OTOH, Programming Perl (weighing in at 1176 pages!) does include a chapter on the Perl debugger. As does Mastering Perl.

    A few debugger quotes from some famous programmers:

    • merlyn : I'm not into debugging. I can't recall ever invoking the Perl debugger except to try out snippets of code at a prompt ... But never for debugging. (Larry is also like this, I'm told.) merlyn again : If the code the client throws at you needs a debugger to trace it through, I'd argue it's not maintainable.
    • Linus Torvalds : I do not condone single-stepping through code to find the bug ... Without a debugger you have to look at the level above sources. At the meaning of things. You have to understand what the program does. Not just that particular line. (See also: Linus Torvalds wikiquote).
    • Brian Kernighan and Rob Pike : As personal choice, we tend not to use debuggers beyond getting a stack trace or the value of a variable or two. One reason is that it is easy to get lost in details of complicated data structures and control flow; we find stepping through a program less productive than thinking harder and adding output statements and self-checking code at critical places. Clicking over statements takes longer than scanning the output of judiciously-placed displays. It takes less time to decide where to put print statements than to single-step to the critical section of code, even assuming we know where that is. More important, debugging statements stay with the program; debugging sessions are transient.
    • Rob Pike : Ken taught me that thinking before debugging is extremely important. If you dive into the bug, you tend to fix the local issue in the code, but if you think about the bug first, how the bug came to be, you often find and correct a higher-level problem in the code that will improve the design and prevent further bugs.
    • Uncle Bob Martin : Using a debugger is a code smell. I consider debuggers to be a drug -- an addiction. Programmers can get into the horrible habit of depending on the debugger instead of on their brain. IMHO a debugger is a tool of last resort.
    • John Graham-Cumming : For me, a debugger is (almost) always the wrong tool. And people who habitually use debuggers are making a big mistake, because they don't truly understand their code. I suspect that the same people who use debuggers all the time, are the same people who don't unit test their code.
    • Daniel Lemire. The author of Python, Guido van Rossum, has been quoted as saying that he uses print statements for 90% of his debugging.
    • Damian Conway urges you to add new test cases before you start debugging. After all, if the original test suite didn't report this bug, then that test suite was broken ... so 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.

    Update: Added some quotes from the famous programmers to indicate why they dislike debuggers.

Re^3: Modern Perl 4th Edition
by Your Mother (Archbishop) on Nov 19, 2017 at 03:42 UTC

    I'm also finding some of your review and critique bizarre and the reasoning as opaque as it is verbose. Good critiques are terse. Good writing is devoid of aphorism. Reviews should take a meta-view or risk becoming opinion editorial.

    As a 19 year user of Perl I could not possibly care less about Perls 1-4 except as they might relate to amusing stories from Wall and Co. As mentioned about other areas you found lacking, there are excellent books devoted to them already. No one is going to improve on Friedl's book(s) in regex for example.

    As a mostly self-taught programmer, and trained writer, I find chromatic's work above average, deeply helpful, and of great benefit to the community.

Re^3: Modern Perl 4th Edition
by chromatic (Archbishop) on Nov 20, 2017 at 02:44 UTC
    You tried to remove all, even existing, links to the lower levels of abstraction (for example, by choosing to cover Moose and avoiding old school "bolted on" Perl OO mechanisms).

    You may have had a bad download and read only half of the book; the "Blessed References" section is not only in the same chapter as the "Moose" section, but they're right next to each other. Furthermore, the "Moose" section includes discussions of polymorphism, attributes, method dispatch, roles, and inheritance which would have been covered anyway even if Moose hadn't been covered.