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.
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.
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.
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.
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.
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!
--
Mark Baker
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
