чт, 8 авг. 2019 г. в 22:17, Zeev Suraski [email protected]:

[... 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

[email protected]

Skype: psihius

Telegram: @psihius https://t.me/psihius