Five Features Perl 5 Needs Now

By chromatic
December 10, 2008 | Comments: 39

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. Perl 5.10 added many wonderful features and Perl 6 will change the landscape for programming languages, 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 Parrot 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.
  • Moose, Mouse, and autobox. Though Perl 5 borrowed Python's object system, the relative simplicity of default objects in Perl 5 optimize for flexibility, not ease of use. Moose and Mouse provide a better default object system for Perl 5, 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 ctypes. Perl's extension system 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 P5NCI 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 CPAN 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?

  • mod_perlite, the equivalent of mod_php for Perl. mod_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.


You might also be interested in:

39 Comments

I think Perl also needs a function to sort uniquely, just like the "/bin/sort -u" in UNIX.

Apart from Moose & friends being in the core, I'd love to see mod_perlite shine. When I present mod_perl to friends, they love it, until they have to read an awful lot of documentation just to output anything from a perl script. I really love mod_perl, but, the simplicity of mod_php is what made it an option, otherwise, no one would use that.

s/crrufty/crufty (unless you meant that for emphasis?)

I'm still giving my vote for having Moose & autobox to be part of the core for 5.12 (and a second mention to try and slip in Devel::Declare stuff like MooseX::Declare etc).

So how do we (the Perl community) make this happen?

And is there a consensus on this? (darn it I've just noticed my p5p mailing list digests seemed to have stopped again!)

I wonder if this "vote" should be part of the next Perl survey?

/I3az/

Step one to getting Moose in core, convince the Moose devs (of which I'm one) that it's worth the pain, which I'm very not convinced of.

Actually, I think a better approach would be to have the core start implementing Moose features. At least then it'd be fast, although we'd still have the problem of having it frozen at a certain implementation for a long period of time, in the absence of much more frequent releases.

Being put into the core is *death*. Moose and Mouse are not ready for that yet. Core Class::Accessor first.

I do think stable, useful modules that require XS (in particular Autobox and PadWalker) should be cored for various reasons.

This idiom is pretty concise:

my %map = map { $_ => 1 } @original;
my @unqsorted = sort keys %map;

There's also the unix idiom:

./listgen | sort | uniq

my @sorted = sort @original;
my $prev;
my @unqsorted = grep { my $r = defined $prev ? $prev eq $_ : 0; $prev = $_; not $r } @sorted;

Ok, that's ugly, but only because I'm using strict, otherwise it's just:

my @unqsorted = grep { $r = $p eq $_; $p = $_; not $r } @sorted;

(read: $r as "repeat" and $p as "previous")

Bron.

>Python's ctypes. Perl's extension system is crufty and baroque.

What do you think about http://search.cpan.org/perldoc?FFI ??

Core should have less not more. It's stupid that p5p has to chase down people to make sure things like CGI.pm (I'm not picking on Lincoln, as far as I can tell he does a wonderful job) are up to date. I want my pumpkins focused on Perl.

Things like Moose and Mouse (specifically) should be done up in a separate dist. Similar to how Vanilla/Strawberry/Chocolate work under Alias' supervision. You could build a list of modules that are the "Best of Breed" for Perl development, and publish a distribution that included those. This could be done by some sort of enlightened organisation, who could form a working group of some kind who would be tasked with making sure that modules who are chosen have patches and bugs applied, and that the authors have the support they need. If only such an organisation existed...

On the subject of CPAN, most of the components needed to move the it-just-works-out-the-box "Strawberry Experience" to the core are pretty much completed.

We just need to get them finalised and moved into the core.

WRT "the core" I agree that the core should be small.

Personally, I think it should be SO small that it becomes impossible to do anything other than load modules.

You define "Layer 1", "Layer 2" etc that provides successive levels of functionality.

Layer 1 ONLY has support for loading modules into memory, and is contained in the tarball itself.

Layer 2 includes platform abstraction modules (File::Spec, File::Temp, File::HomeDir, IO::Socket, etc) and can serve as a minimalist run-time you could then install pre-build modules or products on.

Layer 3 includes everything you need to bootstrap up to the point of having a CPAN client.

Something like this is what I'm hoping we can arrange for Perl 6 distros...

For Nemo:
use MoreUtils::List qw(uniq);
@bar = sort uniq @foo;

I used ctypes long ago and was amazed by it! perl alternatives are just not as silky smooth.

oops! s/MoreUtils::List/List::MoreUtils/;

Working on it ;-)

I don't understand the point about "mod_perlite". What do you expect from such a module? Something like Mason or Embperl or one of the other "embedded perl" modes? There are many alternatives in Perl and not one is dominant.

I really like the idea of mod_perlite. I usually "settle on" HTTP::Engine when I want to make a really simple app, but we could do even better than that.


What I am thinking now is a HTTP::Engine-based service (with some glue to make it an apache module) that reads files, and wraps them in a subroutine, and makes $request and $response available to the mini-apps. (I will upload a prototype to git.jrock.us shortly.)


