Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:124033 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by qa.php.net (Postfix) with ESMTPS id 9F6E21A009C for ; Sat, 29 Jun 2024 13:15:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1719667028; bh=cVN3SOqsCU3hFEZiZHRmW2kbLXCVtLyX6AJb5H6CeDU=; h=In-Reply-To:References:Date:From:To:Cc:Subject:From; b=EtKMFBqHMuaE25vsgZ6F91mMQWqr0lD4iNVi/7asIvvdQgFZbMh3eg9m24164LO71 Y+AzyB6WgOd6Jjv8l9HyoXiXwWsfSJoW97SAu7I2oNYLBQWpa5uWSFV1BGVoPF5CgS rHYPoF9ZDWtbf2HIajXPvR500Nx20qaBffFKiI01wM3Z1lKiVdWQtppavDNh75KXPH wzGmxrUvnfVUo4dQIcF3mZyBYE0ECaxhHM35v7a05SnRZIefUVzhIiQetSe1Pi4ghI Nj4XT/EmkHnWCFRMuu+vmCTK/a28epNXZQ/4TgWH5JR/4oJ+jpZZIM/XExfHtrtC/n QVt5HVJu+69bQ== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 8AEFA18004A for ; Sat, 29 Jun 2024 13:17:07 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-0.1 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_MISSING,HTML_MESSAGE, RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: Error (Cannot connect to unix socket '/var/run/clamav/clamd.ctl': connect: Connection refused) X-Envelope-From: Received: from fhigh1-smtp.messagingengine.com (fhigh1-smtp.messagingengine.com [103.168.172.152]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Sat, 29 Jun 2024 13:17:06 +0000 (UTC) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailfhigh.nyi.internal (Postfix) with ESMTP id 4D4DC11401D7; Sat, 29 Jun 2024 09:15:47 -0400 (EDT) Received: from imap49 ([10.202.2.99]) by compute1.internal (MEProxy); Sat, 29 Jun 2024 09:15:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bottled.codes; h=cc:cc:content-type:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to; s=fm3; t=1719666947; x= 1719753347; bh=S1HAoXx7ClPFtzbTbWg4F4JjsMRCrvrBLPicBxO2vI0=; b=L BbK8BPRtrebw6kBF3yTgHSi+/dW8uNIaXMJnAG8FiJRDVNsyv184P7qIfV+Wl9DE 8cJ+NL9OAnvmQWiO4HvPGgIhAzrLj7VlHRx1EABJ2dXF5RHnya5LlKkM9SyHSUFV nHa9LhQUpwF4WfXwZKXDbRGlGvKVKzp8zXhlTlcOjdXsINoXCeo14nQYimhmzEKA XaT6caKdBo27vrz39mkgeC8vvog38aUBEF29mVcK2daurUUungyeFrd69Gc/iMOA hEVK/ke6bhMiAxBuPQx+uHMP4Es5Hr43NtBSHyNmbrgWu1pfqGbzMZT0knpQk1TN 3xKyEWyAutX4+ymLkKETg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1719666947; x=1719753347; bh=S1HAoXx7ClPFtzbTbWg4F4JjsMRC rvrBLPicBxO2vI0=; b=jYOz9Qazs2WdXXV8kJFKgRJKnhjMtpemkkqc4SGrme2J ofvV2sez9tDxVb06SdgDVnoqbR57iEH/FvcrKomqF8wD7RdZXima43oxBDJR3yfR CBC4Mpc6OSCv3Kh8rINi9/26CTc7i0FRtvXdBdKiKCqpicT6PNcOzVFXtN2Nm+r9 HLnvfTUcwOMMTbapSgl4M6rJzKuaqEs5da0wzyWqRVZv0ztne2Cgfj3Nm/79YnL+ LMzcb0+8/Noq2VqlX4Ma/AQh2l9u8yiwP6RuqTxRtFiHek0l18uyD/Fww92SSqGs nLviXc+ZBEkX0DC8TF/fFQv+dWXmzP1ApC/G651eLg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrtdelgdeifecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvvefutgesrgdtreerreerjeenucfhrhhomhepfdftohgs ucfnrghnuggvrhhsfdcuoehrohgssegsohhtthhlvggurdgtohguvghsqeenucggtffrrg htthgvrhhnpefgvdefjeefvddvteeigeekhfevjeeiffeuudettdethfdtieefgeethfdv veevgfenucffohhmrghinhepphhhphdrnhgvthenucevlhhushhtvghrufhiiigvpedtne curfgrrhgrmhepmhgrihhlfhhrohhmpehrohgssegsohhtthhlvggurdgtohguvghs X-ME-Proxy: Feedback-ID: ifab94697:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id BA07A15A0093; Sat, 29 Jun 2024 09:15:46 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.11.0-alpha0-538-g1508afaa2-fm-20240616.001-g1508afaa Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net MIME-Version: 1.0 Message-ID: In-Reply-To: <5B0CE06B-DB82-442E-A4A0-BF1B49F42246@newclarity.net> References: <0acedb8e-34be-4348-907b-4075cf7641fd@app.fastmail.com> <9c20b078-f82a-47fe-af23-2f3cdd233079@app.fastmail.com> <50529C6A-42BB-4D49-B720-FE1847577484@rwec.co.uk> <97EA49E2-43A9-42D2-B493-A6B66CC54914@edison.tech> <5B0CE06B-DB82-442E-A4A0-BF1B49F42246@newclarity.net> Date: Sat, 29 Jun 2024 15:15:06 +0200 To: "Mike Schinkel" Cc: internals@lists.php.net Subject: Re: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript Content-Type: multipart/alternative; boundary=b62887e293084cdb9e223cbb9d7f52db From: rob@bottled.codes ("Rob Landers") --b62887e293084cdb9e223cbb9d7f52db Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Sat, Jun 29, 2024, at 13:43, Mike Schinkel wrote: >> On Jun 29, 2024, at 7:14 AM, Rob Landers wrote: >>> You say it is impractical, you claim millions of users, but you don'= t address why the specific features are impractical. >>>=20 >>> They are no more impractical than any other new language features PH= P has added in recent years (and I am not being critical of what has bee= n added, to be clear.) >>=20 >> 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 peo= ple would use it, why people would rewrite their entire application to u= se it (if the RFC calls for it), and so far, nobody has shown that other= than "there are packages!" >=20 >> The problem with your assertion is that "impractical" is not a critic= ism 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. >>=20 >> 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 on= ly be solved by swaying people's opinions which sometimes involves techn= icalities. People have and will decline RFCs simply because they don't l= ike it. It's that simple. >> You need to show why people would use it, why people would rewrite th= eir entire application to use it (if the RFC calls for it), and so far, = nobody has shown that other than "there are packages!" >=20 >> It seems you have not read any of the several other emails I have wri= tten to this list in the past several days that do far more than say "th= ere are packages!" >>=20 >> Please read them in full before making such further equivalently dism= issive 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. >=20 >> 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'r= e descendants of B which borrowed syntax from BCPL which borrowed syntax= from CPL which borrowed it's syntax from ALGOL... eh, no, these languag= es are not related to each other. Inspired, maybe. >=20 >> Aside from your cringing, how does your pedanticism here move the dis= cussion 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 pe= r-se), to the point where some of it can't be taken seriously, like comp= oser 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 c= hecked by simply doing a quick search before sending the email, but argu= ments 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 va= lid argument. >=20 >>=20 >> 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 othe= r way around. If anything, JavaScript is more like PHP than PHP is more = like JavaScript. >=20 >> Again, you are making a statement that cannot be objectively proven t= rue or false, and frankly I cannot see any way in which your argument he= re 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. >>=20 >> I don't see any gate-keeping here, >=20 >> Those who are inside the gates never do. >>=20 >> 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 p= eople 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 involve= d. In fact, some of my ideas are "against the grain" of the current vote= rs as well; this is fine. Success isn't the only way to make progress. >>=20 >> just people challenging assumptions and pushing for the feature to be= better than it is currently being proposed. >=20 >> Yet the challenges are premised on opinions and fallacies instead of = objectively challenging the proposed features. =20 >>=20 >> I am happy to defend against proposal against arguments that can be o= bjectively evaluated, but having my arguments challenged *"because they = come from a language I don't know" *means that my assumptions are not ac= tually being challenged and the criticisms made are based on the challen= ger's pre-existing lack of comfort with the assumptions while making it = appear readers the criticism is objective. >>=20 >> And that IMO is no way to improve a language. >>=20 There is nothing objective about the RFC process... If you go create an RFC right now, you're faced with the following guide= line in the template, before you even write a word: > Quoting [[http://news.php.net/php.internals/71525|Rasmus]]: >=20 > > 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 wi= de range of users >=20 > Your RFC should move PHP forward following his vision. As [[http://new= s.php.net/php.internals/66065|said by Zeev Suraski]] "Consider only feat= ures 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 f= ull context, the huge audience out there, the consequences of making th= e learning curve steeper with > every new feature, and the scope of the goodness that those new featur= es bring." The reason people are challenging this so hard is that last sentence: "M= ake sure you think about the full context, the huge audience out there, = the consequences of making the learning curve steeper with every new fe= ature[...]". 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 askin= g 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 wor= k within the current syntax. =E2=80=94 Rob --b62887e293084cdb9e223cbb9d7f52db Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable

