Perl Debuggedby Peter Scott
The 2001 classic - available in eBook formats for the first time
Perl Debugged provides the expertise and solutions developers require for coding better, faster, and more reliably in Perl. Focusing on debugging, the most vexing aspect of programming in Perl, this example-rich reference and how-to guide minimizes development, troubleshooting/i>/b>/b>… See more details below
The 2001 classic - available in eBook formats for the first time
Perl Debugged provides the expertise and solutions developers require for coding better, faster, and more reliably in Perl. Focusing on debugging, the most vexing aspect of programming in Perl, this example-rich reference and how-to guide minimizes development, troubleshooting, and maintenance time resulting in the creation of elegant and error-free Perl code.
Designed for the novice to intermediate software developer, Perl Debugged will save the programmer time and frustration in debugging Perl programs. Based on the authors’ extensive experience with the language, this book guides developers through the entire programming process, tackling the benefits, plights, and pitfalls of Perl programming. Beginning with a guided tour of the Perl documentation, the book progresses to debugging, testing, and performance issues, and also devotes a chapter to CGI programming in Perl. Throughout the book, the authors espouse defensible paradigms for improving the accuracy and performance of Perl code. In addition, Perl Debugged includes Scott and Wright’s "Perls of Wisdom" which summarize key ideas from each of the chapters, and an appendix containing a comprehensive listing of Perl debugger commands.
In this exceptional reference and debugging guide, the authors cover every aspect of efficient Perl programming, including:
- CGI programming—special tips for debugging this type of Perl program
- How to develop the proper mindset for developing and programming effectively in Perl
- Perl "gotchas"—how to understand them, work around them, and avoid them
- "Antibugging"—the authors’ rules of thumb on how to code defensively
- The Perl debugger —the authors’ guide to using this Perl built-in
- Common syntax errors and how to track down their causes
- Semantical errors—why code may appear correct but the programs do not work
- How to improve the performance of resource-hungry programs
- Tips and advice for programmers moving to Perl from other language environments
Focusing on the process of Perl programming and guidelines for identifying and correcting mistakes, Perl Debugged helps the developer to write better Perl programs immediately and become better programmers in general.
- Pearson Education
- Publication date:
- Sold by:
- Barnes & Noble
- NOOK Book
- File size:
- 9 MB
Meet the Author
Ed Wright is a Software Engineer at the Jet Propulsion Laboratory. He holds a Master of Science degree in Engineering Mechanics and Astronautics from the University of Wisconsin at Madison, a Master of Science in Physics from the University of Louisville and a Bachelor of Science in Mathematics from Auburn University. He currently leads the JPL Perl Users Group.
Peter J. Scott runs Pacific System Design Technologies, providing Perl training, application development, and enterprise systems analysis. He was a speaker on the 2002 Perl Whirl cruise and at YAPC::Canada, and he founded his local Perl Monger group. A software developer since 1981 and a Perl developer since 1992, he has also created programs for NASA¿s Jet Propulsion Laboratory. Scott graduated from Cambridge University, England, with a Master of Arts Degree in Computer Science and now lives in the Pacific Northwest. He is the lead author of Perl Debugged.
More from this Author
Read an Excerpt
Chapter 1: Introduction
Unfortunately for the programming world (and programmers), software development continues after a project is declared finished (an increasingly arbitrary-and often inaccuratelabel). Maintenance and debugging may consume more time than the original coding, particularly because the person responsible for a program's maintenance may not be one of the original programmers. This means we spend a lot of our time trying to deduce the specifics of some algorithm we find in the code: how it was done, why it was done, and why it doesn't work any more l
The odds of creating a bug-free program are rather long. Anything larger than the ubiquitous Hello World program is fair game for bugs. No recipe exists that, if followed, eliminates the possibility of bugs, but some practical rules have been developed:
1. Reduce the places where a bug may be introduced. This means incorporating modular design, encapsulation, and unit testing.
2. Identify the bug's pathology. Play detective: what shouldn't happen but does, or does happen but shouldn't?
3. Isolate the bug's locationwhere do things go south? (This is the reason for the invention of debuggers.)
4. Determine the conditions that cause the bug. What activates it? Why haven't you found it before?
5. Correct the bugand always retest altered code.
6. How did the bug get in there in the first place? If you made a typo and caught it 5 minutes later on a unit test, that's one thing. If the bug was caused by a logic error and survived to release, 1.2 Why Perl?
Chances are, if you use Perl you know why you picked it and don't need further proselytizing. But additional ammunition never hurts-if you have to defend Perl up your management chain, well, Perl doesn't have a megamultinational conglomerate to pour zillions of dollars into a marketing campaign 2 so it falls to users like us to sing its praises in practical ways.
Whenever we have a problem we need to solve with a program, the solution first shows up in our mind, in thought pictures and words, which most development methodologies then have us enunciate as an English (or whatever our native language is) description of an algorithm before ever translating it into code. If the algorithm description were complete and unambiguous, it could be executed by a computer if the computer could understand our phraseology.3 But no parser yet exists for free-form English algorithm descriptions, so we translate the description into some language a machine can comprehend.
Therein lies the rub: an ideal computer language imposes zero overhead on the programmer during implemention of the description. Such a thing doesn't exist, so we want the language that minimizes the overhead. This can vary from task to task-if you're writing a device driver, your best choice is quite likely to remain assembler. If you're writing a graphical user interface, at least part of the problem is probably best attacked with a WYSIWYG editor that creates a layout specification.
When writing a program, you're conscious of its overhead every time you create a requirement on code solely to satisfy the demands of the language but not the problem. For example, in writing C and C++ programs, a frequent example of this is how to allocate memory for dynamic data structures and where and when to give it up.
Perl imposes on the programmer the smallest overhead of any language we have used for the vast majority of problems we have had to solve. At the expense of little learning, we are able to create very short programs in an incredibly brief time to solve complex problems. Because the language overhead is small, changes in requirements don't force changes in large unrelated sections of the code since a much more natural mapping from the English description of the solution to the Perl version exists. And because the Perl expression of the solution is so succinct, a reader can encompass more of it at a glance.
In fact, in many respects, Perl resembles English in its ability to resolve ambiguities favorably, its intuitive and orthogonal interfaces, and even how it sounds when read out loud. Larry Wall, Perl's creator, often states how his background in linguistics led him to consciously draw such parallels. 5 Perl cognoscenti refer to this collective phenomenon as Perl's DWIM (Do What I Mean) behavior...
and post it to your social network
Most Helpful Customer Reviews
See all customer reviews >