Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119891
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> <CADK1yXJP__a8ZzFpkXsUsh3DxJFDcB4gppOYV9AnwaAcBfKExg@mail.gmail.com>
In-Reply-To: <CADK1yXJP__a8ZzFpkXsUsh3DxJFDcB4gppOYV9AnwaAcBfKExg@mail.gmail.com>
Date: Tue, 11 Apr 2023 01:52:55 +0300
Message-ID: <CAL0xaBGfoc5UF=U82o8PXrObcikozswkX2LFHN9BJg7PwX0ZJA@mail.gmail.com>
To: Deleu <deleugyn@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="000000000000dacc6105f9033db6"
Subject: Re: [PHP-DEV] Future stability of PHP?
From: arvids.godjuks@gmail.com (Arvids Godjuks)

--000000000000dacc6105f9033db6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 11 Apr 2023 at 01:08, Deleu <deleugyn@gmail.com> wrote:

>
>
> On Mon, Apr 10, 2023 at 6:42=E2=80=AFPM Arvids Godjuks <arvids.godjuks@gm=
ail.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
>>>> you blame the wrong people here.
>>>> This is the failure of the business owner to plan accordingly and
>>>> ignore all the warnings for years and decades. That is if any develope=
r
>>>> raised any concerns lately, which I also have seen quite a bit when "y=
es
>>>> man" just shove code into the meatgrinder for a year or two and then j=
ust
>>>> move to the next job: "It's not my problem, the next guy will deal wit=
h
>>>> this". And that feeds the vicious cycle, and the owner is either obliv=
ious
>>>> 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 a=
n
>>>> effort of 1 month of my time to drag it into the modern day paid off o=
ver
>>>> the next 6 months by picking up development speed by 3x with the same =
team
>>>> of 5 people + me. In 1 year we started to literally take away clients =
from
>>>> our competitors who could not keep up with us and we had a literal lin=
e of
>>>> clients to onboard, we had to scale our sales team 3x and had a backlo=
g 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 th=
at
>>>> 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 almos=
t any
>>>> language that is being actively developed. Think laterally - instead o=
f
>>>> hand-fixing every null check out there, introduce a library that can h=
andle
>>>> data structures and handle the nulls for you en mass. Isolate the inte=
rnals
>>>> and just pass already sanitized values into it. Suddenly you cut off l=
ike
>>>> 90% of the needed fixes that prevent you from running your code. It's =
still
>>>> needs fixing, but at least you give it good data to start with, so it =
does
>>>> 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
>>> improving 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 code, but I still need a couple of years to do it. I have lo=
ng
>>> ago convinced the people in my business that we need to pay this techni=
cal
>>> 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 legac=
y,
>>> 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 als=
o
>>> 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 t=
o
>>> 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 alw=
ays.
>>> - 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 th=
e
>>> language around projects that have started in 2018+ with automation tes=
ts
>>> from day one. Introducing a BC break on PHP 8.3 about something that wa=
s
>>> first released on PHP 7.4 is orders of magnitude easier to deal with th=
an
>>> BC breaks on things first Introduced on or before PHP 5.6. If we could =
just
>>> have a way to opt-in to a faster-paced language for all new code while =
not
>>> 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, PH=
P
>> the project? This is pure and simple is a company issue. Now they have t=
o
>> pay for their decision by probably buying some 3rd party extended suppor=
t.
>>
>
> 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 nothin=
g
> else to argue and I can accept it.
>
> --
> Marco Deleu
>

The reality is, the bandwidth developer-wise is just not there. Not even
close. So PHP does its best effort to keep BC, but up to a point while it
is sustainable. Beyond that point, as in 3 years of support, the older
versions have to be let go and development needs to continue. The project
has the rest of the programming world to keep pace with the limited
resources it has.

--=20

Arv=C4=ABds Godjuks
+371 26 851 664
arvids.godjuks@gmail.com
Telegram: @psihius https://t.me/psihius

--000000000000dacc6105f9033db6--