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