> 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.
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!"
>>
>> 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.
>>> 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."
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.
>
> 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'm very much not "inside the gate."
Again, you debate irrelevant characterizations.
> 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:
>
>> 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."
Such is life I guess. 🤦♂️
> 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?
Or do we need to continue to debate characterizations that are irrelevant and orthogonal to any
potential proposal?
-Mike