I would also like to put full apps inside PARs, and then drop that into a directory and have it "just work". This will involve a bit more coding, but I think I have the basic idea down.


Someone should setup a mailing list for this.

OK, you can get my code by saying "git clone git://git.jrock.us/perlite_prototype".


In that directory, run "bin/server.pl example". Then you can drop the mini perl scripts in the example/ directory. Anything with .pl is a perl script; everything else is static content. In the perl script, you get a request and response object in @_. You also have full MooseX::Declare syntax for creating classes, if you desire. (See the examples in that directory for details.)


Anyway, I am really excited. We can give people new to Perl the full power of Moose and HTTP::Engine, without requiring them to install modules. They can just upload their script, and hack away. (And this is only with about 20 minutes of work, so far.)


chromatic++ for the idea!

I think you pretty much nailed it. In more or less priority order too. Regular releases are crucial to any project. It cuts down complexity, and makes tasks "bite sized". Bugs get squashed quicker (because you're not changing as much) and people have more faith in upgrading, because they know it's more stable and not much has changed (and they do it every month, or quarter or whatever as part of their usual process).

I also agree that Perl isn't properly leveraging the wealth of code that's on the CPAN. Other languages have much more elegant solutions to dependancy managment.

I agree with David; HTML::Mason is easy to setup, it runs under mod_perl and does everything you would expect from "something like PHP" -- and a lot more. Or then I don't understand the requirements.

Perl is a language that lets programmers think the way *they* want to think - mostly. It's not perfect, but that above all other things is why Perl is my language of choice.

IMO, things that improve that principle are most worth advancing.

Moose/Mouse are great stuff, but I agree with what Dave said about having them "frozen" - they simply aren't ready for that. However, something more mature/static would be perfect - like autobox.

Autobox adds syntax and semantics to the language that it never had before. Building upon ideas like that gives programmers more and more of what we love about Perl.

Everything else chromatic mentioned I agree with 100%. However, because I consider it the *most* important point, I want to say that I think that replacing/eclipsing/augmenting XS with something *at least* as good as Python's ctypes is *critical*.

Python has something special these days -- interfaces and APIs to just about *everything*. Perl has a long history of being a 'glue' language, but Python is eating Perl's lunch here. I don't have any experience writing XS, but what I've seen is *frightening* and even experienced hackers I've talked to seem to hate it.

Big +1 on mod_perlite.

That would be a huge boon for Perl's popularity. See http://blog.ianbicking.org/2008/01/12/what-php-deployment-gets-right/ for the real scoop on why PHP hits the sweet spot in *so* many cases. If mod_perlite could do that, I (and I think I could convince my sysadmins) would switch in a minute.

--peter keane
ut austin

mod_prelite is the key, simplicity of mod_php in work make it popular, perl really need it. advance users always can find the way, beginners needs something simple and easy to use ( not stupid ), I like the idea of PAR package that jrockway mentioned too

I agree on all points! If we had more frequent p5 releases, better CPAN integration and an improved XS then putting Moose/Mouse into core would be well worth the "dual-life module" pain, because,.. well the pain would be lessened.

Very nice list :)

- Stevan

About mod_perl .. Ian's blog had definitely good points and we should learn from those issues. However, if you want to sandbox your mod_perl stuff, shouldn't you use "PerlOptions +Parent" option like this:

http://perl.apache.org/docs/2.0/user/config/config.html#C_Parent_

You will then have your own (or pool of) Perl interpreters for every virtualhost .. or even for a specific directories under one vhost.

Still, if you want the simplicity of PHP, and just put your stuff under the document root directory and start coding, HTML::Mason is a good choice with very gentle learning curve. When you need more (for example to separate your DB logic to a separate "model" .pm), it allows you to use any native Perl module, as all Mason templates/components are just Perl.

A lot can be done with Mason's own component calls; everything lives under the document root and it's very straight forward, but when more is needed, just setup own INC path for every site/customer and run the interpreters in own sandboxes (as described above). Only remaining "problem" would be restarting the interpreters when site/customer specific .pm code changes.

So as a conclusion, I think all the pieces are there, but people just don't know about them, can't find good documentation and best practice examples. That is a big problem and requires more visibility, not so much coding.

For MVC, use Catalyst. You can still use Mason as a View.

Thanks for this post, chromatic. I thoroughly agree. Many Perl users on shared hosting environments have never been able to take advantage of mod_perl -- I am one of them, and I would love to see something like mod_perlite.

Also, I find deploying and installing Perl applications far too difficult for the average user, and this has its root in CPAN. We need somethink like .jar files that you can just throw onto a server and it works.

Thanks for your ideas - especially as to a better integration of C/C++ or java I agree to 100 %. I find it always hard to call compiled c/c++ or java routins which is after all not always avoidable, especially if you need to automat applications.

use PLP;

JF^D Perl Programming

