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