Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124073
Content-Type: text/plain;
	charset=utf-8
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.8\))
Subject: Re: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of
 ES6 from JavaScript
In-Reply-To: <af6030af-c0c4-4ef1-b241-82d4b0ca16ff@app.fastmail.com>
Date: Sun, 30 Jun 2024 02:40:10 -0400
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <5B2D9EAB-81E9-4450-A612-EA482DFDFE7B@newclarity.net>
References: <CAEUnE0fGZ3jFiBG=GyvnhBzH5a0iO4=n75PM=3+6zLAMrumEvA@mail.gmail.com>
 <0acedb8e-34be-4348-907b-4075cf7641fd@app.fastmail.com>
 <CAMrTa2Hhk31hgbr_fR7YAb94YPN030oTkvV5UD_ynRBM664QfQ@mail.gmail.com>
 <9c20b078-f82a-47fe-af23-2f3cdd233079@app.fastmail.com>
 <CAEUnE0fTwbc8LabwaNUxp9=vWCnes0E+E_zM+a_Ojera=jQSKg@mail.gmail.com>
 <A8486FCE-2788-47DF-9778-2872A3D32FC4@newclarity.net>
 <50529C6A-42BB-4D49-B720-FE1847577484@rwec.co.uk>
 <97EA49E2-43A9-42D2-B493-A6B66CC54914@edison.tech>
 <e1744ee3-61df-490e-8f67-c9d18ee50ffa@app.fastmail.com>
 <5B0CE06B-DB82-442E-A4A0-BF1B49F42246@newclarity.net>
 <af6030af-c0c4-4ef1-b241-82d4b0ca16ff@app.fastmail.com>
To: Rob Landers <rob@bottled.codes>
From: mike@newclarity.net (Mike Schinkel)

> On Jun 29, 2024, at 9:15 AM, Rob Landers <rob@bottled.codes> wrote:
> On Sat, Jun 29, 2024, at 13:43, Mike Schinkel wrote:
>>> On Jun 29, 2024, at 7:14 AM, Rob Landers <rob@bottled.codes> wrote:
>>>> You say it is impractical, you claim millions of users, but you =
don't address why the specific features are impractical.
>>>>=20
>>>> They are no more impractical than any other new language features =
PHP has added in recent years (and I am not being critical of what has =
been added, to be clear.)
>>>=20
>>> So far, nobody has shown how it is practical -- that is on the =
person proposing the RFC. Ideally, this would be it, you show why it is =
useful, how to use it, etc. But it is also political. You need to show =
why people would use it, why people would rewrite their entire =
application to use it (if the RFC calls for it), and so far, nobody has =
shown that other than "there are packages!"
>>=20
>> The problem with your assertion is that "impractical" is not a =
criticism that can be objectively determined to be true or false. It is =
just a pejorative used to stifle discussion which is why I responded to =
it as a did.
>>=20
>> Yes I agree that it is no proposers to show people why to use it, but =
it is unfair to proposers to give criticism that can only be classified =
as opinion.
>=20
> The RFC process is people problems, not technical ones. Thus they can =
only be solved by swaying people's opinions which sometimes involves =
technicalities. People have and will decline RFCs simply because they =
don't like it. It's that simple.

Absolutely. =20

But that argument encourages a focus on feeling and not technical =
objectivity.=20

If a proposer convinces everyone that their idea is great but ignores =
objective technical factors they were get an RFC passed that either =
cannot be implemented or worse actively harms the language.

I argue it is incumbent on those discussing RFCs to remain within the =
realm of the objectively quantifiable and to also expect to be =
challenged back when their challenges are not objectively quantifiabl,e =
such as when the challenge is in the form of an opinion-based =
characterization  (where "impractical" is an opinion-based =
characterization without objective criteria for any proposer to address. =
Rowan even acknowledged that his question might have been poorly =
worded.)

>>> You need to show why people would use it, why people would rewrite =
their entire application to use it (if the RFC calls for it), and so =
far, nobody has shown that other than "there are packages!"
>>=20
>> It seems you have not read any of the several other emails I have =
written to this list in the past several days that do far more than say =
"there are packages!"
>>=20
>> Please read them in full before making such further equivalently =
dismissive claims.
>=20
> My apologies if I've missed it, but I find your emails extremely hard =
to read. The extra indentation you do on your replies makes it show up =
as quoted text that I have to expand in my email reader. It may be that =
my email reader has hidden entire replies from you and I wouldn't even =
know it.

Interesting. My email style has always been to try to make my emails as =
scannable as possible and I have used intention for that. I never =
suspected that indented would have the opposite effect I intended.

I would never know that unless someone called it out, which you and =
Rowan have mentioned.=20

Thank you and I will try my best to avoid indentions in the future =
emails to this list.

>>> I cringed at this. There is no direct lineage though they borrow =
come syntax from C, and if you want to push it, you might as well say =
they're descendants of B which borrowed syntax from BCPL which borrowed =
syntax from CPL which borrowed it's syntax from ALGOL... eh, no, these =
languages are not related to each other. Inspired, maybe.
>>=20
>> Aside from your cringing, how does your pedanticism here move the =
discussion forward in a positive manner?
>=20
> This isn't pedanticism, it's just plainly incorrect. There's been a =
lot of that in this thread (I haven't been keeping track of who said =
what per-se), to the point where some of it can't be taken seriously, =
like composer taking the lock file idea from npm. Like, sure, let's just =
go about rewriting history in this thread too. Most of these assertions =
can be checked by simply doing a quick search before sending the email, =
but arguments based on lies/incorrect facts are not valid arguments. =
That is why I am pointing it out, so that you (or whomever) can come =
back with a valid argument.
>=20

