@Crell if you were a new engineer today, would you hand on heart, pick up PHP?
What incentive to their project is there to use abd take on maintenance burden of adding PHP, or any other language / dep-management framework they do not support?
@Crell It's made by Google. They've only ever paid php lip service, and only if there was some monetary value to them. Things like GData and AppEngine only had good PHP support by them in the early web 2.0 days, when PHP was a more popular/visible choice in the larger web dev ecosystem.
So I'm bummed, but not surprised.
(Also: Not mentioning Packagist on PHP.net doesn't help. All the options listed are endorsed by their languages. I hate that PHP doesn't.)
@mwop My strongest argument about PHP being a good language is how popular and successful it is, despite the long, detailed list of organizational own-goals that PHP manages to pull off. Internals mainly, but user space a bit as well.
@Crell I do market research yearly, and there's this really weird dichotomy of "PHP is everywhere, powers the vast majority of the web, and has a disproportionate number of developers worldwide" and "PHP is an antiquated language that nobody uses for new projects, nobody teaches, and there aren't enough developers". The truth is likely somewhere in the middle, but it's hugely flabbergasting.
@mwop@Crell Also, the pace of change in the language and short security window is often cited as a reason to stay off it... And yet I'll often then hear folks say they're migrating to node in the same breath.
Essentially, folks say they value stability and security, but then go and choose technologies that offer even less of each.
@mwop@Crell I feel we as developers get sucked into a permanent hype cycle where something else, something new, is always better. And it's always to our detriment, and costs our companies and businesses endless amounts of money and effort when we could be focusing on solving real problems.
But instead we belittle the languages others choose, strap our flag to the shiny new, and churn, churn, churn.
@hunter@derickr@mwop Realistically no. It would require a 2/3 vote of the people who would be disempowered by it. That's not a thing that happens.
The other option is a coup, but I don't even know how that would work and the fallout of someone just locking server and repo access or whatever would likely be project killing. I'm not a fan.
@simonrjones@mwop Internals has been firmly, almost pathological, opposed to doing anything g that might seem to "endorse" any particular user space project. To the point that you're not even allows to use Composer packages for PHP.net tooling.
Except Docuwiki, which somehow gets a pass for no logical reason.
@Crell Not surprised, the industry seems to want to push PHP out of it. Relatedly the number of times I've been told I shouldn't waste time helping php-src maintenance is uncountable, which shows the view on it.
@nielsdos Yeah, especially as the high end. It's hard to impossible to get staff+ level PHP jobs.
Though in fairness, if you were to design a governence process for a language to make it as painful and self-defeating as possible, you would still not do as good a job as PHP Internals at those goals.
@nielsdos I don't know about the former. For the latter, for as long as I've been on the list (circa 2007). I just feel it more since I started working on rfcs (~2020).
@Crell@nielsdos I might be wrong, but PHP is lacking corporate backing (which is important for C-level in order to seen continuity) and the ways we as a community make decissions is for those same C-levels completely unpredictable.
Who in their right state of mind would start the next project with a language whose path is unpredictable and that might just vanish and where they don't have a corporation to sue.
Also no one is paid to go out telling everyone how awesome PHP is.
@Crell@nielsdos And I know how stupid that is. But it is never about being awesome but about sales. Which is something we are .... I can't even say "not good at" as that would mean we'd actually be doing sales...
The web has changed, the world we operate in has changed, PHP as a language has chamged. Perhaps we need to change the ways we work in as well.
@heiglandreas@nielsdos Amen and pass the sweet potatoes. But Internals can't even wrap it's little head around having elected people to break ties on implementation details, because that was a "power grab."
Seriously, the organizational incompetence of Internals has made me question continuing in PHP more than the job market has.
@Crell internals never was intended to have organizational competence.? That was what Zend did in the background. And what is now missing. And could be taken up by the PHPFoundation.
Make longer standing plans and support them by financing people to execute them.
And yes: Perhaps we need to rethink the RFC system if that should bring stability to PHP.
@heiglandreas@nielsdos Agreed! The issue with RFCs isn't the RFC itself per se. It's that it's all spec work, and there is no way to know what will or won't pass at all until the vote happens. And it could, and does, vary by who happens to have read misinformation on Reddit that week. There's no vetting of concepts in a binding way before all the work is done.
And that in turn makes any kind of planning or design basically impossible.
@heiglandreas@nielsdos An elected set of rfc reviewers/approvers that have clearly and explicitly stated design goals. Who we know up front are the people to convince (or understand that we won't convince and so should stop trying.)
But if Internals wouldn't even accept elected leaders on implementation details, I haze zero expectation that the anarchists will let elected RFC approvers through.
@Crell@heiglandreas Related to this aspect: I noticed with my ext-dom (and in general XML extension) involvement, that I find it hard to reach the right people via the RFC process. I have a few people that I contact off-list, that don't participate in internals, to discuss API design aspects on my RFCs (which is great of course!). But inside internals there's few people that actively do.
And when it comes to discuss the implementation aspects, really only Gina can double check my work atm.
Add comment