Modern Perl Books, a Modern Perl Blog

Eighteen months after I started this site, the Modern Perl book is almost out, as is Using Perl 6. Perl 5.10.1, Perl 5.12.0, Perl 5.12.1, and (very nearly) Perl 5.12.2 are out, with Perl 5.14 coming next spring (not month, as I mistakenly typed). Spring means, of course, April or May 2011. (Sorry, southern hemisphere; you should elect a volunteer release manager.)

Rakudo Star has had two impressive releases, which brings Perl 6 to ever more people. The Parrot VM had its 1.0 and 2.0 and 2.3 and 2.6 releases, and if you want an order of magnitude performance improvement in Rakudo Perl 6, the Parrot 3.0 series will deliver some impressive gains through the Lorito reorganization.

I've spent a lot of time critiquing the Perl language and community and even more time critiquing perceptions of Perl from within and without. I'm glad to review what's going right. It's easy to make a list of great new features of Perl and the community, but I can limit it to my favorites, in terms of immediate and longer-term significance.

By no means are these the only important developments in Perl in the past 18 months; please by all means let us all know what you find most important in your own journals and talks and presentations.

• The revitalization of Perl 5 core development has amazed me. Regular monthly releases have become boring, as they should be. A rotating series of release managers helps avoid the burnout that's claimed every Perl 5 pumpking up to this point, and it helps to make the process of releasing a new stable version of Perl 5 easier. That's why you can have confidence upgrading to Perl 5.12.2 when it comes out, and why in a year Perl 5.10.1 will look old.
• I've wanted Plack for Perl for ages; I've long thought Python's WSGI is a good example of the "There should be one obvious way to do it philosophy" (it works much better for interfaces to well-defined problem domains than language features). The rapid adoption of Plack for so many web frameworks and libraries within Perl—as well as the number of backends supported by Plack—has solved many of the deployment problems of Perl web applications. It also allows greater collaboration on middleware, such as debugging and profiling tools.
• Ancillary tools such as perlbrew and cpanminus have demonstrated that very simple interfaces devoted to solving the most common problems can improve the user experience immensely. I've known how to maintain my own user- and app-specific Perl 5 installations for years, but I've never wanted to maintain the morass of symlinks necessary to do so. Now I don't have to. Similarly, cpanminus lets me install CPAN modules often in the time it takes the official CPAN client to download the indexes.
• Regular releases of the first Perl 6 distribution (Rakudo Star) demonstrate the power and consistency and disruptive potential of Perl 6 to even more people. Every month brings new features and improvements. Every bug report and new module written and benchmark help the development community make it an even better platform for new projects.
• Schwern made the CPAN forkable through gitPAN, and the world is better for it. Public distributed version control for Perl 5 improves the experience of submitting changes, and public distributed version control for CPAN distributions has helped me submit and publish more changes too. Noticing a typo in documentation on search.cpan.org has become almost an enjoyable experience, if I can find the appropriate repository on Github, fork it, make my changes, and submit a pull request within five minutes. Often I can.

