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.
BTW, the list of famous programmers who dislike debuggers (or at least the time wasted in crack pipe debugging sessions) includes:
- Larry Wall
- Guido van Rossum
- Randal L. Schwartz (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.)
- 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.)
Update: Added some quotes from the famous programmers to indicate why they dislike debuggers.