On Mon, 10 Apr 2023 at 23:43, Mark Baker <m...@demon-angel.eu> wrote:
> On 10/04/2023 19:04, Arvids Godjuks wrote: > > I also want to add that PHP is purely developed by open-source > contributor > > efforts who are limited in their numbers and not a lot of them are > getting > > compensated for it (exceptions being specific people working for > companies > > who have a vested interest in PHP development like JetBrains, hosting > > giants and some others. And now PHP Foundation is there to help people > get > > paid for their crucial roles in PHP project and their dedicated time). > > Yes we know, and we're very grateful; but that doesn't mean we should be > unquestioningly grateful! > > And some of us are also open-source contributors, not getting > compensated for it. We understand; and just as I try to take a > professional approach to my OS contributions, and assess the impact of > any change that may affect bc, I hope that PHP Internals does the same, > but I don't often see that. So am I expected to stay silent when I see > potential problems with bc breaks because I should just be grateful? > Almost all other languages have deep pockets behind them one way or the other. Frankly, they can afford it. PHP has no such option. So, in some way, yes, sometimes you just have to take the loss and move on. PHP has to prioritize the resources and relies on what people are interested in doing for the project. Historically PHP just can't maintain lots of legacy stuff, nor have long LTS releases - that's why there are only 3 versions of the engine ever supported at the same time. > > > > You also have a world on your hands that is changing - everywhere you > look > > things are going for a more typed approach. That's what developers of > today > > expect. That's the reality of how modern libraries are developed and old > > libraries have been actively migrating to strict type code bases. This > code > > quality improvement absolutely takes a huge load off those developers' > > shoulders. I'm seeing libraries out there now that basically require PHP > > 8.1 as a minimum because Enums are all the rage and almost half the > > libraries I use have introduced them in their code in the latest versions > > and authors just flat-out tell you "use the older version of the lib or > > update your project" (and I have at least 7 of them in my code already > and > > that project will never run on anything lower than 8.2). Some of the > > biggest libraries out there have fully adopted SemVer and will bump the > > minimal PHP version quite aggressively. And will tell you to pay for > > commercial support or deal with it on your own. And now the Union types > are > > coming and I expect that to get adopted at a rapid pace by everyone and > > their dog. > > Yes it is changing, but at different speeds in different companies. > Changes aren't being adopted at that rapid pace by everyone and their > dog, that's the reality. > This is business. Adapt or be swallowed by competitors. This really has nothing to do with language development. 2 decades is enough for a commercial entity to realise something needs to be done about the code base. Speaking of competition - PHP needs to move forward at a pace where it stays competitive with other languages too. The project has already stumbled once, that's why the RFC process and yearly release cycle was born. Because that thread was identified and people decided to do something about it. > > > > Just as owning your own house means you need to do the upkeep on a yearly > > basis or it will become a mess, the same is with code and not maintaining > > it - eventually, the roof will cave in and the costs of fixing it all > will > > skyrocket. And, frankly, this is the feeling I get from a lot of this > > thread - the roof has collapsed and people are put into impossible > > positions of "no, you can't have the time or resources to update the > > project to the new PHP version, here are 20 KPI's for the next 3 months > you > > need to hit". The codebase was run on a credit of "this will be fixed > down > > the line". Well, the debt collectors now what their debt, their late fees > > and lawyers want their slice of the pie. > > Do you think we're unaware of that! But you're suggesting that anybody > that isn't using the latest shiny release should be treated as though > they don't exist. They're not your problem, so forget about them. Many > of those developers would love to upgrade to the latest shiny release, > but that isn't always an option every November; that run-up to Christmas > can often be the busiest time of year for those developers, the time > when they are least in a position to go through an upgrade. > PHP 8 was released 2.5 years ago. To be frank, I have a feeling that the code base in question is never going to keep up with PHP even if it does 1 release every 2 years. The result will be the same. In my case, on multiple occasions, the management just decided to sunset the old systems and just build new once on modern code bases with modern frameworks, libraries and using all those bells and whistles like Psalm, phpstan, cs-fixer, run modern development practices. Some people left, new people got hired. Business moved on to have far more sustainable software on their hands that underpins it's whole existence. Most clients I worked for who clung to their old systems at this point are all defunct. Because competitors just ate them up eventually. > Telling them that the debt collectors and lawyers are here isn't going > to help them when the people that pay them so they can eat and have a > roof over their heads and care for their families is a slap in the face > to them when they are torn between business demands and wanting to do > technical upgrades. > The point I was making is that at that moment it's too late to do anything. That's when you close the business and hope you are not in the red. > > > And the attitude of some here on PHP Internals that we should just > ignore those who can't develop in greenfield environments using the > latest shiny, or that it should just be a simple upgrade step from last > version to current release... that's the equivalent of having unit tests > that only test the happy path. > In my opinion, it's not the job of the internals developers to solve legacy system issues. They are developing a language, they are making sure deprecations are issued well in advance, sometimes through multiple versions and only then the feature is completely removed or made a full-on error. Why a PHP language developer should care about a commercial company having a 20-year-old legacy system that has no resources to upkeep it's systems? I mean even Microsoft does not care enough and are sunsetting their Windows support even for customers who pay them literal bags of money and beg them to continue. But they still cut their losses because at some point it makes no damn sense for any amount of money. > > > -- > Mark Baker > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > > -- Arvīds Godjuks +371 26 851 664 arvids.godj...@gmail.com Telegram: @psihius https://t.me/psihius
