Modern Perl 4th Edition
Use the Amazon App to scan ISBNs and compare prices.
Enter your mobile number or email address below and we'll send you a link to download the free Kindle App. Then you can start reading Kindle books on your smartphone, tablet, or computer - no Kindle device required.
To get the free app, enter your mobile phone number.
Frequently bought together
Customers who bought this item also bought
From the Publisher
Five Things Perl (Still) Gets Right by chromatic
In the late ’90s, I switched from Java to Perl because Perl made things easier. Perl let me get things done. Almost 20 years later, Perl still has a special place in my toolbox. I keep using it for certain projects because it still does some things so very well.
I can get many of these features from a lot of languages and platforms, and that’s great. Yet the combination available from Perl and its ecosystem keeps me coming back to the language.
The first serious program I wrote in Perl was a statistical analysis of random number sequences. It was last modified on February 26, 2003 and still runs, untouched. This program isn’t unique in its longevity. Most programs written to run even for Perl 3 or 4 will run today on Perl 5.22. In the 8 major and 38 minor stable releases of Perl since 2000, nearly any program written will run without modification. The expectation of compatibility guides people to keep existing code working.
Perl has a standard test suite that’s expected to pass on every platform with every commit. It has monthly unstable releases so that intrepid volunteer testers can test the CPAN--Perl’s large library of freely reusable third-party code--against the latest development versions.
A project called 'Bleadperl Breaks CPAN' bisect commits to Perl itself to find out exactly which change breaks which modules when something goes wrong. In practice, it’s possible to update an application to run on the newest release of Perl the day it’s released with no changes to your code. Just install the new version, install your module dependencies, and go.
Writing documentation as a programmer is like flossing: everyone knows they should do it, but most of us don’t do it often enough. Yet Perl’s documentation standard has set a bar that few other projects I’ve seen have ever matched. Perl set this standard early; it includes voluminous documentation of the language, core libraries, and even its expected documentation format. CPAN modules have a well-established standard for documentation, including running code you can often copy and paste and modify into your own programs.
One of Larry Wall’s early design goals was to fill the gap between one-off shell scripts and serious programs written in C. I like to think he took the ease of prototyping and low ceremony of shell scripting and combined it with the full power of Unix available from C.
If you plotted the sizes of all the programs I’ve written in the past couple of decades, you’d see a wide range: lots of one-liners, countless Unix filter scripts, and larger programs of tens of thousands or hundreds of thousands of lines. That’s not by accident; scalability of programmer effort is a deliberate goal of Perl that’s pervasive through much of the CPAN as well.
Perl’s been available on every professional system I’ve used in recent memory. It was quicker and easier to write a simple log parser in Perl on a new work laptop than to make sure I had all the development dependencies installed to install the correct other language dependencies to use the libraries I’d need there. (Though to be fair, I’m really good at writing simple log parsers after decades of Unix experience.)
Going from “I have a fresh account on a new machine” to “I can use Spreadsheet::WriteExcel to fill in the gaps of an existing spreadsheet just uploaded by a user” is easy--in part because I know all the pieces, but in part because I have confidence that they’re stable, well-tested, work together, and are available not just on my new laptop but on my server. I appreciate that Perl works and continues to work.
About the Author
Since 1998, chromatic has helped kick off the Perl testing revolution; contributed to the PerlMonks community from its origins; and wrote, edited, and reviewed many books and articles. He's contributed to Perl's current release structure, as well as Moose, Catalyst, Mojolicious, and p5p. He first released Modern Perl to the community in 2010.
There was a problem filtering reviews right now. Please try again later.
Perl and I used to have so much fun together. Back in the day (2000-2010), Perl was my right hand man. I used C/C++ and SQL to write project code, and Perl to analyze, automate, simulate, emulate, innovate, prototype, test, and generally blast obstacles out of the way. Some of my colleagues and managers were frightened of Perl - it was voodoo as far as they were concerned. A manager who clearly didn't get it chided me for bringing this Unix thing into his cozy little Windows shop, "Why would you use this Perl thing when you have Visual Basic available to you?" Yes, such a question can make one wince. However, Perl got results, quickly, and Perl culture was a blast.
I switched jobs, and found PowerShell had become the socially-acceptable scripting language for the Windows side, Python was the lingua franca for the Linux side, and Ruby was de rigeur for Chef for both sides. Absent a role, my old friend faded from view. Such is life in DevOps.
As it turns out, my old friend is now even more muscular, and still quite the party animal. However, this book shows that Perl has gotten some nice new features.
To be quite clear - this is NOT a book to use to learn Perl. Stick with the Llama book for that. This book assumes that you are using it to get reacquainted, and it succeeds wonderfully at that.
"Modern Perl" is phrase used to describe a style of Perl programming that uses modern tools and techniques to develop better Perl programs. Modern Perl the book is an excellent introduction to the ideas, tools, language and community of the "Modern Perl" way. Author chromatic draws on his expertise to deliver an opinionated and reasoned guide which is ideal for programmers new to Perl or returning after a hiatus. Terse and fast-moving, Modern Perl doesn't baby the reader and may not be ideal for absolute programming beginners. This edition from The Pragmatic Bookshelf is beautifully typeset and styled - I highly recommend it.
Review Synopsis: Suffers from overcomplexity
It is very difficult or impossible to write a good book on Perl, because it is such a large and complex scripting language with various application domains. Also Perl is a very large language. Chromatic managed to do an excellent job in this respect covering all the language with its modern enhancements in relatively small book. Of course, you can't provide a lot of details for each feature in 300 pages, but he managed to cover most major areas important for programmers. This is what determined my rating of the book.
But such approach is not without problems. While the book is a usable reference (it's intended purpose) that covered almost all the most recent Perl enhancements and new features up to Perl 5.14 it is not suited for studying Perl language (this is not a drawback as intended purpose of the book is to be a language reference).
Still it might be beneficial to any seasoned Perl programmer who wish to update his knowledge of latest and greatest language features.
For those purposes most material that is covered is covered well, with the distinct approach that "newer is better". I did not found any new feature that chromatic did not like :-). For beginners old Simon Cozen's book(2000) might be better for studying the "basic" subset of the Perl language and can (and probably should) be used along with this book to see what changed in the language in 17 years since its publishing.
Again, if you use this book as the only book to learn programming in Perl. It's a bad book for this purpose. Clearly it is a "language junkie" written book. which is fine for reference, but bad for learning the language. It does not distinguish between important and superficial/esoteric things in the language. Everything is, kind of, "treated equally" independent of complexity and the level of abstraction that a particular feature introduces: Ohh we have this great feature. Here it is ;-) This "Schwartzian" approach is a very bad idea for beginners, even if they know some other language really well. And not so good for accomplished programmers either, although they suffer less from it and can benefit from delving into most recent esoteric staff (sometimes :-). All-in-all the book suffers from "over-complexity for the sake of over-complexity" approach to Perl. Which was typical for O'Reilly books, but which I do not support or approve.
I also noticed two rather obvious problems with the book:
(1) Looks like it does not cover Perl debugger. At all, as if it does not exists.
(2) It does not contains adequate coverage of built-in functions such as index (mentioned only in passing in index), substr (not in the index), tr, to name a few.
Also regex searching on long strings with newlines is an important topic (modifiers s and m) for modern Perl usage, coverage of which can be improved and expanded. This is a pretty minor point but it is important for me.
As for advocacy of Moose, this was a very questionable decision on the part of the author. Many organizations prohibit installation of SPAN modules for security reasons. In such cases you need to deal with modules included in the Perl distribution that comes with OS, or jump through the hoops to get permission for "non-core" modules. Also quality of modules on CPAN varies greatly, many are unmaintained for years. Blank recommendation to use CPAN is a dangerous proposition.
Perl 5 now is the language that most people use in rather limited subsets, the idea which is completely missing from the book. Nobody probably knows or uses the "full Perl language". It is the classic situation with blind men and elephant. It is also true about other languages such as Python and Ruby.
Even using a very limited subset of Perl can be somewhat problematic as there are way too many special cases and gotchas. This is clearly non-orthogonal language and this has its strong and weak sides. How to avoid problem that arise from this is the topic that is very important for Perl programmers. Aside from advocating to put "use strict" and "use warnings" at the top of your script there are other relevant methods, such as switching to IDE usage, that are also missing from the book. For example, Padre or Pycharm can be used (Pycharm does support Perl, although this is not advertised).
Any language is not just the language, but is the whole ecosystem which includes among other things the debugger and IDE.
Please note that it does not make sense to adopt "Pythonista" approach to the same domain either, as it stands father from the spirit of "Classic Unix" than Perl to say nothing about related unhealthy infatuation with OO that Python promotes. OO actually is a pretty limited paradigm of programming suitable only in few (but important) areas; historically it came from languages oriented on simulation (Simula67), which is an important, but not all-encompassing domain; later it acquired some features of "compiler-complier" approach.
But other approaches also exist. For example, coroutines can also can be viewed as a software development paradigm for certain type of programs (that allows structuring the problem into multiple semi-independent passes with intermediate representation produced in each) and I am not sure that it is not better approach for certain types of programs. Melvin Conway (famous for Conway law: "organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations.") initially proposed this paradigm for the construction of the compiler. Success of Unix pipes speaks volumes about power of this approach.
Aside from overcomplexity, another problem with the book is that it presents Perl as unified "one-dimensional" language. In reality Perl exists at least on three distinct levels:
1. Minimal Perl. Perl 4 subset of Perl 5 -- which surprisingly is adequate for many tasks; especially in Unix system administration area. This is the level of the language typically used in one-liners, small Unix-maintenance scripts, and such. This is a kind of "Perl as better bash, AWK and sed." level.
2. Basic Perl 5 -- Perl 5 with modules and references, but without fancy staff (like closures, OO, exceptions). This probably the mostly widely used subset.
3. Enhanced Perl 5 -- Perl feature level typical for people who speak at Perl conferences. That include OO, polymorphism, inheritance and other complex staff that is useful for example for writing interactive program with complex GUI and such.
I think that any book that presents Perl only on level 3 (which is the case with this book) without mentioning of possibility of using Perl on levels 1 and 2, suffers from overcomplexity. I think a proper book on Perl should be like an onion with at least three layers of coverage outlined above. Of course, such a book is very difficult to write.