чт, 8 авг. 2019 г. в 22:17, Zeev Suraski <z...@php.net>: > [... and not in the Sith Lord kind of way.] > > *snip* > > Thoughts? > > Zeev >
Apparently, this exists: "ezmlm-reject: fatal: Sorry, I don't accept messages larger than 30000 bytes (#5.2.3)", so re-sending with Zeev's part sniped out :) Good day everyone, after literally sleeping on it and stewing for the most part of the morning to gather the thoughts and read other's feedback, here are my 0.02$ as a userland developer who has been on the list for 10+ years :) TL;DR. I think the proposal will not work. C++ worked because it was a completely different time, target audience and environment that does not exist in our day and just plain old lack of a team/resources to pull this behemoth of a feat (but if that would happen successfully, we will have to assign each of the developers an official status of "Wizzard"). The long version: Reason 1: Community and ecosystem. Just look back at how the adoption of 7.1 became to be - if Zeev is saying "overnight" for P++ and means 2-3 years of work, 7.1 was adopted/supported/became the minimum required essentially instantly. I mean it did not take even 6 months for major frameworks, communities and libraries to announce 7.1 support in next major versions or even 7.1 becoming the next minimum required. Some made plans even before 7.1 landed. I mean try updating a project to latest versions of libraries/frameworks today and still stay on 7.0 or 5.6. It is literally impossible because the community has moved on. What my feeling is that either majority will just jump ship to the new P++ or it will get ignored. All that means is that one or the other part will just lack the ecosystem support to survive the transition. I have to say I'm sorry, but today there are just too many alternatives to PHP that work just fine and fragmenting PHP into 2 language branches is just a bad idea. One of the primary reasons PHP did not succumb to winds of popularity and people returning to it for a more sane and stable environment is its ecosystem of robust libraries, tools and framework and people behind them keeping up to date with modern developments. I mean, just look at the 5 to 7 transition in the last 4 years - people dropped BC support like crazy, most of the complaints got "adapt or die" treatment and a lot of people ended up quite happy after doing the upgrades. Many discovered that the problem was a fly rather than an elephant. Tooling was available to automate transitions. Reason 2: Fragmentation, adoption Look at what happened to Hack - that is basically P++ in a nutshell. It got dropped by everyone as soon as PHP 7 got the speed boost and Hack team just saw no more reason to have anything to do with PHP. They also had trouble implementing or supporting parts of PHP functionality. In a sense, I could say the experiment got it's test run and failed. Reason 3: Evolution and resources Maintaining 2 versions of PHP will be daunting, to say the least. In not so distant past PHP core had a lack of resources to even maintain the primary implementation. I really really do not think the PHP core team has the bandwidth to do a P++. And while C is not by any means dying, it's scope of use is somewhat limited in a commercial application these days and it is hard to find jobs, meaning the pool of people who are able to skill up and contribute is small. If anything, I think the majority of people will jump the P++ bandwagon and not pay any attention to the PHP. So a handful of core devs will end up with the responsibility to maintain the PHP core and poor all their available time into it or just give up on it. I know I would jump the bandwagon in that situation without a second thought even if I'm trying to tell myself I'm a more responsible developer. I'm lying to myself :) Reason 4: Suggested features and modes. Going basically statically typed - thanks, but no thanks. There are numerous languages that are statically typed that are suitable for web development and that could and should be used in such an environment is desired. I know people who moved back into PHP because they wanted a more relaxed environment. I think `declare(strict_types=1)` mode got it right and future efforts to enhance that model should be the focus. I mean we ALREADY have 2 versions of PHP going - weak mode and strict mode. What if we just double down on the strict mode? I mean, I just had a wild idea - if a file is included from a "declare(strict_types=1)" scope - do not allow `<?` usage. If anything, we can introduce "declare(strict_mode=1)" for all such stuff (it will include strict_types) and this makes it opt-in and a valid upgrade path that actually can be done on a per-file basis. As a userland developer, I don't really want the core concept of PHP to change. It evolved nicely over time and I actually am on a steady moderate evolution side of things. If anything, these days a lot more effort should be put into fixing some of the extensions *khm*~PDO~*khm* and maybe working on some of the async and of course, don't forget the JIT - that will be a huge focus in next few years and can yield huge benefits to everyone and everything. Reason 5: The issue that spawned this thread What did tick me off about the short tag removal is the fact that there is an agreement on engine level behaviour switches need to be all removed. Short tags, as RFC states, is the last one left. I honestly and truly right now do not care if `<?` gets grandfathered in as `<?=` did. Though I'm opposed to leaving `<?`, we can make it a permanent parse error if that makes "code leaks" people happy and leave it there till, idk, PHP10. What I care about is `short_tags = On/Off` switch in php.ini surviving the purge and resulting in a long term promise that was honoured before this and now will be broken. P++ does not solve the original issue regardless. Reason 6: Extensions and parts of the standard library At this point, I feel, some attention needs to be redirected at maybe trying to come up with a cleanup solution for the standard library and handle the PDO that has been a pain in the ass for everyone to a point people don't really want to touch it and on the userland side it becoming a pain to work within certain cases and use workarounds. I mean really the more I work with databases, the more and more PDO restrictions, bugs or peculiarities I encounter and less and less I want to work with it. It is in dire need of either PDOv2 or a different solution. Closing thoughts: I feel like both hardcore camps Zeev is describing are too way off base and want basically impossible. The BC crowd is just being unreasonable and only the tech that evolves realistically survives. You cannot have the BC cake and eat it, at some point you have to upgrade and update your application code. I have migrated personally a 5.2 app straight into late 7.0 release. I did not find it especially hard and the client found the improved performance and development speedup worth the spend resources. If anything, it convinced him to pore resources into a proper rewrite of the system. I consider PHP to be in a good stot, it just needs a bit more spine in dropping BC things and because we have BC conscious people in the core, a lot of the times it is done gracefully and very well. But once a decade or so something comes up that just cannot technically be handled in a good way. But people have developed tools that automate the transition, there are validation tools, code style tools that ALL can detect and warn about planned upcoming BC break. And plan to actually drop the thing involves "a 5-year plan of gracefull depreciation, errors and final removal". What more the BC crowd wants to be done then? My view on this is this: "They are being unreasonable because a plan was made, automation tools were developed, information is being spread out. People's laziness is not a valid con argument". The "upgrade everything, BC be dammed" crowd also needs to chill. If you are so impatient - there is Go, NodeJS with it's JavaScript/TypeScript, etc. Right now PHP does has somewhat of a plan and direction it is going, it is going at a decent pace - not too slow, not too fast. The community is able to adopt the new features and changes in a timely manner and gracefully introduce their support or requirement without everyone running like headless chickens. So maybe solidify the plan, make it into an actual roadmap? That will allow people to make long term plans and decisions and make BC less of an issue. There is also the fact that major parts of PHP that were BC already got handled and BC breaks since 7.1 have been few and far in between. A few dangling BC issues that are still present just need a final push and we are going to end up in a somewhat clean state of things. A lot of future work is either self-contained new features or can be made opt-in behind a declare statement. As I have mentioned, why not expand "declare(strict_types=1)" into a concept of "declare(strict_mode=1)" and put a lot of upcoming RFC stuff under it? `<?` removal can go into that, so can go the strict operator RFC and other things that make PHP a more strict language. Thank you for reading. -- Arvīds Godjuks +371 26 851 664 arvids.godj...@gmail.com Skype: psihius Telegram: @psihius https://t.me/psihius