It is not "incorrect" and these are not "lies."  We three were debating =
a characterization and characterizations are by-nature derived from =
opinion thus cannot be objectively judged to be correct or incorrect nor =
accurately designated as "lies."

To which I will restate: "How is your characterization of the =
relationship between Go and PHP vs. my characterization really relevant =
to this discussion, and how does it make positive impact on the debate?"

>> Again, you are making a statement that cannot be objectively proven =
true or false, and frankly I cannot see any way in which your argument =
here matters to discussion of modules.
>=20
> As someone who used to make a living porting things from one language =
to another, I can say, quite frankly, that this is objectively true.

<sigh>

I asked ChatGPT:

"If someone says "X and Y are alike" and someone else says "No, X and Y =
are not alike" and follows it up saying based on their experience that =
they know "X and Y are not alike" is objectively true, is it possible =
for them to be correct in their assertion that their claim is objective =
truth? Why or why not?"=20

ChatGPT responded =E2=80=94 in part =E2=80=94 with this:

"If the claim that "X and Y are not alike" is based solely on personal =
experience without clear, objective criteria or evidence, then the claim =
is more subjective. Personal experiences can inform perceptions, but =
they are not sufficient to establish objective truth without verifiable =
evidence."

And this:

"Conclusion

It is possible for someone to be correct in their assertion that their =
claim is objectively true if:

=E2=80=A2 There are clear, agreed-upon criteria for what makes X and Y =
alike.
=E2=80=A2 There is verifiable evidence supporting the claim that X and Y =
do not meet these criteria.

If these conditions are met, then the claim that "X and Y are not alike" =
can be objectively true. Otherwise, if the criteria are ambiguous or the =
claim is based solely on subjective experience, it cannot be considered =
an objective truth."

Full reply here:  =
https://chatgpt.com/share/b8ae223c-5d53-4e84-8353-79d2ac15dd6a

I see no "clear, agreed-upon criteria for what makes X and Y alike" nor =
"verifiable evidence supporting the claim that X and Y do not meet these =
criteria." =20

As such, given these criteria, no, it is NOT objectively true.

Still, once again, "How is your claim of being the exclusive holder of =
objective truth between you and me really relevant to this discussion, =
and how does it make positive impact on the debate?"


> I'm very much not "inside the gate."

Again, you debate irrelevant characterizations.=20

> I am not a voter, I just like PHP, trying to make php even better by =
proposing RFCs and helping out other people with RFCs. I'm not paid to =
be here, I'm here because I want to be. I have very limited time to =
spend here, so I'm not consistently involved. In fact, some of my ideas =
are "against the grain" of the current voters as well; this is fine. =
Success isn't the only way to make progress.

For a third time, "How does your claim of not being a voter make =
positive impact on the debate?"

> There is nothing objective about the RFC process...

Glad to understand that you do not see any value in focusing on =
objectivity quantifiable aspects of a technical debates. Noted.


> If you go create an RFC right now, you're faced with the following =
guideline in the template, before you even write a word:
>=20
>> Quoting [[http://news.php.net/php.internals/71525|Rasmus]]:
>>=20
>> > PHP is and should remain:
>> > 1) a pragmatic web-focused language
>> > 2) a loosely typed language
>> > 3) a language which caters to the skill-levels and platforms of a =
wide range of users
> Your RFC should move PHP forward following his vision. As =
[[http://news.php.net/php.internals/66065|said by Zeev Suraski]] =
"Consider only features which have significant traction to a
> large chunk of our userbase, and not something that could be useful in =
some
> extremely specialized edge cases [...] Make sure you think about the =
full context, the huge audience out there, the consequences of  making =
the learning curve steeper with
> every new feature, and the scope of the goodness that those new =
features bring."

Per my characterization I see that everything I am proposing fits into =
that classification.

However, based on my recent experience with your propensity to argue =
against the characterizations made by others I feel certain you will =
tell me that my characterization "wrong" and that you are the only one =
between the two of us who could possibly be "correct." =20

Such is life I guess. =F0=9F=A4=A6=E2=80=8D=E2=99=82=EF=B8=8F

> The reason people are challenging this so hard is that last sentence: =
"Make sure you think about the full context, the huge audience out =
there, the consequences of  making the learning curve steeper with every =
new feature[...]". This objectively WILL make the learning curve steeper =
with two different execution modes. People are asking you if it is =
"worth it" to learn two different modes, so prove it is worth it. People =
are asking you if it is "worth it" to rewrite billions of lines of code, =
so prove it. Or ... pivot and think about how you can change your =
feature to work within the current syntax.

Are you done?  Have you finished mischaracterizing my arguments, e.g. =
"(having to) rewrite billions of lines of code?" And are we free now to =
objectively discuss a proposed feature set? =20

Or do we need to continue to debate characterizations that are =
irrelevant and orthogonal to any potential proposal?

-Mike=