Modern Perl Programming

This took longer than it should have, but the electronic reader editions of Modern Perl: 2014 Edition are available. The letter and A4 PDFs have been available for a while, but we're satisfied with the formatting of the ePub and Mobi (Kindle) versions, so they're now ready for download and redistribution.

You can still, of course, buy the print edition of Modern Perl online. You'll get the Kindle edition from Amazon for free there, if you like. If you've already purchased a Kindle edition, it should update for you automatically.

It'll take a couple of days for Amazon to approve the new Kindle edition.

Please share with your friends, coworkers, and anyone who ought to learn how Perl really works and how to write Perl well in 2014.

(It wouldn't hurt my feelings if you shared a link to that page, though it also wouldn't hurt my feelings if you shared with everyone you know Trendshare's how to invest guide either.)

With great pleasure do I announce Modern Perl: 2014 edition is out and available in stores. You can also read Modern Perl: 2014 edition free online. Of course it's available from the various booksellers:

Modern Perl at Powell's
Modern Perl at B&N
Modern Perl at Amazon

PDFs and other electronic versions are available on the Onyx Neon Modern Perl book page now. The Kindle edition will update soon.

Please spread the word far and wide.

HN tl;dr: innovation in the 2010s means getting your anonymized social network for marmots acquired so that big SV can put ads on it or datamine your users

proggit tl;dr: you should have spent your time learning how to write a CRUD app and a mediocre template system, dependency injection framework, and ORM in Haskell Rails Erlang Scala Rails Python Node Clojure Julia instead of mastering one tool and learning how to solve problems.

It Begins

I shut down my music career in 1998. "Career" is too generous a word. I'd made money as a musician, but not enough to call myself a professional and certainly not enough to pay the rent and buy food. I talked my way into the Color LaserJet group at HP.

I wrote some code for the printer group, just because I could. I had a little AWT app (even though Swing had just come out, it wouldn't run on Linux for quite a while) for customer support techs to record data about customer problems. Then the networking group asked me to write a program to email customers whenever the web site had a new technical article published. The ten line shell script (written in whatever HP-UX 9.x supported out of the box) was orders of magnitude less than the Java version I could never convince myself to finish.

When I realized that I enjoyed playing with HP-UX and the Linux box under my desk far more than I appreciated learning all of the ways that paper could jam or PostScript drivers could render things wrong, I switched to system administration. (Programming was in a different state altogether, and my music degree hardly compared to the CS degree they wanted.)

After fighting fires for three months and automating away the remaining problems, I had a lot of time on my hands. The web was suddenly very interesting. mod_perl had just come out and applets were obviously not working. I picked up Perl.

I started a couple of small free software projects on my own. They never went anywhere. (Everyone used to write a template system in those days. Then I found the source code to Everything 2's predecessor, sent in a couple of patches, and (after Carly Fiorina decided to save money by not paying system administrators) eventually started working for the dot com that produced Perl Monks and promptly imploded.

Then I wrote a book. It had a cool cover but you probably didn't read it. (It was only the first book in English about blogging, but the title was wrong anyhow. This was the last gasp of the first dot com era, when everything seemed like a good idea in a certain context, almost including the TSA.)

Writing a book is equal parts frantic research and tedium, and in the first of many moves designed to convince myself that my actions had a positive effect on a cruel and uncaring universe, I took up Michael Schwern's call to unify the internals of Test::Simple and Test::More. The result is Test::Builder.

This was a revolution for everyone on the perl-qa list and it was a revolution for Perl in general, but it's the kind of revolution that you look back on now and think "Wow, that was obvious!" and "That was a revolution?" because it seems like such widespread common sense, like "It's good to drink water!" and "Maybe smoking has deleterious health effects."

It was a revolution in that it let a thousand blossoms of test modules bloom (so people could solve their own specific testing problems and share those solutions) while providing the soil in which all of those blossoms could bloom (so they all worked together with almost no effort on the module writer's part). This is an important principle of API design: handle the difficult, tedious, and tricky parts at the low levels so that everyone gets that right while not ruling out people doing their own things at higher levels. If that makes you think of layering, you're right.

I did some consulting work for a while, based on the strength of my free software work with Perl. (Making a name for yourself answering questions on a site does help get your name in the community and build some networking connections. Getting a patch or two in a dominant project helps as well.)

Then my career took a lurch sideways, and I spent some time as an editor concentrating on free software and technology.

Free Software as a Hobby

It was important to keep my programming skills fresh, so I increased the amount of time spent contributing to free software projects (in and around writing books). Parrot sucked up a lot of my efforts.

(More than one Parrot/Rakudo/P6 developer said to me in separate conversations as far back as 2007 that "Sure, it's a long slog now and no one's getting compensated much for it, but when it's done in the next 18 months, there'll be a lot of interest in books/training/consulting, and we'll be in a good position then!")

This was a rough time to be in Perl. Having helped push the Ruby snowball back down the hill with Rolling with Ruby on Rails (just over nine years ago now!) and with Perl stuck on 5.8 for another almost three years, the hope was still that a new major version would turn the language's fortunes around. Meanwhile, the testing culture had infected the core language as well as the CPAN like an unseen brigade of healthy gut fauna (don't leave the dinner table without it). There was growth and roots and foundations, but the effects would take some time.

Pugs helped, but Pugs has been a historical curiosity for a long time now.

The Resurgence of Perl that Nobody Noticed

While the world stopped waiting for a new major version of Perl, Perl 5 came out with several new major versions and the CPAN continued to be the reason that I stuck with Perl. I'm not alone in this. Moose is probably the singular reason there are any significant new projects in Perl in 2014. This by no means should take credit away from other projects such as DBIx::Class, Mojolicious, Catalyst, and other projects well worth mentioning, but Moose was a revolution in the noisy, flashy, overthrow the dominant paradigm sense. It was Fidel to the rest of the CPAN's Che—the one that gets the credit, unless you're some sort of weird countercultural rebel who likes giving oligopolic corporations money to wear t-shirts with your icon's image on them. (That metaphor rode away from my point on a motorcycle tour of South America. Sorry.)

That revolution needed a name.

Modern Perl

JavaScript had its resurgence, going from "that awful language that everyone has to use and nobody likes" to "Sure, if you squint hard enough and ignore all of this awfulness over here and are very very disciplined, you can write code that's not too bad". (If that apologia sounds familiar and you feel bitter, keep in mind that, unlike Perl, you have no choice whether to use JavaScript on the client side.)

I figured this was a great time to leave the increasingly depressing world of corporate technical book publishing to work on my own technical book publisher, because it didn't cost us tens of thousands of dollars to get the first copy out the door. While it's nice that the revenue we make on a book like Modern Perl, it's still a lot better to think of writing or publishing a book as "a hobby that'll buy you nice dinners here and there" instead of "I will never have to work again, unless you count sleeping on a pile of gold coins to be work".

Book publishing is driven by the semi-random lightning strikes of big hits, and you have to be in the right place at the right time. Like a poker player, you need to know when to go all in—and, more important, you need to know when to get out. This is one of the reasons the tech book publishing market is so awful. Ruby and Rails were the hottest things since JSP in 2005 and 2006, but the market had reached its peak of sales in 2007 even as publishers were still pumping out the kind of ancillary books around Rails that they'd pumped out around Perl in 1998, 1999, 2000, and 2001 even as talking puppets, razorfish, and drones delivering fresh vegetables even before you one-click order them had become a bubble about to pop, taking with it countless jobs and lots of paper money in an inflated stock market. (Maybe that's what you should expect from hiring a member of an adolescent power fantasy fiction cult to manage the world's largest economy, but keep in mind music degree not economics degree and everything's more obvious in retrospect.)

That's one reason why there hasn't been a Modern Perl Testing book; I can't convince myself to give up increasingly valuable weekends and evenings when there are other things I could do which are either much more relaxing (spending time with friends and family), much healthier (cooking, exercising), or profitable (investing). At some point, there might be a Programming Rust book, if only because I find Rust fascinating for what it both does and doesn't do. I wish I'd had it ten years ago for Parrot.

With that said, writing and publishing Modern Perl was a good thing. Giving it away for free was a good thing. Maybe I would have made as much revenue if I'd spent the same amount of time slinging milkshakes at the local SBUX, but I'm more satisfied about the social good done by giving away PDFs and hosting a web site than I am about most anything else done in my career. (Perhaps Test::Builder has been more influential from a code standpoint, but once I start going down that line of thought, I feel a complex insert-lengthy-German-compound-philosophical-term-here emotion about those large projects I worked on which seemed influential and important at the time and haven't actually gone anywhere.)

At worst, Modern Perl gave Perl as practiced by its best programmers in the 2010s a concrete name. At best, it helped existing Perl programmers and hopefully some new ones avoid some of the worst parts and adopt some of the best parts.

Golden Handcuffs For a Very Modern Perl Consultant

With a brief foray into running my own non-publishing businesses (hey, if you want to give this free investing articles for novices a link somewhere, that'd be great) revealing that starting a business from nothing is very, very difficult.

This, I think, is one reason why so many small consultancies are consultancies and never manage to turn their brilliant ideas into shipping products because it's too lucrative to chase consulting dollars and too difficult to invest in products which may not pay off. This isn't the first time I ran into this, either. If my first job after the dot com crash had succeeded in producing its product, it would have owned a lucrative vertical market. Unfortunately, consulting dollars ran out before it could finish a proof of concept to jumpstart presales. (Of course, the investors also wanted to rewrite the Perl backend and the Python/Wx client application in Java, in 2002, to run on point of sale systems for small businesses, in 2002.)

When consulting is good, it can be lucrative and that lucre can be tempting. Consultants have to charge a rate far in excess of a normal hourly salary because there's overhead: you may have a lot of spare time between contracts, you don't get PTO or benefits you don't pay for yourself, and you have to negotiate contracts and pursue work which may or may not materialize.

If you find a good client, you treat him or her like a combination of the Pope, the Queen, and the Dalai Lama, because a trustworthy client who pays you on time and doesn't argue over little details of the contract is better than gold.

Yet suppose you budget for eight or nine months of steady work and luck into a contract that gives you twice that. Some people deal well with that boom and bust. Others don't. (For me, the mechanics of budgeting are easy but the psychology of riding the business cycle is difficult.) It's difficult to look at other opportunities with an objective eye because when the contract is great, that money looks very nice and it represents a lot of freedom, but when the contracts are awful or far between, the stability of a salaried job represents a lot of security.

Finding a Perl Job

Am I a Perl programmer?

If you look at my résumé, I've been fortunate (in one sense) to have spent the past 16 years working with Perl at a deep level on many, many projects in many jobs in many domains. I've also made money working with Python, SQL, shell, Ruby, C, C++, JavaScript, assembly, Java, SQL, PL/pgSQL, Visual Basic, PHP, LaTeX, and I'm sure I left out at least one or two.

As a professional programmer with an interest in my professional development and someone who is physiologically unable not to program occasionally outside of 9-5, I've dabbled in other technologies—not enough to call myself an expert the way I call myself a Perl expert—but enough that I don't completely embarrass myself in conversation about them. (Chuck Moore once tried to convince me of the value of writing my own operating system. I have an MP3 of this.)

Yet on my CV, one technology keeps coming up again and again. Perl

It's no secret that that's where I've spent most of my time. Look, I like the language. I'm used to its flaws (even though a couple of hundred entries on this site will reveal that I don't like all of them) and I know how to play to its strengths. I like its community (people like Tim Bunce and Rik Signes and Andreas Koenig and Tatsuhiko Miyagawa are, frankly, irreplaceable elsewhere). I'm exceedingly productive with Perl in a way that would take me a while to get productive in other languages. That's what you get from a decade and a half of experience. That's what you get from at least 20,000 hours of practice.

But Did You Learn to Program?

You tell me. I can give you references who will speak of me in positive terms. I can refer to to people who will tell you I helped solve problems or helped teach them something or helped them think about their problems in better ways.

(You'll also find people who will say I can be sarcastic and moody and bitter, and for better or worse you're reading this, so why pretend?)

This is the important question that a CV can't answer. This is an important question that rifling through the small subset of my professional work that's on Github or the CPAN won't tell you. They won't tell you about all of the mistakes I made that you don't see, if they exist. They won't tell you about all of the thrashing around that I did or didn't do which Git let me squash out of existence. They won't tell you if I churned out 1400 lines of code one afternoon in a marathon coding session and it compiled on my second try and hasn't been touched since, because it just works and no one needs to touch it.

Then again, asking me to write a sorting algorithm on a whiteboard won't tell you much either beyond "Does this person actually seem like he knows how to program at all?" and that's still a thing in interviews.

You can't look at a CV and tell whether I'm the kind of person who will go above and beyond the task of transcribing what a software architect dictates that the project manager has teased out of what the director of sales has forced the enterprise sales representative to admit that he promised to the customer for the next release. (I can tell you that I would find that environment frustrating.) You can't predict only from a page and a half whether I have an enthusiasm for writing the best darn medical insurance billing code ever or whether that enthusiasm will translate into an attempt to delight users even if they never think about all of the bugs and frustrations that we squashed and eliminated before they escaped to production.

You can't tell that by reading Perl or Ruby or PostgreSQL on my résumé. You can't even tell that by reading my code. That's the risk you take in hiring someone, but isn't that at least as important as answering the question "Can you make a decent attempt to write something resembling code on a whiteboard, even though your muscle memory has been tuned over several years for Vim, because you're ostensibly a professional who cares about tools and automation and making it easy to do the easy work of typing?" or the question "How well do you fit with our team?"

But Where are the Perl Jobs?

I'm not a unique and special snowflake. Programmers aren't fungible, but there aren't so many difficult programming tasks that you need the world's singular expert in a subject. (The fact that my degree says Music and not "Computer Science" from Stanford, Berkeley, MIT, or CMU probably keeps me out of computer vision, AI research, and compiler design, however, just as much as it's garlic to the Google recruiters who want me to believe it's an honor to spend weeks answering questions about ping pong balls and sorting phone books for the opportunity to babysit a data center full of machines dedicated to slapping ads on the world's information.)

It should be no secret that, if I stay in programming, my preference is to work with the language of my expertise and preference. I believe that the fashion-driven chasing of programming fads is bad for business and programmer alike, but that world isn't changing any time soon.

As I see it, you can find a Perl job in one of a few ways:

• Create it yourself by starting your own company
• Create it yourself by recruiting a client without a strong technology preference
• Create it yourself by introducing Perl slowly into an existing job and making it irreplaceable
• Find one of the existing companies using Perl (read "Move to Amsterdam" or "spend time maintaining a codebase from 1997" or "get very lucky")
• Create something so amazing and compelling and useful that people can't not use it, like mod_perl or Movable Type or, let's throw cPanel and Catalyst in there
• ...

Fifteen or fourteen or even ten years ago, I might have railed against the inherent unfairness of a cruel and uncaring universe of technology driven by fashion, where technical superiority is less important than buzz, but I've tried these approaches over my career. As I ponder the midpoint of my career (asking myself "Should I get a CS degree?" or "Wouldn't it be more effective to get a degree in finance and manage a boutique legal firm?"—I am not making this up, but then again I thought about buying a bakery a couple of years ago and it took Robert Buels only a few minutes to talk me out of it), the broader question of patterns and trends comes up.

Is Any Technology Immune to This?

Apart from COBOL? Mumps? No.

Do I want to program in Cobol or Mumps for the rest of my life, or even the rest of the afternoon? No.

Look, I'm a programmer. I solve problems. I've managed teams and I've been managed. I've written documentation and I've written tests. Some days I've deleted more code than I've written and I've been glad of it. Some days I've solved customer problems by not writing code. Some days I've been elbow deep in profiles or Valgrind reports and other days the best thing I've done was add an index to a column in a database and it was totally worth all of the research to reach the point where that was the solution.

I have my preferences in technology, sure. I also have my experiences. When you hire a programmer, you're getting his or her preferences and experiences and biases.

Maybe I'm being too picky. Maybe it's natural to reach the mid-career crisis and say "Arguing over which syntax is best on the Internet is a poor use of time I could spend walking a dog or playing pinball with my eleven year old nephew or celebrating a housewarming with friends". Maybe it's acceptable to by cynical and say "I'm a professional, which means that even if I have no personal interest in managing clinical research records, you are paying me enough to bring my knowledge and experience and hard-won judgment to bear to solve this problem in an effective and trustworthy way", but I'm probably not going to spend my nights and weekends thinking about it.

Alternately, perhaps I should have bought that bakery. Sure, you have to hire people you can trust and pay them a lot of your revenue and you have to get up at 4 am every day and health inspectors and land zoning and the prices of dairy products...

... but you're not dealing with VCs who underpay you and dangle ever more diluted RSUs in front of you for that 1% chance of an acquihire payout that'll slightly pay more than if they'd paid you a market rate for the start, or clients who want the world in a week for $20 an hour because some teenager in Albania only charges $8 an hour but at least you speak English, or an HR department that sees "Perl" sprinkled liberally through your résumé and thinks either you're the system administrator you started as in 1998 or someone who fell through a time warp in 1999, and by the way, they have the Internet on computers now, har har, JavaScript is a real language, would you kindly join us in the new spring lineup for 2014?

The Real Question

For someone whose life obligations preclude selling everything and living on a beach in Thailand or Belize for a year, how do you evaluate a career reaching its midpoint? How do you keep programming fresh? How do you market yourself as someone who solves problems instead of someone who transcribes ideas in the language du jour? Or do you leave programming altogether?

I don't have the answers, but if there's anything a decade and a half of experience has given me, it's the ability even to ask those questions.

If you, like me, have worked on any project in rapid development, you've had the joy of dealing with changes to your database. Tables get added. Tables get removed. Columns get renamed. Constraints get added. Stored procedures change their parameters. Refactoring code is easy (if you have discipline, source code control, and an effective testing strategy), but refactoring your database seems more difficult.

In the good old days, you may have had a directory full of little .sql files with DDL for schema changes and insert, add, delete, and update statements to mangle data.

Sqitch is a database change management system designed and developed by the inestimable David Wheeler. David is also responsible for pgTAP, which provides usable automated testing of PostgreSQL databases.

Sqitch gives you a command-line tool to manage database changes. You can add new changesets, apply them, and even verify them. (In practice, verification happens automatically; Sqitch encourages you to write pgTAP-style tests to verify that your changes do the right thing. If your tests fail, Sqitch rolls back the change. Obviously this works best on mature database systems such as PostgreSQL.)

I've used DBIx::Class::DeploymentHandler on other projects successfully, but there was always a little mismatch between how I prefer to work (maintaining DDL by hand) and how DBIC tends to want you to work (manage your schema as a set of DBIC classes and let it generate the DDL for you). That's mostly personal preference, but I do believe the Sqitch documentation is easier to understand at the moment as well.

The only substantive complaint of any sort I have with Sqitch at all is that its idea of an ideal directory structure in which to store migration files is different from my idea. (This may not be true of the most recent versions.) You can override its notions with environment variables, but I use it on multiple projects.

A while back, on a previous project, Allison said something like "What if we had a Makefile just to automate away the common commands that we're all typing all the time?" These commands did things like "Run a development version of the web server" or "Recreate the testing database" or "Update all of the dependencies we're using with Carton." While I hate the use of Make as a requirement to build CPAN modules, Make solved a real problem for us.

The problem is: how do you create a consistent set of commands, scoped to the project, which collect common operations and configure external tools to work as the project desires? We had a little directory, tools/, because the kind of people who work on Unix-like systems and have no problem writing Perl code are the kind of people who have directories full of useful, single-purpose tools. Yet we wanted something a little different.

Makefiles are unholy unions of dependency-based procedural programming and shell commands. They're not really either one, but at least they let you extend them so that you can type make command and have something reasonable happen. You're not cluttering up your shell alias list with aliases for every project you have in development and you don't have to remember paths or invocations special to every project. You get a little bit of consistency so your brain can spend its power on more important differences.

Here's what I have for the current project:

PSQL=psql -h localhost -U mpuser
PG_LATEST_DDL=db/current/myproj_ddl.sql
PG_TEST_DATA=tools/test_db_build/test_db_fixtures.sql
SQITCH_CONFIG=config/sqitch/sqitch.conf
HAS_TEST_ENVIRONMENT:=$(shell perl -Ilib -MMyProj::Config -e 'print MyProj::Config->new->allow_testing_db')

sqitch_cttester:
    @echo sqitch deploy cttester
# Makefiles are tricky about indentation
ifeq ("$(HAS_TEST_ENVIRONMENT)", "1")
    @SQITCH_CONFIG=${SQITCH_CONFIG} sqitch -d cttester -u cttester deploy; true
    @SQITCH_CONFIG=${SQITCH_CONFIG} sqitch -d cttester -u cttester status  >/dev/null 2>&1
else
    @echo not in test environment, skipping
endif

sqitch_myproj:
    @echo sqitch deploy myproj
    @SQITCH_CONFIG=${SQITCH_CONFIG} sqitch deploy; true
    @SQITCH_CONFIG=${SQITCH_CONFIG} sqitch status  >/dev/null 2>&1

sqitch_deploy: sqitch_myproj

sqitch_add:
    SQITCH_CONFIG=${SQITCH_CONFIG} sqitch add $(name)
    vim "config/sqitch/deploy/$(name).sql" "config/sqitch/revert/$(name).sql" "config/sqitch/verify/$(name).sql"
    git add "config/sqitch/deploy/$(name).sql" "config/sqitch/revert/$(name).sql" "config/sqitch/verify/$(name).sql"

First, the Makefile defines a couple of environment variables used throughout the file. The most important are SQITCH_CONFIG, which controls the location of the project-specific Sqitch configuration file and HAS_TEST_ENVIRONMENT which returns a boolean representing whether the current environment allows the use of a separate testing database. (The production server has no testing database. Development servers do.)

I only ever use the sqitch_deploy and sqitch_add commands. The deployment command tells Sqitch to deploy the most recent migrations it knows about in its plan. Sqitch's status command returns a boolean representing the success or failure (so that the exit code of make sqitch_deploy is useful and that make command doesn't think that the target failed).

The sqitch_add command helps add a new database migration. It takes one argument, so invoke it with make sqitch_add name=new_migration_name. Not only does it add the migration, it opens the new files Sqitch has created in vim (it should use the $EDITOR environment variable, but I haven't needed to care about anyone other than Vim users yet) and then adds all of the saved files to git's index.

This saves me a few dozen keystrokes and a few seconds every time I make a database change. If that sounds trivial to you, good. A few keystrokes and a few seconds are trivial. My brainpower isn't trivial. Those keystrokes and seconds mean the difference between staying in the zone and fumbling around trying to remember commands I don't use all day every day. They save me minutes every time I use them, if you count the friction of switching between "How do I do this in Sqitch again? What's the directory layout here?" and "What was I really working on?"

Automating silly tasks which take up a few seconds here and there is valuable if you can get rid of that friction. Sqitch has helped remove that friction from database migrations. Automating Sqitch with a simple Makefile has gone even further.

When Perl 5.6.0 introduced lexical warnings, it gave programmers finer control over what parts of their program would produce warnings and how to handle those warnings. The most important feature is that the warnings pragma has a lexical effect. In other words, rather than enabling warnings for the entire program unilaterally, some files and blocks can request stricter or looser warning categories than others.

Whole-Program Robustness is Not a Library Concern

This is especially important for Perl applications which are often a combination of custom code and CPAN modules. Even though the CPAN is free and open source software and even though many of the newer CPAN distributions have public source control repositories to which you can submit patches and feature requests, there's often a thick line between "code we maintain for this project" and "code someone else maintains". Lexical warnings mean that the maintainers of CPAN distributions can choose their own warning strategies and your team can choose your own warning strategy and those strategies don't have to be the same.

Keep that separation of concerns in mind for a moment.

Blurring the Lines Between Warnings and Exceptions

The warnings pragma also included a feature which can promote any warnings caused in a lexical scope into exceptions. If, for the purpose of security or clarity or maintainability or coding standards, your team decides that uninitialized value warnings are so severe that they should be exceptional conditions, you can ask the warnings pragma to promote that warning to an exception within a lexical scope. This is a powerful feature that you should use with caution; unless you're prepared to catch those exceptions and deal with them (or not catch them and deal with the consequences), those exceptions will cause your program to terminate. That may be what you want, but if you've asked for it explicitly, Perl believes you know what you're doing.

Perl also gives you the option to promote all warnings in every warning category to an exception with use warnings FATAL => 'all';. If enabling fatal warnings for one warning category is serious, promoting all warnings to exceptions is grave.

Promoting Library Warnings to Exceptions

The warnings pragma also added an interesting feature by which modules can register their own categories of warnings. Perl will treat them as lexical warnings just as if they were core warnings. In other words, a module which chooses to register its own warning category will be able to emit warnings which respect a use warnings; or no warnings; in caller scopes.

This is a wonderful feature because it respects the separation of concerns. It's not up to a library to dictate what the users of that library consider warnable conditions. The users of that library can elect to accept warnings or disable them as they see fit.

Warnings registered with warnings also fall under the purview of the fatal warnings promotion code. If you've enabled fatal warnings and if any of the modules you use within that lexical scope emit a warning, that module's warning will become an exception.

Fatal Warnings are Not Future Proof

If you have the mindset for reading awkward bug reports, Perl RT #121085 demonstrates one serious danger of unilateral fatal warnings. Because you've asked Perl to treat all warnings as fatal, any warning you get will be fatal.

Because Perl, by default, does not treat warnings as fatal (because Perl uses the word "exception" to mean "exception" and "warning" to mean "warning", thus distinguishing between the two as a matter of syntax and semantics), it's possible that a newer major release of Perl may emit more warnings than a older major release of Perl. In fact, that happens. As Perl evolves and improves and Perl users discover more interesting and useful interactions with the language and as bugs get fixed, certain conditions lend themselves to error messages.

If you've written use warnings FATAL => 'all';, you've accepted the responsibility for checking to see if a newer release of Perl emits newer warnings. Even if you didn't know you had that responsibility, you should have known. That's what you asked for. Your program threw an exception and you didn't catch it. That's your responsibility.

Many people know that. That fact is rarely controversial. If you read the RT #121085 bug report, you'll see the argument that p5p should be extra careful adding new warnings because some people choose to treat them as exceptions, and so they're effectively exceptions, and p5p is causing previously valid programs to break—but that's a silly argument.

Perl developers brag rightly about Perl's commitment to backwards compatibility, but an understated corollary to backwards compatibility is forwards compatibility. It's your responsibility as a developer to write code that's compatible with future releases of Perl (within reason) or to face the consequences. If you write code that is likely to break when upgrading to a new version of Perl, that's your fault. p5p will do its best to ease the transition (that's why deprecations are multi-year processes which begin with warnings and eventually become exceptions), but you have a responsibility too.

That fact is a little bit more controversial, but it's pretty well established on p5p. It's not at all well established on the CPAN, which is where the problem gets a lot more serious and subtle.

Remember how modules can register their own lexical warnings? Just as Perl may add new warnings in major releases, modules can add new warnings—except that CPAN modules can add new warnings whenever they see fit, because there are no normative community standards about when it's acceptable to add new warnings, how often releases will happen, how long the support period for releases is, and any commitment to backwards compatibility or deprecation.

If you've enabled fatal warnings, you've asked for any warnings in any CPAN module that you didn't write and you don't maintain to become exceptions which may terminate your program. The risk isn't "We upgrade our core Perl once a year and read the list of changes then run our entire test suite and only then deploy a new version". The risk is "We've updated CPAN modules and now have to audit all of them for new warnings."

That's a bigger risk—but it gets worse.

Fatal Warnings Do Not Belong in Module Code

What if a CPAN module you use but do not maintain uses fatal warnings? Any change to its dependencies which throws a warning the module did not account for may now throw an exception. Because it's in code you do not maintain, it's time to break out the debugger to figure out what went wrong, then fire off a patch and hope the maintainer releases a new version. In the meantime, your code is broken because a CPAN maintainer did not think about the risk of promoting warnings to exceptions for circumstances which are outside of his or her control.

"Wait," you say. "Which CPAN author would be silly enough to write use warnings FATAL => 'all'; in library code? That's awful, and I wouldn't use that code."

The problem is that Moo enables strictures by default in all code that simply writes use Moo; and strictures enables fatal warnings in all code which uses strictures, so writing use Moo; enables fatal warnings in the enclosing lexical scope.

In other words, any CPAN module which uses Moo is, by default, vulnerable to a change in any of its dependencies which may legitimately produce new warnings. By "vulnerable" I mean "your program may start crashing in library code you didn't write and do not maintain and, by the way, may be in a dependency several levels deep that you didn't even know uses Moo."

One solution is to use Moo::Lax instead of Moo in code you write for the CPAN. That doesn't fix existing code, but it doesn't make the problem worse.

I suppose the well-intentioned people who wrote strictures could make the argument that "You should be submitting patches against CPAN modules anyhow!", but I have trouble reconciling that against their justification for enabling fatal warnings, which seems to be "Novices should take exceptions seriously!" as the argument then becomes "If new Perl programmers aren't willing to learn enough about Perl to submit upstream patches when our code crashes their programs, there are many other languages they can use with library ecosystems which aren't hostile to new developers"—and that's a silly argument to make too. (Then again, strictures has the misfeature, documented in RT #79504, that its behavior will change if you're in or slightly under a directory managed by a VCS even if you're not a Perl developer or even if it's not a Perl project or even if the program you're running has nothing to do with the directory or even if strictures is a dependency of library code several levels deep.)

In Other Words, strictures is Broken?

I suppose you could claim that it's Moo that's broken, for inflicting the silliness that is the current behavior of strictures on the CPAN and all downstream code that's unfortunate enough to somehow, somewhere use code that depends on Moo, but the real problem is that use warnings FATAL => 'all'; does not belong in library code that you're handing other people to use. It's just too risky.