Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107526
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Message-ID: <C50AA20C-25AA-4C31-8E1F-38183E1AEC6A@newclarity.net>
Date: Fri, 11 Oct 2019 16:38:53 -0400
Cc: php internals <internals@lists.php.net>
To: Chase Peeler <chasepeeler@gmail.com>
Subject: "Fighting about analogies"
From: mike@newclarity.net (Mike Schinkel)

> On Oct 11, 2019, at 1:44 PM, Larry Garfield <larry@garfieldtech.com> =
wrote:
>=20
> 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!  :-)

> On Oct 10, 2019, at 1:03 PM, Chase Peeler <chasepeeler@gmail.com> =
wrote:
>=20
> 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 =E2=80=94 or perhaps ironic =E2=80=94 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.=20

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.


> On Oct 10, 2019, at 1:14 PM, Bishop Bettini <bishop@php.net> wrote:
>=20
> 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. =20

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 =E2=80=94 including non-voters =E2=80=94 before =
an RFC can be submitted? (IIS for short =E2=80=94 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?


> On Oct 10, 2019, at 1:03 PM, Chase Peeler <chasepeeler@gmail.com> =
wrote:
>=20
> The fact is, when there is a compromise that makes sense, people =
usually suggest it.=20

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. =20

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.) =20

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.=20

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.

> On Oct 10, 2019, at 4:27 PM, Mark Randall <marandall@php.net> wrote:
>=20
> On 10/10/2019 20:59, Walter Parker wrote:
>> They will either be stuck  on an old version of PHP or have to pay to =
update the code.=20
>=20
> 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.

> On Oct 10, 2019, at 1:03 PM, Chase Peeler <chasepeeler@gmail.com> =
wrote:
>=20
> 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.=20

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.=20

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.=20

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.=20

...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. =20

As a quick aside, are you really employing the "But this is the way =
we've always done it" argument? =20

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.=20

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.

> On Oct 11, 2019, at 1:20 AM, Stephen Reay <php-lists@koalephant.com> =
wrote:
>=20
> If the only reason to keep a dangerous operator is =E2=80=9Cwell a =
small subset of people use it=E2=80=9D, 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.

> On Oct 11, 2019, at 1:40 AM, Walter Parker <walterp@gmail.com> wrote:
>=20
> Personally, I=E2=80=99m 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