I especially liked the making-CPAN-better idea. Its a pain in the a** to install stuff from CPAN that needs to be compiled right now....

I would agree with comments to the effect that the core should have less, or really the bare minimum. Then we'd have Perl 'stacks' to load up common types of work, similar to the way the Eclipse project works. We could have a 'Classic' stack that includes all the old core stuff, a OO Developer Stack, which I'd could see Moose playing a big role in, etc.

We'd have to tread carefully since I know the Moose core group is reluctant to see Moose tied to a version of Perl. Moose is very active, with a very aggressive release schedule. Getting people to support the idea of a "Long Term Release" version of Moose, similar to what Ubuntu does is not going to be very easy.

Something missing from the list is the question of Advocacy. This is going to kill us if we don't make 2009 the year of Perl Advocacy. I mean, Ruby has a minor release and it's on Slashdot. But several Moose releases have added more features than a lot of the RoR, Django, etc releases of late and yet the project seems to have little visibility.

Every Cloud startup or every web application vendor with any sort of web API will proudly mention it's compatibility with Ruby, Python or PHP, but Perl is very seldom mentioned. On my latest integration project when I asked for a perl sample of how to use their SOAP API I was sent a hacked up script that used LWP. It looked like it was written in 1994 or worse. When I saw that I thought to myself, "When the average programmer thinks of Perl, this is what they think of."

For some reasons advocacy doesn't come naturally to our community. I guess most of us are practical and very busy. Spin and crap PR stuff isn't something we like to spend time on. Also, we are complacent. Perl is working for most of us. But even with the love of Perl I have, it's becoming harder to justify using it in an enterprise setting. Hiring good Perl programmers is becoming nearly impossible (Please don't email me about a job, my company is not currently hiring, but when we were in the summertime, we must have interviewed 20 people, and settled on hiring an old friend of the CEO, a person he already know was a good perl programmer).

So we need more of everything when it comes to advocacy. More blogging, more documentation and examples, all of that.

People have been saying this for years. I'll just add that we are literally on the edge of a cliff here. That's my perspective.

Frankly I feel it is quite justifiable that a library (read Moose) does not get the same visibility as the core language upgrades (read minor Ruby version). This is how people from the outside look at the language. CPAN is the treasure of Perl - but it cannot be treated at the same level as the core language. I will always be an additional step - and additional requirements (Internet connection) from the core. And that dictates how people learn Perl.

Badger by Andy Wardley looks nice as well. No outside of the core dependencies. A nice object system as well. It is a good foundation to build on.

If you really want a lighter weight Moose, check out Mouse, which is a intended by the Moose developers to fill this role. It also has active contributors and tries hard to be a subset of Moose functionality (so you can jump from Mouse to Moose should you require more power)

I agree with the mod_perllite. I was basically forced away from Perl by my line of work to PHP. I always considered PHP = PerlLite, and so much miss my "Pretty Easy to Read Language"!


Something proposed on p5p for 5.12 with a lot of encouraging feedback and no one opposed yet (only discussion of the details of it) is parameter lists. That's huge, from a PR standpoint. Like autobox, the lack of it doesn't keep you from doing things, but without a good reason not to have it, everyone will assume there's something wrong with Perl for not having it, and that it's a symptom of more screwed-up-ed-ness.

On XS, I couldn't agree more, except for one caveat -- that's needed now to save 5.14. One of the main things preventing refactoring in core is the need to maintain the ABI/API used by so many XS modules. Problem is, Perl exposes some seriously crufty stuff that modules now depend on (as you know). If 5.12 can introduce an alternate ABI/API that's more abstracted, then long process of deprecating stuff like "vtable magic" can begin.

-scott

can i know books on hacking?????
how to hack???

Regarding mod_perl lite: I use the SpeedyCGI module on my pair.com host, and it works great. I get about a ten-fold performance improvement on complex scripts with database accesses, and it has proven reliable and lightweight.

What is SpeedyCGI (PersistentPerl) missing that would make it the answer?

Hello, I have 3 yrs msoft testing (lang and proc),3
Java,1 Ethernet(math and structure),If I was to observe PERL "extract" info from a common text file,even as early as 1990 msworks,and chart the behavior of the mission,very exactly,with good math results,can I get a certification from someone?
Thanks.

pleas send me anti proxi.

I am not a fan of CPAN dependence in a language, mostly because I run most of my code on a network that has airgap security, meaning we're not connected to CPAN.

Often I don't get to use the newest features of perl because it is so much effort. It would be nice if Perl contributors took this into account--there are perl modules in CPAN which assume that you're installing from the same machine that retrieved the modules from CPAN. That's a bad assumption.

Agree with Ray Bingham. Unnessecary adding to the CPAN module dependency list is bad. Many people seems to think using a CPAN module is always better even if it just replaces a local sub of only three or four lines of code.

News Topics

Recommended for You

Got a Question?