=
On Sat, Jun 29, 2024, at 13:43, Mike Schinkel wrote:
<= /div>
On = Jun 29, 2024, at 7:14 AM, Rob Landers <rob@bottled.codes> wrote:
You say it is impractical, you claim million= s of users, but you don't address why the specific features are impracti= cal.

They are n= o 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, y= ou 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, nob= ody has shown that other than "there are packages!"

<= div>
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 prop= osers to show people why to use it, but it is unfair to proposers to giv= e criticism that can only be classified as opinion.

The RFC process is people probl= ems, 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 wou= ld 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!"
<= /div>

It seems you have not read any of the several o= ther emails I have written to this list in the past several days that do= far more than say "there are packages!"

Pl= ease read them in full before making such further equivalently dismissiv= e claims.

M= y 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 q= uoted text that I have to expand in my email reader. It may be that my e= mail reader has hidden entire replies from you and I wouldn't even know = it.


I cringed at t= his. There is no direct lineage though they borrow come syntax from C, a= nd 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 b= orrowed it's syntax from ALGOL... eh, no, these languages are not relate= d to each other. Inspired, maybe.

<= /div>
Aside fro= m your cringing, how does your pedanticism here move the discussion forw= ard in a positive manner?
=
This isn't pedanticism, it's just plainly incorrect. Ther= e's been a lot of that in this thread (I haven't been keeping track of w= ho said what per-se), to the point where some of it can't be taken serio= usly, 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 asse= rtions can be checked by simply doing a quick search before sending the = email, but arguments based on lies/incorrect facts are not valid argumen= ts. 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 e= ach other. With a bit of finangling, you can actually port JavaScript li= ne-for-line to PHP, but not the other way around. If anything, JavaScrip= t is more like PHP than PHP is more like JavaScript.

