Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119892
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_36C93D2B-FB48-4998-8113-8557CABE6EF1"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\))
Date: Tue, 11 Apr 2023 01:16:07 +0100
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>
 <CAL0xaBGfoc5UF=U82o8PXrObcikozswkX2LFHN9BJg7PwX0ZJA@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
In-Reply-To: <CAL0xaBGfoc5UF=U82o8PXrObcikozswkX2LFHN9BJg7PwX0ZJA@mail.gmail.com>
Message-ID: <5E8E5486-B715-45DF-AB6F-35434CFB78D2@sewell.info>
Subject: Re: [PHP-DEV] Future stability of PHP?
From: php@sewell.info (Matthew Sewell)

--Apple-Mail=_36C93D2B-FB48-4998-8113-8557CABE6EF1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi,

This is a really interesting thread and am glad that Stephan raised it =
as I've been thinking along similar lines for a while now and am glad =
I'm not the only one.

Considering the range of people adding comments (especially someone like =
Mark) then I would hope everyone agrees that this deserves a full =
discussion (though am now concerned by a couple of Larry's comments that =
I've referenced below). If I may though, I'd like to take it back to =
Stephan's original point as I feel there is a bit of digression (though =
some is really interesting).

I generally come across 3 types of projects:
1. Projects that were originally developed a number of years ago and =
have not been updated since
2. Projects that were originally developed a number of years ago and =
have been updated regularly since
3. Projects that were originally developed in the last 5 years and have =
been updated regularly since

Generally projects in 1 match what Stephan described:
> My usual tool set for web projects like that is plain PHP, HTML, CSS =
and JS. Everything without any frameworks or unnecessary libraries and =
kept as simple as possible. If possible I just use builtin and stable =
APIs and usually end up without any or with just one or two dependencies =
(e.g. PDF generation).

I've tried to keep this generic, but in a lot of cases I see this with =
local government work that was developed several years ago (generally =
PHP 5). They had budget up front to build something but then expected to =
maintain it without any code changes, just by updating the OS and PHP. =
They perfectly match Stephan's use case group:
> I think a lot of programmers underestimate the flexibility and =
simplicity of file based webservers like Apache with PHP. If you keep it =
simple they allow projects to grow organically.
> A lot of that are just small projects, small customers or the =
inglorious everyday work that nobody likes but someone has to do. So it =
doesn't get talked about much.

These tend to run for 10 years plus.

Projects in 2 are the trickiest. They're often projects that were =
started in PHP 5 (or in some cases even 4) and have been upgraded over =
time. They're generally well maintained and structured code bases =
although don't have full test coverage. For these the upgrade to PHP 7 =
took a lot of planning and effort (and some of them have been my =
projects since the beginning so unlike the others I can't always even =
blame other people for most of the original decisions as they were mine =
15-20 years ago! ), though that was unsurprising given the context, but =
that process then needed to be repeated for PHP 8 (as previously =
mentioned, null handling was our biggest issue especially as we couldn't =
change our integrations with several hundred partners).

Projects in 3 are generally modern PHP applications, often using =
frameworks. They tend to be the easiest to maintain and upgrade as =
they're written as modern applications with full test coverage. Once you =
throw in the business processes around upgrading though they're still =
not as easy as is being suggested in some places here :)

As Andreas said:
> The PHP ecosystem even just in the last 10 years has changed =
completely, with composer, more mature frameworks, easily usable =
independent components and even static analyzers. For me that ecosystem =
is the big value proposition of PHP, in addition to a good standard =
library.

Does this mean that projects which use the traditional PHP approach =
(i.e. without the complexity) are now not considered a good fit for PHP?

Back to Stephan's original question. Is PHP still the best use case for =
type 1? A long running, simple application that doesn't use Composer or =
a framework that can be extended slightly over time?

If the answer to that is no then so is the answer to 2. In our case the =
projects in 2 are generally static because they're critical and =
therefore have budget, though haven't been upgraded to entirely new =
applications as they're overly complex, integrated with multiple =
partners or subject to legal regulations. Is PHP still a suitable =
language for building a long running, complex application that needs to =
be maintained for 20 years plus? The issue with this is more to do with =
the frequency of breaking changes?

