Re: Bringing Peace to the Galaxy

First of all, Amen to Arvids Godjuks. I think managed to clearly convey the opinion of a majority of the PHP community. ---- Some small things I like to add. IMHO the backward-incompatible changes that are currently discussed aren't about radical changes, but incremental improvements. There are a number of issues common in PHP applications, that you don't often find in programs written in other languages. Experienced PHP developers hardly fall for these gotchas, but the quality of PHP applications written by novice developers is typically lower than, for example, written in Python. This is one of the reasons that it's becoming harder and harder to convince people, both within an organization as well as developers in general, to start any new project in PHP. There are issues that are considered unacceptable for a modern language. Requiring to fork PHP or create a new flavor is unreasonable when compared to other languages. C++ introduced a paradigm shift from a procedural to an object-oriented language. This can't be compared to the changes currently discussed. On the other hand, if we look at changes introduced with major releases in other languages, like Python, Perl, Java, EcmaScript, etc, we can only conclude that even the most progressive portion of the PHP community is still relatively conservative. Also, the notion that we always had a strong bias for downwards compatibility is not completely accurate. There have been extensive backward-incompatible changes in the past. None of the changes proposed today come even close to the impact that changing the behavior and finally removing register_globals had. Using a directive to apply backward-incompatible changes should not be expected to get a lot of support. The limited situation where this would be the case with strict_operators caused great opposition. The P++ directive proposal would take this, with all the downsides, to a whole nother level. LTS versions are the tried and tested method to ensure that legacy applications can continue to run. This is favorable to a highly experimental method. Sure LTS requires some extra effort from the maintainers, but not nearly to the same extent that a fork or flavor would. The real risk to the future of our language isn't related to legacy apps. A bit harsh, but they're vendor locked and will continue to use PHP anyway. On the other hand, this lack of interest in PHP by novice developers is a big problem, as is the diminishing number of new projects that are created in the language. We should prevent PHP from becoming a legacy language. In short, please just allow PHP to progress in a natural (and slow) pace, rather than forcing a fork which has changed to much that switching is not trivial and on the other side have an original that completely stagnant. Yours, Arnold [Arnold Daniels - Chat @ Spike](https://www.spikenow.com/?ref=spike-organic-signature&_ts=3yfvn) [3yfvn] On August 9, 2019 at 13:41 GMT, Zeev Suraski <zeev@php.net> wrote: