Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119883
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>
In-Reply-To: <CAL0xaBGCw7szRaqJNdDHuZVoATms7dhCus4eXjUacAnLpBz+GA@mail.gmail.com>
Date: Mon, 10 Apr 2023 18:03:26 -0300
Message-ID: <CADK1yXKCKzq=965HT85nYoJcQqfp=X_L1b_O6zpAn0UoxS66+Q@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="00000000000068ba2205f901b5bf"
Subject: Re: [PHP-DEV] Future stability of PHP?
From: deleugyn@gmail.com (Deleu)

--00000000000068ba2205f901b5bf
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Apr 10, 2023, 4:01 PM Arvids Godjuks <arvids.godjuks@gmail.com>
wrote:

>
>
> On Mon, 10 Apr 2023 at 21:30, Deleu <deleugyn@gmail.com> wrote:
>
>> On Mon, Apr 10, 2023, 1:17 PM Pierre Joye <pierre.php@gmail.com> wrote:
>>
>> > hello,
>> >
>> >
>> > On Sun, Apr 9, 2023, 1:37 AM Stephan Soller <
>> stephan.soller@helionweb.de>
>> > wrote:
>> >
>> > > Hello,
>> > >
>> > > I'm sorry if this isn't the correct mailing list for that discussion
>> but
>> > I
>> > > couldn't find a more appropriate one where people actually know how
>> the
>> > > wind is
>> > > blowing.
>> > >
>> > > A few days ago I migrated a project from PHP 7.1 to 8.2 and the
>> amount of
>> > > deprecations and fatal errors spooked me a bit (details below if
>> you're
>> > > interested). That got me wondering about the long-term stability of
>> PHP
>> > > (as in
>> > > language and API breaks) and I looked at the RFCs. I got the
>> impression
>> > > that
>> > > static typing has a lot of traction now and I have no idea of what t=
he
>> > > fallout
>> > > might be of changing a dynamically typed language into a statically
>> > > typed one.
>> >
>> >
>> > I keep reading this in multiple languages, pr even more frameworks.
>> >
>> > I understand agency work, managers pushing new features instead of a
>> > cleaning some legacy.
>> >
>> > however years of ignoring deprecation notices (very few were introduce=
d
>> > right before 8.0).
>> >
>> > Most of them could have been fixed within a couple of hours in any cod=
e
>> > base, if they had tests.
>> >
>> > I would suggest, very very nicely, to review and rethink the developme=
nt
>> > flows of these projects instead of asking php to freeze.
>> >
>> > best,
>> > Pierre
>> >
>>
>> I resent the sentiment of "if your code or development process was exact=
ly
>> like mine you wouldn't be here complaining" and I believe nobody is aski=
ng
>> PHP to freeze. Not everyone has the ability to fix every deprecation
>> within
>> a couple of hours and not everyone has tests. Yes, we get it, it's commo=
n
>> knowledge nowadays that code without test is unmanageable, but if you
>> inherited a 15 year old codebase developed by multiple developers in a
>> start-up mentality producing code faster than they could actually plan f=
or
>> and with no tests, its going to take some time to clean that up and if I
>> take longer than you would, does it mean I matter less as a PHP user?
>>
>> PHP 8 is pretty great to work with and a lot better than previous
>> versions,
>> but there was no opt-in aspect to a lot of PHP breakages. All that we're
>> asking here is for a bit more forgiveness to existing code that was
>> developed 2 decades ago by a complete different generation and still nee=
d
>> to run today while we clean it up.
>>
>> >
>>
>
> 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 a=
ny
> 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 t=
he
> next job: "It's not my problem, the next guy will deal with this". And th=
at
> 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 over
> the next 6 months by picking up development speed by 3x with the same tea=
m
> of 5 people + me. In 1 year we started to literally take away clients fro=
m
> our competitors who could not keep up with us and we had a literal line o=
f
> clients to onboard, we had to scale our sales team 3x and had a backlog o=
f
> 6 months still. All stemmed from a single decision "I will tackle this, w=
e
> 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 majo=
r
> 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 hand=
le
> data structures and handle the nulls for you en mass. Isolate the interna=
ls
> and just pass already sanitized values into it. Suddenly you cut off like
> 90% of the needed fixes that prevent you from running your code. It's sti=
ll
> needs fixing, but at least you give it good data to start with, so it doe=
s
> 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 long ago convinced the
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 always.
- 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 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 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.

>

--00000000000068ba2205f901b5bf--