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 PM Arvids Godjuks <arvids.godj...@gmail.com <mailto:arvids.godj...@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īds Godjuks > +371 26 851 664 > arvids.godj...@gmail.com <mailto:arvids.godj...@gmail.com> > Telegram: @psihius https://t.me/psihius >
