Could y'all please go fight about analogies in another thread, rather than one that was explicitly trying to get away from that silliness? Much obliged.
Done! :-)
Mike - I have no issue with compromise when it makes sense. Sometimes, though, it doesn't. I'll paraphrase an example given by Jonah Goldberg. One side wants to build a 100 yard bridge to an island. The other side doesn't think we need to build the bridge because we don't need to go to the island. What's the compromise? Building a 50 yard bridge?
It is interesting — or perhaps ironic — that you choose to quote an individual known for staking out controversial no-compromise positions in governmental politics in order to attempt to justify the existence of a no-compromise approach to issues that affect a large number of people where many disagree with the solitary approach proposed but would be open to exploring ways to meet their underlying objections.
To him I would say that same thing; black-and-white approaches to issues ends up ensure that everyone is worse off. However ask "What is the underlying motivation here and can we find a way to address your legitimate needs/concernss while at the same time not trampling on my legitimate needs/concerns?"
Basically most all RFCs are great examples of X-Y problems. Rather than have discussions to identify legitimate cases of "Y", someone proposes "X" and then people dig in based on their unstated/understated concerns rather than FIRST identify mutually agreed problems and THEN collaborate on a solution.
No. The compromise is funding a ferry system. Or laying Internet between them. Or a passenger pigeon mail route.
Sometimes compromise requires deep discussion about the motivations for each side and coming to a lateral, mutually acceptable, solution.
Bishops response perfect illustrates the fallacy in binary thinking given Goldberg's example.
But we'd rather not discuss motivations and just bicker about the surface results. I.e., argue the X, rather than the Y, of these little XY problems we're solving.
Yes! Basically most all RFCs are great examples of X-Y problems.
Rather than have discussions to identify legitimate cases of "Y", someone proposes "X" and then people dig in based on their unstated/understated concerns rather than FIRST identify mutually agreed problems and THEN collaborate on a solution.
Maybe we should create a pre-requisite for RFCs, to first require an "Issue Identification Statement" be drafted first and signed by a minimum number of people — including non-voters — before an RFC can be submitted? (IIS for short — yes, pun intended. :). We could also allow dissenters to write up a response that would be group with the statement on the wiki. Doing this might help ensure that the problem is one that people have agreed need to be solved before debating solutions ad-nauseum?
The fact is, when there is a compromise that makes sense, people usually suggest it.
That has not been what I have witnessed. Reading this list for ~3 months now, I have rarely seen people suggest compromises, and when they do it is just one or two people in a discussion with 10 or more people. What I am suggesting is that we consider as possibly part of a future CoC that "How can we compromise on this?" Is a question everyone is expected to ask and everyone is expected to offer what they view would be a compromise.
Of course, saying that I am expecting that more than one person will say this would not be workable because they do not see how (are unwilling?) to compromise on many issues.
To the side that says "There is absolutely no reason we need to go to, or communicate with, the island in the first place," a ferry project isn't a compromise. The position of the "anti-bridge" builders isn't because they are against building bridges - it's because they are against spending resources on attempts to get to the island in the first place. The other side might have valid arguments on why we need to get to the island, but, just proposing different ways to get there isn't compromising with the side that doesn't want to go there.
And that is a perfect example of the type of approach that cause problems in all communities; someone who is intransigent on a topic and unwilling to consider the wants and needs of others, thinking that the only solution is one that addresses their own wants and needs, others wants and needs be damned.
So the question I pose is, in a community when one contingent says "Lets find a compromise" and the other says "My way or the highway," who should prevail? Is the ones willing to find a workable solution, or the ones who are dug-in and not willing to compromise.
For me, the answer is easy; the ones who are willing to compromise should get the upper hand because only the former are considering the needs of all stakeholders.
That said, your Goldberg example does not fit as an analogy for BC concerns. The proposed bridge would fit the analogy of a new feature, not a deprecation. So let me rework your analogy to make it fit better, where all parts of my analogy have a direct analog (in paranthesis) to the BC concern:
There is an island with an existing bridge that is home to a large number of people (untold millions of people running existing PHP apps), and numerous very rich people (internals@ members). Unfortunately the bridge (selected feature to be deprecated) has become a magnet for suicides (concerns of misuse that can harm the program's owner), and most everyone wants to address that. Further, the rich people really hate the the island has become a weekend getaway (poor coding practices) for people of lesser means (userland developers.)
So the rich propose that the bridge be torn down (features to be deprecated) and replaced with a ferry (tooling to fix the problems), and being rich they know that with the lack of a bridge generally won't affect them their boats and helicopters (their existing paid development teams.) For the few times they need to drive off the island they are willing to put up with the ferry in order to get the weekend getaway people off their island.
Unfortunately this will create huge hardship for all the other people living on the island, many whose families have been there for generations (legacy apps where the original developer is long gone) and many of those people who have jobs off the island (small businesses to run) where the ferry is unworkable, and with no financial means to have their own boats and helicopters (don't have the budget to hire developers to fix their WordPress site.)
These rich are also very intractable on this position and have rejected all proposals by the rest of the islanders to find a workable solution to the suicide prevention (staking the position that an RFC is black or white) such as installing high fences on the bridge to make jumping almost impossible (deprecating with an explicit mention that removal is currently unplanned) and these intransigent rich be contribute to the campaigns of local politicians (voting on RFCs) to get their way.
OTOH, the rich do invest is a PR campaign, running ads (emails to this list) explaining how the old bridge was ugly (how much better PHP will be after the deprecations) and how the result will be no more suicides (no more userland developers shooting their client in the foot.)
But for those who are cynical, they view the motivations of the rich having nothing to do with suicide prevention and all to do with making their island more exclusive (making PHP a more strict, enterprisey type of language.)
Whatever the case, it is clear the rich people are not concerned with the hardships these changes will cause for others of lesser means (websites, scripts and apps that will be broken by the deprecation and that those who depend on those apps will have to pay to have fixed), they are only concerned with aspects that affect them directly (having PHP become they language the deprecation advocates want it to be)
So what we have here is something that has existing and is being taken away. That fits the deprecation/BC model better than adding a new bridge.
That said, I do agree with Goldberg's example if we are talking about new features. But we are not. We are talking about taking away things that existed for people, not adding new things. Very different scenarios.
They will either be stuck on an old version of PHP or have to pay to update the code.
If you're getting stuck on a island after being given 4 or 5 years warning that the bridge to it will be closed, after being pointed to the ferry, given free tickets to that ferry, and being told it will continue to run long after, that's your own fault.
You are saying it is their fault for their family havIng lived there for generations, and now someone else who does not share their concerns is advocating that their home be isolated from the mainland because a bridge is being removed that has exist for decades?
No, it's their right to advocate and say "No, I object to you tearing down the bridge that would isolate me and my family's home of generations from the mainland." Just because a rich construction developer wants to build a waterfront property where the bridge exists does not mean they island's residents should accept that they will have to leave in 4 to 5 years.
And yes, we are both stretching the analogy here, but as you used it to make a point I am using to make the counter-point.
One example being Zeev's proposal on the RFC to raise the error levels of undefined variables to making it opt-in. Zeev's stance on the issue was that we shouldn't do anything that was mentioned in the RFC, but, he felt that a compromise would be to at least make those changes opt-in. That proposal was rejected by pretty much everyone. That's probably why it wasn't proposed this time, either.
Perfect example. Yes, and most everyone who rejected his proposed compromise did so either silently or did so without any justification for what Zeev's suggestion was not workable. Or if they did, I did not notice it, and I have read all the emails to the list for the past ~3 months.
As for this particular RFC, I think it's a pretty binary decision. Deprecate them or don't.
There again, you are choosing to view this is a binary option when other options logically/technically exist.
As long as I've been involved with PHP, nothing is ever deprecated unless the eventual goal is to remove it. I could be wrong, and welcome examples where we've deprecated something where the end goal wasn't removal.
Ignoring the fact that Bishop gave you just such an example in short tags...
Assuming I'm correct though, that provides a pretty strong reason for why we wouldn't start doing it now.
...the only reason why we "cannot" do this is because you some people have unilaterally decided it is not an option, but not for any tangible reason.
As a quick aside, are you really employing the "But this is the way we've always done it" argument?
Even the Wikipedia definition leaves open deprecation w/o removal as a viable option by use of the word "may" in this quote:
...deprecated status may also indicate the feature will be removed in the future.
There is no technical, logistical or logical reason we cannot deprecate a feature with an explicit statement that says this deprecation is NOT intended to be used as evidence for a future RFC that removes it, but that instead a future RFC that votes to remove it will need to set the same bar for removal as it would have required before the RFC was passed.
Doing this is a clear workable compromise to everyone except those who are uncompromising. It would not break existing code but it would signal to developers to stop using the feature and give other developers reasons to get their colleagues to stop using the feature. Fear of potential future removal is often just as helpful as actual removal.
What I do not get is why people prefer the non-stop debates that resulting in PHP advancing slower than all its major competition rather than find a way to work together by acknowledging the concerns of other so that we can more PHP forward.
If the only reason to keep a dangerous operator is “well a small subset of people use it”, marking it as deprecated is how you signal to those people that the feature will likely be removed in a future version.
I would argue that deprecation can be used as a signal to userland that it might be removes WHILE AT THE SAME TIME signal to internals@ that specific deprecations do not imply a plan and tacit approval to deprecate. Otherwise, the deprecation will almost certainly be used as justification for removal in the future w/o thoughtful analysis of the impact on userland.
Personally, I’m thinking of moving my backend work to something else, like
Go. Rob and his team seem to have a good handle on things.
Absolutely!. I have already started that path, a year ago.
Anything new I can write in Go I write in Go rather than PHP because I have little faith that PHP will move forward given how dysfunctional its process for improvement appears to be.
Unfortunately as I still specialize in WordPress there is no getting away from PHP.
#fwiw
-Mike