Five Features Perl 5 Needs Now

Perl's 21st anniversary of release is next Thursday, 18 December. Perl 5 is already 14 years old. Though the language has seen many changes since 1994, it can't stand still. and , but what's the vision for Perl 5? How can the language stay relevant?

I believe the best way to do so is to add features which remove tedium, frustration, and potential errors from real projects -- not to check off marketing features on the back of a metaphorical retail box, but to make programs easier, faster, more productive, and more fun to write.

Perl 5 should add:

• Regular releases. The project is about to release its 24th monthly stable release in a row. If only one decision has turned around the fate of the project, it's this one. Monthly releases have allowed us to find a workable development rhythm, demonstrate that we can make and meet commitments, and implement a sane deprecation policy which lets us identify and recover from inevitable design mistakes. A three-month point release cycle for Perl 5 may be painful to achieve (you have to streamline your release process), but taking the mystery and confusion over releases and allowing yourself to hold back a feature because the next release is soon provides stability and confidence.

• , , and . Though , the relative simplicity of default objects in Perl 5 optimize for flexibility, not ease of use. , one which scales upward in features if you need more power. If the core subsumed these models, everyone using 5.12 would benefit -- and this would smooth the path for people considering a migration to the Perl 6 object system.

  Similarly, autobox adds one of Ruby's loveliest features -- the ability to call methods on primitives as if they were objects. Though conceptually Smalltalk's "everything is an object" philosophy butts heads with Perl's pragmatics, this practice can occasionally remove a lot of complexity from code. That is another important pragmatic.

• Python's . is crufty and baroque. It requires far too much knowledge of Perl internals merely to pass and return values to and from shared libraries. My was a proof of concept to simplify the most common uses, but I haven't had the time or energy to work on such a system. Python's ctypes library is a smarter, saner approach than requiring people to write and compile C code just to map between Perl 5's and C's calling conventions. There's room to improve the ctypes API, but the concept is sound, and sorely needed in Perl 5.

• Better CPAN integration. This sounds odd, but the CPAN installation system is an aggregation of fixes upon fixes. For example, to install a module from the CPAN, you must first answer several questions to configure the client. Then, you download a package, which runs a small program, which generates a Makefile, which configures, builds, tests, and installs the module -- if everything went correctly.

  I should also mention that on the author side, you have to write this program which generates the Makefile.

  If you don't have root access to the box, or you don't have a C compilation environment, or you don't have a compatible make utility installed, or you don't have network access, or you don't have the Perl headers installed, you may have a world of trouble.

  I'm not suggesting that the process doesn't work -- but I'm not sure that the default behavior and default experience is as easy as it could be for the most common cases. If the CPAN is the shining star which leads people to Perl 5, as so many of us have claimed, shouldn't we make it as easy to accomplish the simple things as possible, while not precluding less-frequent but no-less-necessary customization?

• , the equivalent of for Perl. is an amazing piece of technology, but it asks a lot of administrators -- it effectively takes over the web server. Perl on the web could benefit from a system which allows cheap hosting providers to say "Just upload a few files into this directory, and everything will happen for you automatically!" without worrying about other customers on the same host fighting for resources (or namespaces or memory or...).

  Very Serious Developers may still use mod_perl -- but novices and the rest of us who aren't handling more than a hit per second at peak time should have something easier to set up and gentler on resources than CGI.

The Perl 5 Porters list occasionally debates many blue-sky nice new features; recent debates have considered what Perl 5.12 needs. With the exception of Mouse, Moose, and autobox, these features listed here haven't had as much attention. I realize that the CPAN and mod_perlite questions may be somewhat outside the purview of the core developers, but when considering the Perl world as a whole, they're gaps and infelicities no less blatant than the others.