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.
| [reply] |
Damian Conway gives some excellent Debugging advice
in Ten Essential Development Practices namely:
Add New Test Cases Before You Start Debugging
The first step in any debugging process is to isolate the incorrect behaviour of the system,
by producing the shortest demonstration of it that you reasonably can.
Once you have distilled a short working example of the bug, convert it to a series of tests.
Don't try to fix the problem straight away, though. Instead, immediately add those tests to your test suite.
The point is: if the original test suite didn't report this bug, then that test suite was broken.
It simply didn't do its job (finding bugs) adequately. 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.
The more thoroughly you test the bug, the more completely you will fix it.
External Debugger References
Perl Monks Debugger Nodes
| [reply] |
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.
| [reply] |
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.
| [reply] |