Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119887
MIME-Version: 1.0
References: <aa9f0f66-f772-3fc4-4f66-2245930ab089@helionweb.de>
 <CAEZPtU6qV1OEBt7kaVoaxog=Wd4AZWNyiJW=1NMkASW8AJkRTA@mail.gmail.com>
 <CADK1yXLie-hPJwKSUqpBgpOkWPBrBvcaXdFfLKxDMPbcT=1dYA@mail.gmail.com>
 <CAL0xaBGCw7szRaqJNdDHuZVoATms7dhCus4eXjUacAnLpBz+GA@mail.gmail.com>
 <CADK1yXKCKzq=965HT85nYoJcQqfp=X_L1b_O6zpAn0UoxS66+Q@mail.gmail.com> <CAL0xaBH2OtLg0wiTHPr8L9=uz+No6zxoUMYA6avORra5qEdAcg@mail.gmail.com>
In-Reply-To: <CAL0xaBH2OtLg0wiTHPr8L9=uz+No6zxoUMYA6avORra5qEdAcg@mail.gmail.com>
Date: Mon, 10 Apr 2023 19:07:48 -0300
Message-ID: <CADK1yXJP__a8ZzFpkXsUsh3DxJFDcB4gppOYV9AnwaAcBfKExg@mail.gmail.com>
To: Arvids Godjuks <arvids.godjuks@gmail.com>
Cc: Pierre Joye <pierre.php@gmail.com>, Stephan Soller <stephan.soller@helionweb.de>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000014771005f9029d1d"
Subject: Re: [PHP-DEV] Future stability of PHP?
From: deleugyn@gmail.com (Deleu)

--00000000000014771005f9029d1d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Apr 10, 2023 at 6:42=E2=80=AFPM Arvids Godjuks <arvids.godjuks@gmai=
l.com>
wrote:

>
>
> On Tue, 11 Apr 2023 at 00:03, Deleu <deleugyn@gmail.com> wrote:
>
>>
>>
>> On Mon, Apr 10, 2023, 4:01 PM Arvids Godjuks <arvids.godjuks@gmail.com>
>> wrote:
>>
>>>
>>>
>>>
>>>> *snip to keep the email short*
>>>>
>>>>
>>> Hello Deleu, I want to highlight your response specifically, because yo=
u
>>> blame the wrong people here.
>>> This is the failure of the business owner to plan accordingly and ignor=
e
>>> all the warnings for years and decades. That is if any developer raised=
 any
>>> concerns lately, which I also have seen quite a bit when "yes man" just
>>> shove code into the meatgrinder for a year or two and then just move to=
 the
>>> next job: "It's not my problem, the next guy will deal with this". And =
that
>>> feeds the vicious cycle, and the owner is either oblivious or does not
>>> understand the implications because "well, it works, it generates money=
" at
>>> the moment right until that plane hits the ground and things blow up.
>>> I've handled a big legacy project, did major updates to it, seen how an
>>> effort of 1 month of my time to drag it into the modern day paid off ov=
er
>>> the next 6 months by picking up development speed by 3x with the same t=
eam
>>> of 5 people + me. In 1 year we started to literally take away clients f=
rom
>>> our competitors who could not keep up with us and we had a literal line=
 of
>>> clients to onboard, we had to scale our sales team 3x and had a backlog=
 of
>>> 6 months still. All stemmed from a single decision "I will tackle this,=
 we
>>> need it to update to newer PHP". Business owners were really stoked tha=
t
>>> they actually listened to developers.
>>>
>>> You cannot expect to run code that was written 2 decades ago without
>>> major updates on modern language versions. It's not possible for almost=
 any
>>> language that is being actively developed. Think laterally - instead of
>>> hand-fixing every null check out there, introduce a library that can ha=
ndle
>>> data structures and handle the nulls for you en mass. Isolate the inter=
nals
>>> and just pass already sanitized values into it. Suddenly you cut off li=
ke
>>> 90% of the needed fixes that prevent you from running your code. It's s=
till
>>> needs fixing, but at least you give it good data to start with, so it d=
oes
>>> not error out.
>>> --
>>>
>>> Arv=C4=ABds Godjuks
>>> +371 26 851 664
>>> arvids.godjuks@gmail.com
>>> Telegram: @psihius https://t.me/psihius
>>>
>>
>> Thanks for your reply, I understand everything you mean here by improvin=
g
>> a development flow. I've been responsible to for doing that improvement =
for
>> the past 6 years and I'm pretty close to retiring 100% of the legacy cod=
e,
>> but I still need a couple of years to do it. I have long ago convinced t=
he
>> people in my business that we need to pay this technical debt.
>>
>> You mentioned that I'm blaming the wrong people, but I'm not blaming
>> anyone here. I have 4 teams working with me to replace our entire legacy=
,
>> one bite at a time, but I lead only 1 of those teams. The other 3 teams
>> have not only decided that the technical debt needs to be paid, but also
>> its not worth it to pay it with PHP and have move to Typescript.
>>
>> My points are:
>>
>> - development practices has changed and we know it, but it takes time to
>> shutdown legacy
>> - we are actively working towards paying that technical debt and PHP
>> improvements are great to help with it, but the deprecations aren't alwa=
ys.
>> - like it or not, there is a community unhappy with how hard it has
>> become to maintain a PHP codebase.
>>
>> I believe there's a lot more leeway in breaking BC and fast evolving the
>> language around projects that have started in 2018+ with automation test=
s
>> from day one. Introducing a BC break on PHP 8.3 about something that was
>> first released on PHP 7.4 is orders of magnitude easier to deal with tha=
n
>> BC breaks on things first Introduced on or before PHP 5.6. If we could j=
ust
>> have a way to opt-in to a faster-paced language for all new code while n=
ot
>> breaking PHP 5.6 features until the previous generation of software can =
be
>> retired, that would be awesome.
>>
>>>
> I do have to ask: How any of that is the concern of PHP the language, PHP
> the project? This is pure and simple is a company issue. Now they have to
> pay for their decision by probably buying some 3rd party extended support=
.
>

I think that's a very honest and on-point question. Which is somewhat
related to what I meant to mention here:
https://externals.io/message/119834#119846 but got called out as "spreading
BS" by Larry here: https://externals.io/message/119834#119868

I don't agree with Larry and I think you're dead right. PHP has a limited
resource and maybe it has decided that the "legacy community" is not a
priority and/or not worth the work. If that's the decision, I have nothing
else to argue and I can accept it.

--=20
Marco Deleu

--00000000000014771005f9029d1d--