Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124060
Precedence: bulk
MIME-Version: 1.0
References: <CAEUnE0fGZ3jFiBG=GyvnhBzH5a0iO4=n75PM=3+6zLAMrumEvA@mail.gmail.com>
 <CA+p1FaYYrQtV9vNmtNT+n6e_UospXH_czjN51UfAoQURwGoy7A@mail.gmail.com> <CAEUnE0ejmU7PuadTq5KMgW1fLz+EJNCVjhdKfXsc-sMzeiC+Nw@mail.gmail.com>
In-Reply-To: <CAEUnE0ejmU7PuadTq5KMgW1fLz+EJNCVjhdKfXsc-sMzeiC+Nw@mail.gmail.com>
Date: Sat, 29 Jun 2024 16:20:23 -0400
Message-ID: <CAEUnE0cRc0F-UBtui-W-ovyxvwZhhV8YXADe_bDEyHWCxuFi4Q@mail.gmail.com>
Subject: Re: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of
 ES6 from JavaScript
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000c9e585061c0d183c"
From: tendoaki@gmail.com (Michael Morris)

--000000000000c9e585061c0d183c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, Jun 29, 2024 at 2:20=E2=80=AFPM David Gebler <davidgebler@gmail.com=
> wrote:

> On Thu, Jun 27, 2024 at 4:33=E2=80=AFAM Michael Morris <tendoaki@gmail.co=
m> wrote:
>
>> Hello all. This is a ramble of an idea that's managed to run around my
>> head for a few days now. It isn't fully formed, but I've ran the thought
>> experiment as far as I can on my own and want to share it with all of yo=
u.
>>
>> If you got this far, thank you. This overall idea to take one of the
>> better things to happen to JavaScript in the last decade and incorporate=
 it
>> into PHP has been bothering me for awhile so I figured I'd share.  I don=
't
>> know how much merit there is to this though.
>>
>
> I don't think PHP needs to take many if any lessons from JS to be honest.
> JS evolved the way it did to solve its own set of problems, and likewise =
so
> has PHP. I'm not really clear from reading the whole thing what problems
> this loose bag of ideas is even intended to solve, really, but from what =
I
> have gathered it seems to me more like what you want is a transpiler a la
> Typescript and that this would achieve whatever you're trying to achieve.
> Personal take, but if there's one thing I don't want for PHP it's to beco=
me
> [any more] of a garbled mess of different styles and different ways of
> achieving the same fundamental abstractions and results. Composer and PSR=
-4
> have become de facto standards, they're very good standards, we've achiev=
ed
> remarkable near unity in their adoption and whatever few inconveniences
> remain through the application of those standards in certain cases are
> minor trade-offs (not having multiple interfaces in the same file, etc.)
>

Near universal unity??  You're forgetting Wordpress, which has massive PHP
market share (more than 50% of PHP backed websites - well more than
depending on which survey you cite) and DOES NOT USE COMPOSER. And it DOES
NOT USE PSR-4 either.

Composer is wonderful as a userland solution to a problem the Internals
team has failed to solve, but such a critical problem as package
management being mostly solved in userland using a configuration file
(composer.json) written in another programming language entirely is frankly
an embarrassment in my opinion.


> A JS-inspired subset of PHP within PHP, supported by invocation through
> new keywords and handed off to a separate parser seems like it's asking f=
or
> trouble at every level from implementation to maintenance to userland to
> dependency management...
>

What is asking for more trouble is to stagnate, sit-on-hands, and twenty
years from now PHP will be where COBOL is today - a niche programming
language that was once widely used, but reviled, hated, and the current
generation of programmers working feverishly to remove it entirely. Not to
mention the butt of an awful lot of jokes.

No one is going to post to this list with a perfect plan to solve package
management in CORE.   Not in userland - we've got that - in CORE.  That is
a feature PHP lacks that is present in Java, NodeJS (not clientside JS, a
distinction needs to be made), C#, Python and Go (likely others, but those
are the ones I've used and whose implementations I am familiar with on at
least a cursory level.)

And yes, JavaScript has a carnival of problems. Most of those problems do
not apply to PHP. But I'm starting from there because that's what I would
expect the majority of the PHP community to be familiar with - especially
when you include the large forgotten WordPress legion who don't have a clue
what your beloved composer is.

And I also don't appreciate the notion that any solution proposed here
should be 100% perfect and ready for implementation day one.  That's never
going to happen.  But I'm not willing to join several talented programmers
that have spent a month to a year getting a working implementation into
place before submitting an RFC only to have it shot down after work has
been done.  Cause frankly, I think some of y'all are only here to shoot
ideas down and never come up with new ones.

And while I'm no expert on the underlying engine there are problems with it
that have risen to the surface that may never be solvable except to move to
a subset language.  Like, why in Hell does PHP need THREE scope resolution
operators when every other damn programming language I've ever seen gets by
with ONE. And then there's having variables be required to have a $ prefix
and exist on their own symbol table unaffected by namespace. And I could go
on from there, but I don't want to belabor such points like the haters of
the language do because I am willing to live with them if they must be
there. I want to improve things if I can though.

Some of you just want to furiously defend the status quo with religious
zeal. And that is not helpful. That just drives people off.

--000000000000c9e585061c0d183c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote"><br><div dir=3D"ltr"><div dir=
=3D"ltr"></div><div dir=3D"ltr" class=3D"gmail_attr">On Sat, Jun 29, 2024 a=
t 2:20=E2=80=AFPM David Gebler &lt;<a href=3D"mailto:davidgebler@gmail.com"=
 target=3D"_blank">davidgebler@gmail.com</a>&gt; wrote:<br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s=
