Re: [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript

From: Date: Sun, 30 Jun 2024 07:17:15 +0000
Subject: Re: [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript
References: 1 2 3 4 5 6 7 8 9 10 11 12  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message
On Sun, Jun 30, 2024, at 08:40, Mike Schinkel wrote:
> > On Jun 29, 2024, at 9:15 AM, Rob Landers <[email protected]> wrote:
> > On Sat, Jun 29, 2024, at 13:43, Mike Schinkel wrote:
> >>> On Jun 29, 2024, at 7:14 AM, Rob Landers <[email protected]> wrote:
> >>>> You say it is impractical, you claim millions of users, but you don't
> >>>> address why the specific features are impractical.
> >>>> 
> >>>> 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.)
> >>> 
> >>> 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!"
> >> 
> >> 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.
> >> 
> >> 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.
> > 
> > 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.  
> 
> But that argument encourages a focus on feeling and not technical objectivity. 

I get it man. I really do. I have gone off on rants on this list a couple of times because people
refuse to help make things better if they don't like it. They just say "I don't like
it, good luck" without much constructive feedback like I've (hopefully) been trying to
give here. I don't like this feature as-proposed, but maybe if I nudge you and whomever in a
different direction, you'll come up with something I do like. But if I don't participate,
it is literally a waste of everyone's time. 

I'm actually on your side. I do want modules, but the devil is in the details....

> 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.

This has happened a few times now...

> 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.)

Yep. This happens, too. See my operator overrides RFC right now. I'm actively trying to cater
to all the people who voted "NO" on the previous operator overrides RFC -- which means
doing the opposite of well-researched best-practices, but whatever. I can firmly say that the lack
of constructive criticism has been interesting. I think people want it to fail, but it's so
"php-like" it might actually pass (insert scream emoji here).. I think constructive
criticism is the way to go, and I DO forget this from time to time, as does everyone.

> >>> 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!"
> >> 
> >> 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!"
> >> 
> >> Please read them in full before making such further equivalently dismissive claims.
> > 
> > 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. 
> 
> Thank you and I will try my best to avoid indentions in the future emails to this list.

:thumbs-up: Thank you. I didn't think it was on purpose, but to be honest, it took a while to
figure out what was even going on. :D

> 
> >>> 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.
> >> 
> >> Aside from your cringing, how does your pedanticism here move the discussion forward
> >> in a positive manner?
> > 
> > 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.
> > 
> 
> 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."

Ah, sorry, I didn't mean to intend that you (or anyone) were lying! My intention was to simply
add that as a possible state of the facts, not that anyone was doing it actively!

> 
> 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?"

Fair enough, but I didn't know if you would reuse that fact in a rebuttal. Ergo, it is better
to correct it immediately if we want to build on the original premise.

> 
> >> 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.
> > 
> > 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?" 
> 
> ChatGPT responded — in part — 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:
> 
> • There are clear, agreed-upon criteria for what makes X and Y alike.
> • 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."  
> 
> 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 don't remember what we were talking about, but it seems to me that this was an off-topic part
of the discussion. If I may throw this back: what does any of this email have to do with modules? :p

> > If you go create an RFC right now, you're faced with the following guideline in the
> > template, before you even write a word:
> > 
> >> Quoting [[http://news.php.net/php.internals/71525|Rasmus]]:
> >> 
> >> > 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."  

I don't think you're wrong and I'm sorry if I've made you feel that way. I am
merely asking you to explain why you think you're right and you might have to explain it
different ways, several times, to several people before "it clicks."

— Rob


Thread (128 messages)

« previous php.internals (#124078) next »