Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107455
User-Agent: Cyrus-JMAP/3.1.7-360-g7dda896-fmstable-20191004v2
Mime-Version: 1.0
Message-ID: <ed3411a8-2be7-4555-be8e-adb45462d992@www.fastmail.com>
In-Reply-To: 
 <CAJHtznweQuiXZff=O=d1=JNZCLU-+dJ=eZ49Ev0bc9zp1aC1Ag@mail.gmail.com>
References: <5d976928.1c69fb81.db3a8.78daSMTPIN_ADDED_MISSING@mx.google.com>
 <CAF+90c9uXdqJsTizLCca-AswenZDv9-6yw=ranATp3XoutHyxw@mail.gmail.com>
 <DM5PR06MB285747B847DE2D7320758C05DE9A0@DM5PR06MB2857.namprd06.prod.outlook.com>
 <e69fb3de-df5f-f77e-ad4e-61ea30185c5c@lsces.uk>
 <CAG9XoMR9DhKDwS1moH_9pjDNyZQ70ER5_stNs_GxQFucZ+ar7A@mail.gmail.com>
 <413d377a-4ce1-a521-0cb4-5bb37e84c257@gmail.com>
 <6DFA91F7-0005-453E-A314-A5DFE1A4D3D3@newclarity.net>
 <CAHN63oN3cgGaaWhYhLUVBAgRsi7d-eLODfhLGBOJetFh98zWQg@mail.gmail.com>
 <D2050867-9A1B-45D1-A51E-F7AFEE47DD69@newclarity.net>
 <CAJHtznwX-V8KKSyqir-BQBeaovP3+a6-EoafOFxpgGwAqth3sg@mail.gmail.com>
 <82012CD7-088D-4010-922E-AD54186AE37A@newclarity.net>
 <CAJHtznweQuiXZff=O=d1=JNZCLU-+dJ=eZ49Ev0bc9zp1aC1Ag@mail.gmail.com>
Date: Wed, 09 Oct 2019 11:58:26 -0500
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Internals "camps"
From: larry@garfieldtech.com ("Larry Garfield")

On Wed, Oct 9, 2019, at 2:50 AM, Zeev Suraski wrote:

> As I wrote a couple of weeks back, before we agree on the principle - =
that
> these contentious, breaking-for-no-new-reason proposals can=E2=80=99t =
be forced on
> everyone but we need to make it opt-in, I don=E2=80=99t think formaliz=
ing it into
> an RFC would help.  I could be wrong, but I think we=E2=80=99re curren=
tly lacking
> in good will on the other camp, which appears to feel a lot more
> comfortable to just go on producing contentious proposals day in and d=
ay
> out, and live with whatever sticks.

Tangent: I think it's a mischaracterization to divide opinions about PHP=
's future into "two camps", one of which wants to defend BC and never ch=
ange anything and make the language as loosy-goosey as possible, and one=
 that doesn't care about BC and wants to turn it into Haskell.  Those ar=
e hyperbolic and incorrect descriptions of where I see people standing, =
and creating that "two warring camps" impression only makes the question=
 about how PHP should evolve harder to resolve.

There are several distinct axes of philosophical debate, and they do not=
 necessarily correlate at all. =20

1) More BC protection vs less.
2) More opt-in "syntactic error checking" (eg, typing) vs less.
3) Fail hard on error cases vs "assume what was probably intended".
4) More "simplify common tasks" sugar vs less.
5) "performance reigns supreme" vs "spending performance to get usabilit=
y is a good tradeoff".

And probably many others I can't think of right now.  Those various axes=
 do not all correlate, and I suspect all 32 combinations of answers to t=
hose questions are represented by someone on this list, even before gett=
ing to the fact that they're all scales, not binaries, and some overlap =
in interesting ways (eg, failing hard is in some cases a BC break, other=
s not).

Zeev, you're very strongly and vocally on the "more BC protection" side.=
  That's fine; I agree with you, by and large.  But lumping "pfft, BC" i=
n with "moar types" and "fail hard" and "moar sugar" and then dismissing=
 them as "the other camp" does not advance the cause of BC protection, n=
or does it advance the cause of Internals not being a running gag of dys=
function, nor does it advance the cause of making PHP a better language,=
 for any definition of better.

As long as "anyone is allowed to propose an RFC", we *will* get RFCs tha=
t go against the informal consensus.  Over time, that informal consensus=
 will thus shift.  That is an inevitable and unavoidable result of PHP's=
 loosey-goosey structure.

If you want to really protect BC, the way to do that is to actually put =
guidelines in writing that people have to read before proposing an RFC, =
and that we can point to when people ignore them anyway.  But "that's ho=
w we've always done it, no it's not written down but we really have" is =
an approach doomed to not only fail, but to maximize the amount of strif=
e as it fails.  Let's please not do that.

And developing such guidelines absolutely positively cannot happen on a =
public asynchronous mailing list.  I've been through such processes enou=
gh times to know that is the worst possible way to do it.

--Larry Garfield