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
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.