Following on from that then I had some other thoughts and questions. I'm =
not suggesting that the issue isn't that there weren't warnings, and =
that deprecation notices weren't in place. The issue wasn't that we =
didn't know that the changes were coming, but that we had to make them.

As Ilija said (and his opinion is obviously very relevant):
> Sadly, there's a conflict of interest here. There are people who want =
to keep running their existing websites without having to make any =
changes, and there are people who are using PHP daily and would like to =
see the language evolve. We would like to satisfy both of these groups =
but that is difficult when they are often directly opposed. I do think =
that if we only manage to satisfy the former, PHP will gradually become =
less and less significant.

I think the voting mechanism alone will guarantee that the second group =
will be pre-dominant as the nature of eligible voters means that they =
will likely fall into that camp.

I think a lot of Mark's points are valid. I don't think anyone is =
suggesting that the language should freeze, but I think the point that =
much of the RFCs and upgrade paths assume that your code base is fully =
covered by tests and is a modern application is key. I also think Rob =
Landers' point is also really useful, especially the Rector one.

Again, I think everyone appreciates this is an open source project that =
has both volunteer and paid developers. Having experienced the all =
consuming nature of open source projects myself, I will always be =
grateful for the people whose efforts allow us to build upon them.

Having seen the stories a couple of years ago, and the start of the PHP =
Foundation that's given us an opportunity (as well as other tools like =
GitHub Sponsors and Patreon) to financially contribute to these projects =
but even that isn't enough. I resubscribed to the PHP mailing lists =
after 12 years last May and do think that a lot of the conversation (and =
RFCs) could benefit from additional inputs from different voices who =
aren't focused on the development. I'm as guilty as anyone else as I =
haven't spoken up before now either.

I also don't think this talk of blaming people is helpful. I don't think =
people are trying to blame people, but do want to consider how the =
process could be improved in the wild, particularly for non-IT =
organisations who build occasional or regular applications. I think =
everyone acknowledges that development environments and practices are =
changing but not as quickly or easily as sometimes is suggested.

I'd also like to ask for more detail on some of Larry's points:
> I know multiple internals devs who are not in this thread, who have =
been doing the work of keeping PHP going and moving it forward (and I do =
not count myself among their number), who took one look at this thread =
and went "nope, not this crap again, not interested."
> The OP at the start of this thread sounded earnest, even if this is a =
well-deceased horse by now.  The initial responses to him were =
reasonable.

Can I ask where I can read up on this? The first part worries me, but if =
there's somewhere where we could read up on it then that would be really =
helpful as I still have similar questions to Stephan. If it is a dead =
topic then it would be good to read up on the conclusions.

> Could internals do better on BC, to make upgrades easier?  Yes!  I =
have said so many times.  I proposed several possible improvements in =
the blog post above.  Mark Baker has focused on better risk analysis =
elsewhere in this thread, and that's fine.  A more formal, standard way =
to measure the risk of a change would be a good thing.  Let's discuss =
that.

I've enjoyed reading Larry's article, and will read it again and think =
it through further. It does make me think that just giving money isn't =
enough though and this needs more people to give their time and thoughts =
but would need to understand better how to do that.

Apologies for the long response, or for anything that isn't clear. I =
will give it some more thought but would appreciate the additional =
information so I can consider that further.

Thanks very much for all of your inputs, and to all the people who =
contribute to this project. Whatever questions we are raising I don't =
think that anyone should think we're not grateful to the efforts of =
everyone, or the sacrifices people make to keep a project like this =
going.

Best wishes,

Matt

P.S. Sorry if I've committed a mistake in my trimming, but the original =
response wouldn't accept as it said it was too large.

On Mon, Apr 10, 2023 at 11:53=E2=80=AFPM Arvids Godjuks =
<arvids.godjuks@gmail.com <mailto:arvids.godjuks@gmail.com>> wrote:
>
>
> 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.
>
> --
>
> Arv=C4=ABds Godjuks
> +371 26 851 664
> arvids.godjuks@gmail.com <mailto:arvids.godjuks@gmail.com>
> Telegram: @psihius https://t.me/psihius
>=20

--Apple-Mail=_36C93D2B-FB48-4998-8113-8557CABE6EF1--