Perl7 is a fork of values
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 list 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
- Extensibility
- Stability
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 compatibility.
...
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:
- Robustness
- Portability
- Stability
These are the values of sysadmins. Environments where working things have to keep working.
Whereas for example the Mojo community generally seems to prioritize
- Approachability
- Expressiveness
- Velocity
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.
Perl seems to have a choice between certainty and uncertainty, and in this case, I'll pick uncertainty. Certainty is Perl continuing on as it has down the road to irrelevance and stagnation as the population of folks who are still trying to keep the lights on and put out fires dwindles to nothing.
No program is an island, entire of itself; every program is a piece of the system, a part of the main. I don't think it is important to certainly be able to run a Perl program I wrote in 1998, unmodified, on an operating system written for hardware that hasn't been manufactured for 20 years. Every other part of that system needs to also work, not only the Perl interpreter. When the EDO RAM chips die, I'll have to find replacements or my Perl program is useless. When the ISA video card and network cards die, I'll have to find replacements or my Perl program is useless. When the OS or some other program on the machine stops working, my Perl program is useless. I don't need to be certain that I could run a useless program.
So, in truth, there is no certainty. We can keep maintaining our outdated technology and dance to obsolescence while the ecosystem moves on without us. Or, we can accept that uncertainty is all that exists in technology and take measured, considered steps into that uncertain future, leaving some parts of the past behind.
preaction, if you want uncertainty and to break the language and the community, fork it/off.
Great commentary. I agree that the elation to change things in perl's core that the perl7 announcement has created will fork whats left of the community and douse the last embers of perl
I share the concern about self appointed committees, and its something I have been vocal about.
At the TPC we heard & saw first hand that Perl the community see's the role of TPF's board differently to how it sees itself.
Perl's slow decline was overseen by this "hands off" approach by the self appointing TPF, whilst development is at the whim of anyone in #p5p.
This "model" has left Perl in the dust, as Python has become the dominant language, despite it's many foibles.
In that video, Bryan Cantrill makes points that don't support the ones you make here. He says that values need to adapt to people and the times, and the people leave when their values aren't represented. His through line is that you adapt or die. From re-reading your post several times, I think you are saying the opposite and have misunderstood the presentation.
He also says that elections don't decide values and democracy is not necessarily leadership.
Elections allow people to express their values by selecting their leaders.
People overwhelming migrate from countries without democracies in to countries with democracies.
In perl their are no elections and leaders appoint each other.
The people have left perl for other languages.
I don't think your assertion tracks. By your logic, anything run by a BDFL would be abandoned. I don't think that belief matches reality.
> By your logic, anything run by a BDFL would be abandoned.
The "B" in "BDFL" stands for benevolent. Neither Sawyer, nor you Todd, exhibit this quality.
You will support reforms then I assume. Giving members of the perl community a voice? TPF membership, TPF elections etc.
The current anti-model of governance has been used throughout its fade to near irrelevance.
If you sat people down and said "how should we run our language in 2020" it would never look like what TPF and #p5p look like.
Let's have a modern governance system for modern perl.
Python did it, we can to.
Agree with Dean. Todd, Do you support reforms that provide greater inclusivity to those in the community, giving us a voice too?
All elections depend on people standing up and being elected. Not all the people who stand up to be elected should be.
Sorry just thinking of my current government.
I agree that there should be a democratic mandate and a governance structure and some system of controls to prevent idiosyncratic systems of governance forming.
However systems are "made by the people who turn up and do things. So did we fail you, or did you fail us? I don't know." However I do want you to turn up.
It is good to have change. It is good to have evolution. It is good to hear real passion from people.
What makes you think you didn't have a voice? That's a genuine question, as I was appointed head of one of the committee's and aside from time constraints I don't think I have purposefully not listened to anyone speaking to me.
Maybe our failure here is that we didn't give you a better way for your voice to be heard. For that. I am truly sorry.
You have a voice.
I try to read as much of the comments and posts as is possible. But you can find me and I will respond. So tell me how we can do better? I have a fairly tidy platform to promote a voice. Let me help you.
One note: The committees are not wholly self-appointed. Neither is the board. But it is not very well publicised or has any rigour or review. That should change.
Also. This borders on almost assuming nepotism. That's not the case. Most of the work has been done not by self-appointed, but because no one else was doing it.
That's likely not the best solution. But nothing gets done if no one turns up to do it.
Perhaps, in evolutionary terms, the next generation of something is rarely compatible with the previous, as that isn't how evolution succeeds. It might be how the Royal Families of Europe in the Middle Ages operated though.
Going to have to disagree with you on that Riba - not in regard to your underlying stance, or any technical matter in general, just to the assumption of an absolute,
I have known both Sawyer and Todd to be benevolent and kind. I have never assumed they are angels who tread the light clouds of the fantastic; but to state they have never exhibited the quality of benevolence, that's bollocks mate. Also, in regard to BDFL - neither of them are, so double oops, still doesn't work as a never - maybe James Bond can give us all a Never Say Never Again.
The use of a reduction to the absurd is a fair technique but it doesn't scan so well here. As it isn't their nature and they don't have that position.
I am not seeking to call you out. I just didn't see this as anything but ad hominem. I see you as more than that. So maybe that's my fault. I see you as making a better response than this.
I have no membership in TPF either other than being a conference organizer (which carries no membership). I openly welcome you to come volunteer to organize the next TPC (online or in person) when it happens next June.
1st off, I'd like to make sure you understand that TPF is a support organization for Perl and Raku and has no governance over either.
I think an absolute democracy is a formula for disaster. To my knowledge, no government runs that way today.
That said, I very much think that Perl needs a better governance model than "Larry gets absolute veto". The reality is this hasn't been the situation for over 20 years. Larry is also on record (at least he felt this way back in 2000) that Perl 5 Porters isn't the best way to develop Perl.
This isn't really the best forum for discussing what it should be. I would be up for a conversation on the Perl 5 Porters mailing list of what you would like to see instead. I too think it is past time.
I hope to see you there! Todd
Thanks! My comment was not about Perl's governance so much as most other open source projects. Some have a complex governance but the majority are managed by a select few. Isn't this the common case?
Okay there is no +1 on this platform, but this is my +1
it's usually the evolved state. Which is why structural criticism of form sees it as the parochial or abusive state.
It might be so.
However, assuming it to be the implied rather than the assumed (or default) is perhaps a misunderstanding.
the internal sarcasm here is those who wish to rebuild, to evolve, object the changes to the original form. Those who have built and maintained, object to the adherence of a constant, or common, universal state.
Honestly i think Gloucester would be looking sideways at flies, wanton boys and gods right now.
This venue seems as good as any to voice your support for the current "governance model", or your ideas for how it could be remodeled to better serve those few people and businesses still loyal to Perl.
So as a person who has toiled for a foundation that doesnt even extend membership too you, why not support opening TPF up to membership? Who in turn electing board members? Why not support a model that engages with the perl community and the few remaining businesses that rely on perl?
In 2020 aren't there better models for enagement than saying "join this email list and read this irc channel".
The current "model" has resulted in Perl about to fall off of TIOBE as companies abandon it, notwithstanding no significant feature gap compared to other comparable languages.
So whilst there is enthusiasm for change - as the above post, prior posts and the conversations on reddit and other forums demonstrate - there is rapidly declining confidence that making changes is being managed in a consultative, constructive and open way.
Put simply. Which model is more likely to grow perl?
I think the current Perl 7 plan is very heavy for the resources available to the Perl community.
Perl 7 will succeed if many people welcome it and everyone supports it.
However, I think the remaining users of Perl will remain because of the stability of that Perl.
If, in reality, the move to Perl 7 doesn't work, I think it's an opportunity to reconsider adopting "use v7".
I have a very similar thinking of Leon.