olid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr">O=
n Thu, Jun 27, 2024 at 4:33=E2=80=AFAM Michael Morris &lt;<a href=3D"mailto=
:tendoaki@gmail.com" target=3D"_blank">tendoaki@gmail.com</a>&gt; wrote:<br=
></div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex"><div dir=3D"ltr">Hello all. This is a ramble of an idea that&#39=
;s managed to run around my head for a few days now. It isn&#39;t fully for=
med, but I&#39;ve ran the thought experiment as far as I can on my own and =
want to share it with all of you.<div><br></div><div>If you got this far, t=
hank you. This overall idea to take one of the better things to happen to J=
avaScript in the last decade and incorporate it into PHP has been bothering=
 me for awhile so I figured I&#39;d share.=C2=A0 I don&#39;t know how much =
merit there is to this though.</div></div></blockquote><div><br></div><div>=
I don&#39;t think PHP needs to take many if any lessons from JS to be hones=
t. JS evolved the way it did to solve its own set of problems, and likewise=
 so has PHP. I&#39;m not really clear from reading the whole thing what pro=
blems this loose bag of ideas is even intended to solve, really, but from w=
hat I have gathered it seems to me more like what you want is a transpiler =
a la Typescript and that this would achieve whatever you&#39;re trying to a=
chieve. Personal take, but if there&#39;s one thing I don&#39;t want for PH=
P it&#39;s to become [any more] of a garbled mess of different styles and d=
ifferent ways of achieving the same fundamental abstractions and results. C=
omposer and PSR-4 have become de facto standards, they&#39;re very good sta=
ndards, we&#39;ve achieved remarkable near unity in their adoption and what=
ever few inconveniences remain through the application of those standards i=
n certain cases are minor trade-offs (not having multiple interfaces in the=
 same file, etc.)</div></div></div></blockquote><div><br></div><div>Near un=
iversal unity??=C2=A0 You&#39;re forgetting Wordpress, which has massive PH=
P market share (more than 50% of PHP backed websites - well more than depen=
ding on which survey you cite) and DOES NOT USE COMPOSER. And it DOES NOT U=
SE PSR-4 either.</div><div><br></div><div>Composer is wonderful as a userla=
nd solution to a problem the Internals team has failed to solve, but such a=
 critical problem as package management=C2=A0being mostly solved in userlan=
d using a configuration file (composer.json) written in another programming=
 language entirely is frankly an embarrassment in my=C2=A0opinion.</div><di=
v><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"l=
tr"><div class=3D"gmail_quote"><div><br></div><div>A JS-inspired subset of =
PHP within PHP, supported by invocation through new keywords and handed off=
 to a separate parser seems like it&#39;s asking for trouble at every level=
 from implementation to maintenance to userland to dependency management...=
</div></div></div></blockquote><div><br></div><div>What is asking for more =
trouble is to stagnate, sit-on-hands, and twenty years from now PHP will be=
 where COBOL is today - a niche programming language that was once widely u=
sed, but reviled, hated, and the current generation of programmers working =
feverishly to remove it entirely. Not to mention the butt of an awful lot o=
f jokes.</div><div><br></div><div>No one is going to post to this list with=
 a perfect plan to solve package management in=C2=A0CORE.=C2=A0 =C2=A0Not i=
n userland - we&#39;ve got that - in CORE.=C2=A0 That is a feature PHP lack=
s that is present in Java, NodeJS (not clientside=C2=A0JS, a distinction ne=
eds to be made), C#, Python and Go (likely others, but those are the ones I=
&#39;ve used and whose implementations=C2=A0I am familiar with on at least =
a cursory level.)</div><div><br></div><div>And yes, JavaScript has a carniv=
al of problems. Most of those problems do not apply to PHP. But I&#39;m sta=
rting from there because that&#39;s what I would expect the majority of the=
 PHP community to be familiar with - especially when you include the large =
forgotten WordPress legion who don&#39;t have a clue what your beloved comp=
oser is.</div><div><br></div><div>And I also don&#39;t appreciate the notio=
n that any solution proposed here should be 100% perfect and ready for impl=
ementation day one.=C2=A0 That&#39;s never going to happen.=C2=A0 But I&#39=
;m not willing to join several talented programmers that have spent a month=
 to a year getting a working implementation into place before submitting an=
 RFC only to have it shot down after work has been done.=C2=A0 Cause frankl=
y, I think some of y&#39;all are only here to shoot ideas down and never co=
me up with new ones.</div><div><br></div><div>And while I&#39;m no expert o=
n the underlying engine there are problems with it that have risen to the s=
urface that may never be solvable except to move to a subset language.=C2=
=A0 Like, why in Hell does PHP need THREE scope resolution operators when e=
very other damn programming language I&#39;ve ever seen gets by with ONE. A=
nd then there&#39;s having variables be required to have a $ prefix and exi=
st on their own symbol table unaffected by namespace. And I could go on fro=
m there, but I don&#39;t want to belabor such points like the haters of the=
 language do because I am willing to live with them if they must be there. =
I want to improve things if I can though.</div><div><br></div><div>Some of =
you just want to furiously defend the status quo with religious zeal. And t=
hat is not helpful. That just drives people off.</div><div><br></div><div><=
br></div><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr"><=
br></div></div></div>
</div></div>

--000000000000c9e585061c0d183c--