As engineers we are all used to making quick judgements about what is right about code and what is not. We are used to parsing though lines of source to spot the bugs, the security flaws, the use of outmoded or obsolete idioms. And we can learn to be rather picky, and sometimes we have a hard time distinguishing between a real problem and our personal preferences. Or we pointlessly object to something that has several equally good (or bad) options and no fair way to pick one or the other.
Hold that thought.
As people navigating complex and everchanging networks of interpersonal interactions, we learn (hopefully) that group choices made in the face of numerous and possible equally merited options require at least a minimal ability to separate in our heads those choices worth fighting to the bitter end for and those choices where the progress of a decision made is more important then our personal preference.
Engineers tend to have a hard time with that last bit, "where the progress of a decision made is more important then our personal preference."
I have said previously that I see the Perl community as a sort of anarchisic meritocracy. We value "There is more than one way to do it" and that leads us to endlessly tinker with our language. It does however lead us to suffer from a sort of amplified version of the classic engineer's problem described above. More so than other languages we have a hard time coming together for critical choices about possible futures.
It is said that a compromise is the choice that everyone dislikes but nobody hates. Crafting a compromise typically begins by looking at the positions of all the stakeholders and trying to boil it down to the bits that overlap the most. In doing so we tend to leave out a lot of good ideas that have merit but not enough critical mass to warrent inclusion. We try to craft a narrowly scoped solution that everyone dislikes because it doesn't give them exactly what they personally wanted, but most don't hate because they see the choice moves the project forward and the only other option is to Do Nothing.
Compromises fail when the option of doing nothing is see as less damaging that the compromise proposal. Until the option of doing nothing is so scary and damaging to all the stakeholders, that is often what they will choose to do.
I personally believe that the Modern Perl movement stands on the edge of where doing nothing is no longer an option.
We've had endless discussion about Perl5 branding, about how to clarify the relationship between Perl5 and Perl6, about how to show the world that Perl is a viable and ongoing concern. Matt Trout has floated a proposal that is narrowly scoped to achieve a few small but critical things:
- It will allow Perl5 to reclaim a major version number.
- It will clarify the relationship between Perl5 and Perl6.
- It will give the Perl5 community an opportunity to regain control of our branding.
His proposal is modest in scope. Basically we just all agree that Perl revision 5 version 20 gets the friendly name "Pumpkin Perl version 20". This is what you'd see when you type "perl -V" and it would be great if over time we'd synchronize all the externally facing documentation to reflect this. And we all need to start saying it. But under the hood, for the purposes of declaring Perl version requirements it would still be considered Perl revision 5. So you'd say "use perl 5.xxxxxx" in your code.
Yes it is a small proposal. It doesn't give Perl a MOP, or threading, or better asynchronous support. It doesn't fix the mess that smart matching has become, nor does it deprecate @your_list_of_hated_ancient_perl_crap_feature. Also, it requires that a certain effort is taken to seize the moment and to use the rebranding effort as a chance to reintroduce Modern Perl to the world. It needs to lead us to think deeply about how Pumpkin Perl should evolve to meet the changing state of the art in programming. The proposal in itself does not indicate how to do this, so there is much that is still left unsaid, undecided and to be done. In other words, the possibility of failure is still a possibility.
When you hear this proposal I know your instinct is to say, "Yes but...". "It would be a good idea but only if..." "But don't we also need to...?" Like I said, as engineers we have to fight our urge to be picky and to learn to see the difference between real problems and personal preference. Between problems and solutions nobody can agree on. Often a compromise leaves much that is deferred to a later date.
Please stop for a moment and recall that we've been debating this for years, possible more than a decade. I think at this point its all been said, resaid, screamed and anguished over, shouted and forgotten. Several times.
Pumpkin Perl version 20 is a compromise that nobody is likely to love. However over the decade plus that I can recall this issue bouncing around the community, Matt's proposal is the first and only one that is scoped in such as way as to be possible, and it is the only idea I've heard that has gathered some critical momentum behind it. Not enough yet to make it a go, but more then any other idea that I have heard of, which means its possible the best compromise you are likely to hear for long time (if ever).
You need to ask yourself is this compromise choice, as it currently stands, without modifications or continued tweaking, something you can live with? Is it better than the option of doing nothing? Is it a rational distilation of the hopes and aspirations of the community? Is is something that on its own will move us forward? Is its tightly and carefully scoped proposal something that merits a yes or no on its own?
I believe so, and I hope that before you say, "But only if...", could you take a step back and rethink the proposal on its own merits. I know that is not easy, and that we all have objections and that we all want to be heard, and have our opinions valued. And we all have a certain amount of hubris in thinking that if only everyone thought the way we think the world would be better.
I have heard from several people that Matt's modest proposal is too small to achieve anything, that it could only be worth something as part of a package of larger and more ambitious things (and probably things we will not do in any forseeable future if we stay on the path that our history indicates is likely).
There is some merit to these objections, but I feel certain that if the proposal is adopted it will accomplish one very valuable thing, something possibly of greater value that all the other things we hope and dream to have, because it is the one thing we must have if we are to claim all the rest.
It will show the world, and it will show ourselves, that we can come together and make a choice.
The ability to choose and to move forward is more valuable than any set of technology features. It is the thing that without nothing can occur. Coming together to grit our teeth (or hold our noses) and make a choice will do more to show the world that the Perl community is a viable and ongoing concern than would Perl r5 v20, including a MOP, or method signatures or better threading, or anything. History clearly teaches us that a community that cannot rise to the moment and choose is one with no future at all.
I strongly believe that Matt's proposal to rebrand Perl revision 5 as "Pumpkin Perl" is a strong one that will lead the Modern Perl movement to the next level.
There's an updated link by mst worth looking at http://shadow.cat/blog/matt-s-trout/pumpkin-perl-breakdown/