On Tue, 11 Apr 2023 at 01:12, Mark Baker <m...@demon-angel.eu> wrote:
> On 10/04/2023 23:33, Arvids Godjuks wrote: > > > >> 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. > > That does not mean that I should stay silent when I see problems; nor do > I intend to. > Sure, but I would suggest picking the battles carefully. Resources are one of the major problems here and getting new core devs on board is tough as it is. As cliche as it sounds, we all should choose our words carefully. God knows this list has a poor track record over the decades with making newcomers feel comfortable :D But that's offtopic. > 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. > > I've not mentioned 20 years; but business application should have a > lifespan longer than a mayfly. Even 3 years feels too short for > companies that have a lot of apps that need to be maintained alongside > new development work. Not every company has enough developers for > dedicated teams to handle upgrade work full time. > Well, we were given an example for discussion a real-life application that's 20 years old. So I have been referring to that case. As someone who dabbles in business, I see this a lot of the time when company owners just decide to get a new 100k car instead of investing in their business a bit, so it can survive the next 5 years. Personally, I don' think a company that can't even upkeep it's own systems should be a company that survives. It's better to have a new better company to take it's place. > > > > 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. > > Rewriting any system from scratch can be a major undertaking (I do know, > I've done this myself, and it took a team of 6 people over 8 month in > the most recent case). It isn't the type of undertaking that can be > taken without considerable investment. Yes, the new system was written > with all the bells and whistles; but upgrades still take time and > investment, and there's still the demand for new features. No companies > but the very biggest can indulge in that on a regular basis: developers > are there to add value with new features, not just staving off technical > debt. > Yes, yes it is. But it also can usually be done in chunks - most systems only seem like monoliths, but they aren't really. I've literally headed a re-write project with a team of 4 at a company that was barely 20 people total. So I will never take the argument "only big companies can do that" as a valid one. If anything, bigger companies have a far more higher failure rate because of bureaucracy, internal politics and your typical corporate backstabbing. > > > >> 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 that's tough on the developers that have been struggling with those > legacy debt issues alongside trying to keep a system running and making > money for their employer. When the business closes, it's the developers > that suffer, not the business. > That's the job. And developers really need to learn how to say "no" to stakeholders instead of patching the Frankenstein for the 100's time making things 1000 times worse. And then get eventually fired because you can't keep up with the workload due to how bad the code is, so everything you touch - breaks. > Again, I'll re-iterate. Not all developers are working on shiny > greenfield projects, and they do have to balance upgrades with the new > work that the business is demanding. And not all developers are > freelance who can just walk away from companies that run legacy code, > and walk into new jobs with the latest shiny, latest tooling, and latest > processes. > It's not about being new and shiny, it's about having reasonable processes in the company and understanding that apps need upkeep. Worked plenty of jobs that were 3-4 versions behind on their PHP, but there were always efforts to update in the background as a matter of your daily job. Sure, I learned just not to take the jobs that were stuck in legacy without any prospects of improvement. I just know better (and they never pay even decently) :) > > > > 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? > > > Again with the 20 years. And when did I suggest that should be the role > of internals? BUT, the affect of internals changes on legacy code > shouldn't simply be ignored; where appropriate, upgrade > paths/recommendations should be provided, and the edge cases of those > changes should be considered. A small change to core code might have > minimal benefit; but could still create hours of extra upgrade work for > millions of developers around the world. > > > "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" > > I do wish that this was always the case! > Has been since the RFC process got introduced. Maybe one or two missteps along the line that everybody learned from, but it really hasn't been an issue for a long time now. Every RFC that needs it ends up considering and implementing a depreciation period. > > > -- > 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
