Once More Unto The Breach

So far this year, I've given talks at both OPW and YAPC::NA about where I see Perl headed as a language and as a community. While both talks made heavy use of hyperbole to drive my points home, the overall concern I was trying to convey was my belief -- my fear -- that our beloved Perl 5 had stopped evolving as a language. In my opinion, this is largely due to the problem of backwards compatibility and our community-wide commitment to maintain it. I also wanted to express my desire to see Perl continue to grow and move forward, and my intent to shake things up a bit to help make that happen.

The day after my YAPC::NA talk, our beloved pumpking Ricardo Signes presented "Perl 5: Postcards from the Edge". In this talk he spoke about the work he had done getting Perl 5.18 out the door as well as what might be coming down the pipe in future Perl releases. Rik talked a lot about backwards compatibility as well and how he, as the pumpking, didn't see the same strangle hold on the language that I did. Buddy Burden discusses this seeming difference of opinion in his post reflecting on YAPC::NA. I attempted to address the issue in my comment on that post, pointing out that Rik was talking about more subtle backwards incompatible changes that had been vetted through p5p, while I was talking about more extreme changes. Basically, I am being impatient and Rik is being steady and calm.

Later that same day, Peter Martini gave a talk about his work on getting subroutine signatures into the Perl core. There have been a lot of rumors about this change: claims that p5p bike-shedding had killed it, that Peter got annoyed with all the discussion and just up and left, and so on. In fact, none of these rumors were true. In fact, Peter has been steadfastly navigating the waters of p5p and very soon we will be getting subroutine signatures. Listening to Peter talk I was struck at how he approached getting his changes accepted, how he juggled the concerns of backwards compatibility and performance while still managing to move the conversation forward and arrive at a solution. I left this talk in a good mood -- apparently some of my hyperbole was, ... well, hyperbolic.

On the way back from Austin I thought about the stalled p5-mop project. Thanks to these two talks, I was able to consider the project in a new light, and ask myself a number of questions. If I took Rik's words to heart, studied how Peter succeeded, and got p5p involved earlier, would the p5-MOP have more chance of success? If I tried a different approach, something that was less ambitious and didn't try to invent so many new things, could it work? If I was more cognizant of the past and more willing to compromise to achieve my goals, could we actually pull this off?

In the end, I decided there was only one way to find out, and so I am officially rebooting the p5-mop project and giving it another go. To quote the README file:

The goal is to still have the same syntax, but to make the MOP itself much less complicated, therefore hopefully making the implementation ultimately more maintainable. Additionally this is being built from the start to be compatible with old-style Perl 5 objects and to try to lean on existing Perl conventions instead of inventing a bunch of new things.

Who knows, maybe my next talk in Orlando will be to announce how an upcoming release of Perl will not only have all the usual backward compatibility, but also a "forward compatible" built-in MOP.


I think you should keep exactly the same goal, and just change the timeline. Instead of one huge change up front, perhaps plan a series of smaller changes which build over time to reach the same endpoint?

Best of luck, sir! I think with this and the "dots" pragma, we're getting closer and closer to Perl 6.

I really hope you make it this time.

I think in retrospect this will turn out to be one of the more important steps done for Perl. Unsurprisingly, it will probably be up there along with Moose - both done by the same imaginative person.

Thanks for that.


Are you looking for help?

The dedication of people like you is one of the reasons I love this language. Perl 5 will never die.

Ready for some serious C hacking then? Looking forward to it! :)


I was thinking along the same lines when I read your post about p5mop’s problems and intermittent failure – that none of the insurmountable problems actually are, they’d just have to be tackled piecemeal with support from the core, but that this is possible, and that such efforts will, in sum and in good time, lead to a more malleable core (as indeed they already have, in other areas), without having to throw everything out and start over from scratch. But being as I’m not being close enough to either p5mop or the core, it was more on the level of intuition.

So it’s great to see that someone in the trenches can come to the same conclusion – not just because it validates my intuition, but because my intuition was that no actually, it is doable.


As to your point about you being impatient – that ended up ballooning from a comment into a posting over yonder. The punchline is that I think such impatience leads down the longest possible path, by far.

Thanks for taking another stab at this, Stevan. :)

This is really nice to see. I've been a Darkpanner for many years now and, while I would love to see Perl6 come to fruition, I'm forced to admit that I've given up on the thought of using it for anything practical any time soon. Watching 5.10 and onwards develop more and more useful core features and seeing an upwelling of support towards prioritizing features and modernity over backwards compatibility makes me really hopeful that Perl can remain relevant and perhaps *gasp* even become hip again.

Mind share, both from seasoned hackers and eager neophytes, is the most important thing to keeping your language going and, while Perl has always had the lion's share of the former type, its adoption by new users hasn't approached the likes of Ruby for some time (despite having better standards, documentation and module support, IMHO).

While killer apps like Dancer or DBIC make the community look great and lower the barrier to entry, it's the shiny new core features that can meet them in the middle and really stir people towards adoption. This, the above-mentioned method signatures, and better support for concurrency will be really nice to see, should they come to pass.


I'm really glad to hear you're willing to take on this challenge once again. I'm looking forward to seeing the resolution of the backcompat "problem." :-)

Leave a comment

About Stevan Little

user-pic I blog about Perl.