I look forward to several other projects in the world of Perl, such as Ryan Jendoubi's Ctypes for Perl 5 and the ongoing attempts in the Perl 5 core to rein in a sane set of functions for extensions to use. I've heard that various help forums have become more helpful and less abusive (especially #perl on irc.perl.org). I've even noticed a shift in how community members talk about marketing, especially as the discussion has changed from "Marketing? That's for those sick Java fans!" to "Hey, look at all of the cool stuff we're doing with Perl!"

We can and should still make improvements, but if the past year and a half is any guide, we can safely shift our cautious optimism for the present and future of Perl to regular optimism.

One current discussion on p5p is the namespace of fixed versions of reftype(), refaddr(), and blessed(), recently added to bleadperl.

These functions are part of Scalar::Util right now. Unfortunately, they return undef for non references. This leads to code like:

my $ref_type = reftype( $maybe_ref );
do_something_with_ref( $ref_type ) if defined $ref_type;

(If you don't follow all of the reasons why you have to do that, that's good; you haven't imagined all of the odd and strange ways people might name their classes in various parts of the Perl 5 internals and DarkPAN modules. Safety dictates finding these corner cases.)

Anyhow.

Making these fixed functions available in the core without having to load Scalar::Util offers some advantages but also some disadvantages. It's the "You can't add new keywords to Perl 5" problem. What if someone else defined functions of that name?

Worse, what if someone loads Scalar::Util and imports its functions and expects those semantics instead of the new semantics?

(Apparently it's impossible to detect the declaration or importation of symbols with conflicting names so as to produce warnings or exceptions in this case, though I don't see why. If we were in the habit of declaring the version of Perl 5 our code uses, we wouldn't have these problems.)

The discussion inevitably circled back to the ineffable question of "If this new feature is going in the core, how do people use it in previous releases of Perl 5?" That is, "You've added a new feature to Perl 5 which will be in Perl 5.14 released next year. Is there any way to backport that feature to Perl 5.12? How about Perl 5.10? You know, RHEL 3 is still around. Why do you hate Perl .5.8?"

At some point the weight of ensuring that code written for a future version of Perl 5 can run correctly (if you cram in enough flying buttresses of CPAN shims) on code written for obsolete versions of Perl 5 will pull down the entire edifice. Allowing code written for previous versions of Perl 5 to run on modern versions unmodified (or with a simple use 5.10; at the top—I know a great combination of find and sed which can perform this kind of textual manipulation {and if you're on Windows, use PPT to get portable versions of these tools}) is often good and useful.

Going the other way... well, I don't understand it. If it's possible and someone wants to do it, fine. Why should it block improving the next release of Perl 5 though?

First, read Tyler Curtis's Age discrimination in Perl 6 using subsets and multiple dispatch.

You can do everything in that post manually in Perl 5. (You're better off using a module such as MooseX::MultiMethods to handle the plumbing for you, but the point stands.) That's the fallacy of the Turing tarpit and the Blub programmer: everything is possible, but language support makes certain constructs easy and obvious, and easy and obvious code tends to exist.

If you think about Tyler's post that way, you can squint and see a general language design principle at work. Let me belabor the point somewhat more. Consider how to declare a new class in Perl 5. You have multiple possibilities. A class is merely a namespace, so:

package My::Class { ... }

That's well and good, and it works. Now do it at runtime:

eval "package $classname { ... }";

Again, that works. Yet if you consider the Class::MOP approach, you can start to see the flaw:

my $class = Class::MOP::Class->create( $classname );

I admit the flaw isn't staggeringly obvious until you need to add methods to the class. Again, it's not awful in standard Perl 5:

sub My::Class::method { ... }

... or at runtime:

{
    no strict 'refs';
    *{ $classname . '::' . $methname } = $method_ref;
}

... but how ugly when compared to:

$class->add_method( $methname, $method_ref );

The difference is the design principle at work: specify policy, not mechanism. In other words, the problem with the standard Perl 5 approach is that the how of how you store a subroutine in a package overshadows the intent of the approach. What's important is not symbolic references to typeglob slots in packages which represent classes. What's important is adding a method to a class.

The same rule applies when specifying type constraints on function parameters or multidispatch candidates or even declaring classes themselves:

class My::Class
{
    method awesome_method { ... }
}

... because even as much as I know how to implement a language on top of a virtual machine (or how to compile a language to native code), at the point where I read this code, much less write it, I don't care about the mechanism. I care about defining the policy.

The Perl community gets a lot of things right right now. Consider the CPAN: we expect a few standards of compatibility and kwalitee, but as long as you adhere to rough consensus, your work is useful and usable to a million other Perl programmers.

We have a good understanding of how to package your work and how to mark dependencies and how to document it, and that rough consensus allows sites such as search.cpan.org to provide infrastructure that allows me to read cross-linked documentation of the 84,944 modules on the CPAN (as of this afternoon).

Even the standard documentation mechanism for Perl modules (POD, adhering to a loosely-agreed organizational scheme) contributes to the utility and usability of the Perl ecosystem. You expect perldoc Your::Distro::Name to display something useful for the distro, even if it's a table of contents to other documentation. Larger projects or frameworks have introductions and tutorials and guided recipes (you know, like a "book" for "cooking", except without infringing on a trademark). If you know what you're doing and need a mere syntax refresher—or if your problem is small enough that a handful of lines of code can solve it—the SYNOPSIS section of the documentation is often enough.

Other times it isn't. Explain Plack in a paragraph, or DBIx::Class, or Perl::Critic, or Bread::Board (or explain Bread::Board at all; sometimes I think Stevan and Yuval are the only people who understand it).

Many of the wonderful new tools I want to use in Perl right now have a steep learning curve. I understand that some of them (Devel::Declare) have essential complexity that users must master before using the tool effectively. Not everything does—look at Test::Tutorial, which takes a subject which seemed complex and confusing in 2000 and 2001 and is commonplace and expected in 2010. Writing effective tests well is still an art of experience and good taste, but half an hour with that documentation has been enough to explain the basics to thousands and thousands of people.

I recognize that a SYNOPSIS won't suffice for demonstrating even a simple Catalyst application, with user authentication and logging and route dispatching and a model which is more complex than a Blog with Posts and Comments, but perhaps there's something in between a "Hello, world!" tutorial and the gory documentation of individual components and their methods. (Catalyst does this better than almost every other CPAN project.) Maybe larger projects should consider guided walkthroughs of real and modest-sized applications, especially if they include discussions about design goals and tradeoffs.

We're good at documenting reusable pieces of larger systems—CPAN encourages us to build applications that way. Can we improve further?

Claudio Ramirez raised a perceptive question about the Modern Perl book, specifically How do you deploy a modern Perl application?

I can think of several approaches:

• As a simple program which uses only core modules and relies on the system Perl.
• As a distribution on the CPAN itself.

• As a distribution on a custom, private CPAN.
• As a custom CPAN repository.
• Through the platform native packaging system.
• As a tarball of all of the dependencies installed already.
• Through the use of PAR.
• Through the use of a proprietary tool such as perl2exe.
• Installed manually with a custom build of Perl (whether with or without perlbrew).
• Through the use of another dependency management and bundling system such as Shipwright.
• As a service, not an installable application.

Have I missed any?

Under which circumstances would you choose one over another?

Is this subject appropriate to discuss in the book?