Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119867
MIME-Version: 1.0
References: <aa9f0f66-f772-3fc4-4f66-2245930ab089@helionweb.de> <CAEZPtU6qV1OEBt7kaVoaxog=Wd4AZWNyiJW=1NMkASW8AJkRTA@mail.gmail.com>
In-Reply-To: <CAEZPtU6qV1OEBt7kaVoaxog=Wd4AZWNyiJW=1NMkASW8AJkRTA@mail.gmail.com>
Date: Mon, 10 Apr 2023 20:04:26 +0300
Message-ID: <CAL0xaBF36A3XUADe7DZGyDu5rmSN77o9rku4F0ApsCNHLchkdg@mail.gmail.com>
To: Pierre Joye <pierre.php@gmail.com>
Cc: Stephan Soller <stephan.soller@helionweb.de>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000a2a38f05f8fe5fe7"
Subject: Re: [PHP-DEV] Future stability of PHP?
From: arvids.godjuks@gmail.com (Arvids Godjuks)

--000000000000a2a38f05f8fe5fe7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 10 Apr 2023 at 19:18, 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 bu=
t
> 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 the
> > 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 introduced
> right before 8.0).
>
> Most of them could have been fixed within a couple of hours in any code
> base, if they had tests.
>
> I would suggest, very very nicely, to review and rethink the development
> flows of these projects instead of asking php to freeze.
>
> best,
> Pierre
>

Hello!

I also want to add that PHP is purely developed by open-source contributor
efforts who are limited in their numbers and not a lot of them are getting
compensated for it (exceptions being specific people working for companies
who have a vested interest in PHP development like JetBrains, hosting
giants and some others. And now PHP Foundation is there to help people get
paid for their crucial roles in PHP project and their dedicated time).
You also have a world on your hands that is changing - everywhere you look
things are going for a more typed approach. That's what developers of today
expect. That's the reality of how modern libraries are developed and old
libraries have been actively migrating to strict type code bases. This code
quality improvement absolutely takes a huge load off those developers'
shoulders. I'm seeing libraries out there now that basically require PHP
8.1 as a minimum because Enums are all the rage and almost half the
libraries I use have introduced them in their code in the latest versions
and authors just flat-out tell you "use the older version of the lib or
update your project"  (and I have at least 7 of them in my code already and
that project will never run on anything lower than 8.2). Some of the
biggest libraries out there have fully adopted SemVer and will bump the
minimal PHP version quite aggressively. And will tell you to pay for
commercial support or deal with it on your own. And now the Union types are
coming and I expect that to get adopted at a rapid pace by everyone and
their dog.

Just as owning your own house means you need to do the upkeep on a yearly
basis or it will become a mess, the same is with code and not maintaining
it - eventually, the roof will cave in and the costs of fixing it all will
skyrocket. And, frankly, this is the feeling I get from a lot of this
thread - the roof has collapsed and people are put into impossible
positions of "no, you can't have the time or resources to update the
project to the new PHP version, here are 20 KPI's for the next 3 months you
need to hit". The codebase was run on a credit of "this will be fixed down
the line". Well, the debt collectors now what their debt, their late fees
and lawyers want their slice of the pie.


Arv=C4=ABds Godjuks
+371 26 851 664
arvids.godjuks@gmail.com
Telegram: @psihius https://t.me/psihius

--000000000000a2a38f05f8fe5fe7--