=
Again, you are making a statement that cannot be objectively p= roven true or false, and frankly I cannot see any way in which your argu= ment here matters to discussion of modules.
=

As someone who used to make a living po= rting things from one language to another, I can say, quite frankly, tha= t 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 genet= ic fallacy[1] for dismissing the proposed ideas rather than using object= ive 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 he= lping out other people with RFCs. I'm not paid to be here, I'm here beca= use I want to be. I have very limited time to spend here, so I'm not con= sistently 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 currentl= y being proposed.

Yet the challenges are premise= d on opinions and fallacies instead of objectively challenging the propo= sed features.  

I am happy to defend a= gainst 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 act= ually being challenged and the criticisms made are based on the challeng= er's pre-existing lack of comfort with the assumptions while making it a= ppear readers the criticism is objective.

A= nd that IMO is no way to improve a language.


There is nothing objective ab= out 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 typ= ed language
> 3) a language which caters to the skill-l= evels and platforms of a wide range of users

Your RFC should move PHP forward following his vision. As [[http://news.php.net/php.i= nternals/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 lear= ning curve steeper with
every new feature, and the scope o= f 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 aud= ience out there, the consequences of  making the learning curve ste= eper with every new feature[...]". This objectively WILL make the learni= ng curve steeper with two different execution modes. People are asking y= ou if it is "worth it" to learn two different modes, so prove it is wort= h it. People are asking you if it is "worth it" to rewrite billions of l= ines of code, so prove it. Or ... pivot and think about how you can chan= ge your feature to work within the current syntax.

=E2=80=94 Rob
--b62887e293084cdb9e223cbb9d7f52db--