On Sat, Jun 29, 2024 at 2:20 PM David Gebler <davidgeb...@gmail.com> wrote:
> On Thu, Jun 27, 2024 at 4:33 AM Michael Morris <tendo...@gmail.com> 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 you. >> >> 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 become > [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 achieved > 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 for > 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.
