Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119885
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>
In-Reply-To: <CADK1yXKCKzq=965HT85nYoJcQqfp=X_L1b_O6zpAn0UoxS66+Q@mail.gmail.com>
Date: Tue, 11 Apr 2023 00:42:19 +0300
Message-ID: <CAL0xaBH2OtLg0wiTHPr8L9=uz+No6zxoUMYA6avORra5qEdAcg@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="00000000000060325b05f9024131"
Subject: Re: [PHP-DEV] Future stability of PHP?
From: arvids.godjuks@gmail.com (Arvids Godjuks)

--00000000000060325b05f9024131
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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 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 t=
hat
>> 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 ove=
r
>> the next 6 months by picking up development speed by 3x with the same te=
am
>> of 5 people + me. In 1 year we started to literally take away clients fr=
om
>> 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 that
>> 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 han=
dle
>> data structures and handle the nulls for you en mass. Isolate the intern=
als
>> and just pass already sanitized values into it. Suddenly you cut off lik=
e
>> 90% of the needed fixes that prevent you from running your code. It's st=
ill
>> needs fixing, but at least you give it good data to start with, so it do=
es
>> 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 f=
or
> 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 long ago convinced th=
e
> 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 alway=
s.
> - like it or not, there is a community unhappy with how hard it has becom=
e
> 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 tests
> 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 than
> BC breaks on things first Introduced on or before PHP 5.6. If we could ju=
st
> have a way to opt-in to a faster-paced language for all new code while no=
t
> breaking PHP 5.6 features until the previous generation of software can b=
e
> 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.

P.S. I wish all the luck to the teams going with TypeScript rewrite. Having
dealt with NodeJS on a sizeable project - never again (the npm ecosystem
has an atrocious problem with code quality and bugs that are not fixed for
decades - you have to raw dog it on low-level nodejs drivers and modules to
get code that works reliably). I sincerely hope they know what they got
themselves into, considering they were working on a PHP project.

--=20

Arv=C4=ABds Godjuks
+371 26 851 664
arvids.godjuks@gmail.com
Telegram: @psihius https://t.me/psihius

--00000000000060325b05f9024131--