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.
>> 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.
>
>> 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.
>
>>
>> No, PHP and Go are nothing like each other. With a bit of finangling, you can actually port
>> JavaScript line-for-line to PHP, but not the other way around. If anything, JavaScript is more like
>> PHP than PHP is more like JavaScript.
>
>> 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.
>>
>> I don't see any gate-keeping here,
>
>> Those who are inside the gates never do.
>>
>> I called out gatekeeping because he argued the genetic fallacy[1] for dismissing the
>> proposed ideas rather than using objective criticism of the features proposed.
I'm very much not "inside the gate." 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.
>>
>> just people challenging assumptions and pushing for the feature to be better than it is
>> currently being proposed.
>
>> Yet the challenges are premised on opinions and fallacies instead of objectively
>> challenging the proposed features.
>>
>> I am happy to defend against proposal against arguments that can be objectively evaluated,
>> but having my arguments challenged *"because they come from a language I don't know"
>> *means that my assumptions are not actually being challenged and the criticisms made are based on
>> the challenger's pre-existing lack of comfort with the assumptions while making it appear
>> readers the criticism is objective.
>>
>> And that IMO is no way to improve a language.
>>
There is nothing objective about the RFC process...
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."
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.
— Rob