Before reading this, you should watch this video where Bryan Cantrill explains a value-conflict between Joyent and Node.js, I believe we have a similar problem.
In it he defines a lit of project values:
All these values are important – but they are in tension. In the end one has to choose between them.
Perl’s has traditionally prioritized certain values over these others, and in my experience these are:
Expressiveness is probably the most obvious one.
Extensibility is probably less obvious, probably because it was less of a concious choice, but feels like the right pick for a language that has several OO frameworks and custom keywords.
Stability, in particular backwards compatibility, is thoroughly embedded in our policy document:
Lately, ignoring or actively opposing compatibility with earlier
versions of Perl has come into vogue. Sometimes, a change is proposed
which wants to usurp syntax which previously had another meaning.
Sometimes, a change wants to improve previously-crazy semantics.
Down this road lies madness.
When in doubt, caution dictates that we will favor backward
Using a lexical pragma to enable or disable legacy behavior should be
considered when appropriate, and in the absence of any pragma legacy
behavior should be enabled.
No matter how frustrating these unintentional features may be to us
as we continue to improve Perl, these unintentional features often
deserve our protection. It is very important that existing software
written in Perl continue to work correctly.
More than any other major scripting language, we value keeping code working. Where other similar languages (especially Python) are breaking relatively common constructs regularly, we generally tried to limit that to the margins (though there’s certainly some breakage in any major release).
That doesn’t mean all subcommunities share exactly the same values though. I’m involved in the toolchain, and in the toolchain we have very specific values:
These are the values of sysadmins. Environments where working things have to keep working.
Whereas for example the Mojo community generally seems to prioritize
These are the values of modern web development, where change is the only constant.
And mostly, that difference is fine. It helps a lot if a community’s values overlap with the language values, but different communities can have different values without biting each other.
That said, Perl has been having an internal conflict over its values and where to take the language itself. This tension has existed for several years now, and is focused primarily around stability. The primary axis of tension is approachability versus stability.
Simply put, should new features and defaults be guarded by a version or feature guard (e.g.
use v5.34 or
use v7) (stability), or should they be enabled by default in the next perl version (approachability). 7.0 doesn’t aim to bring new features, it doesn’t enable us to do anything that isn’t possible without it (other than not writing that guard). Instead, it aims to change perl culture as we know it. The whole point of perl7 is radically choosing approachability over stability.
The crucial thing to realize here is that that means that perl7 is not just a fork of the interpreter, it is also a fork of our community and our ecosystem. To some extent that fork can be postponed until perl8 drops perl5 compatibility, but given this new course it is inevitable. Some will join this brave new world, and some will not.
To make this fork of values complete, even the values of governance are completely different. Where perl5 had perl5-porters, a mailing list that was open to the entire community (and historically perhaps a bit too open), perl7 has a steering committee whose membership is invite-only and that only posts summaries of its activities to p5p.
And while everyone is wondering where perl7 is going, the other crucial question is where perl5 is going; will it stop where it is now (the current official plan), will there be a 5.34 (something I have repeated argued for because it makes no sense for the sunsetting release to have experimental features, and is lacking a perl5 executable out the box), will perl5 development continue as it did before? This is something that isn’t talked about much and I’m not sure yet what will happen, but I am pretty sure that decision shouldn’t be taken by the people who don’t want to use it.
I don’t know where we’re going. I’m not even sure if this forking is good or bad in the long run (it could be good if managed well, but so far it isn’t). And that terrifies me.