Bringing Peace to the Galaxy

  106453
August 8, 2019 20:17 zeev@php.net (Zeev Suraski)
[... and not in the Sith Lord kind of way.]

Looking at some of the recent (& not so recent) discussions on internals@,
some of the recent proposals, as well as some of the statements made
regarding the future direction of the language - makes it fairly clear that
we have a growing sense of polarization.

As Peter put it yesterday (I may be paraphrasing a bit) - some folks just
want to clear some legacy stuff.  I think that in practice it goes well
beyond that - many on internals@ see parts of PHP as in bad need of repair
(scoop: I agree with some of that), while other capabilities, that exist in
other competing languages - are - in their opinion - sorely missing.

At the other end of the spectrum, we have folks who think that we should
retain the strong bias for downwards compatibility we always had, that PHP
isn't in dire need of an overhauling repair and that as far as features go
- less is more - and we don't have to race to replicate features from other
languages - but rather opt for keeping PHP simple.

To a large degree, these views are diametrically opposed.  This made many
internals@ discussions turn into literally zero sum games - where when one
side 'wins', the other side 'loses', and vice versa.

It's fair to say that I'm a lot closer in the way I view things to the
latter camp that the former one.  But, at the same time - I understand that
there's merit to the other POV.  Even when my POV 'wins', it often feels as
a bit of a Pyrrhic victory, as the negative vibes from these zero sum
discussions and the feeling of disappointment felt by folks in the other
group - many of which I have very high respect for - are definitely not
good for the project (I hope that at least some of them feel in the same
way when things happen in reverse).

Now, what if there was a way to truly make both 'camps' happy?  I think
there may be.

There are several successful examples for how languages evolved
dramatically while doing exactly that - retaining downwards compatibility
while introducing radical changes - including compatibility breaking ones -
at the same time.

The most obvious example that comes to mind if C++.  It's a whole new
language, that clearly borrows a much of its basic syntax from C, but also
adds many fundamental new features on top of it - and changes behavior in
many situations.  When I say that C++ is compatible with C - it's not that
you can run (or compile) any given piece of C code on C++ - you definitely
cannot - but you can call C code from C++ code fairly transparently, and
you wouldn't have to change anything at all in your C code.  If you have a
piece of code written in C and you don't care about C++ - you don't have to
do anything at all.  In the same way, if you're a C developer, and don't
care much for C++ - you're not forced to learn it - as long as you work on
C-based projects.  That will never change.

Another somewhat similar example is ES6 - where a lot of new capabilities
are added without breaking anything about the underlying ES5.

By now I think the idea should be obvious - what if we did something
similar for PHP?

Essentially - radically slow down the amount of language-level (read:
syntax) changes - both additions, deprecations and modifications in PHP
itself;  But, simultaneously - make the engine understand a new flavor of
the language (phure?  phun?  phlex?  phuture?) - a flavor where we'd in
fact be able to introduce a wide range of changes overnight - a lot more
rapidly than even folks in the former camp feel comfortable doing today.
Since the vast majority of contention between the two camps has to do with
either downwards compatibility or 'language fit' - introducing a new flavor
of the language, which is available in addition to the current one instead
of replacing it - can provide a fundamental solution to both of these
points of contention.

We actually have a substantial advantage over both of the above-mentioned
language sets (C/C++ and JS/ES6) as for all practical purposes - we control
the single relevant implementation of the language.  At this point - I also
see no reason of why that implementation wouldn't be able to handle both
flavors of the language - sharing the same compiler and runtime - and
allowing them to run simultaneously alongside each other, in a similar way
that C++ code can run and interoperate with C code at runtime, despite
being substantially different languages.  The runtime will simply know how
to run in two different modes - depending on the file at hand - similarly
to how we do strict types (and we could probably entertain other options as
well, like doing it on a namespace level).

I want to illustrate what I think this will buy us, at least from my POV.

In P++ (temp code name) - we'd be able to get rid of elements that have
little going for them other than backwards compatibility - such as short
tags (not sure about hebrev :)).

But more importantly - we could make much more radical changes a lot more
quickly.  Since migration would be opt-in - we won't have to worry about
breaking people's code, and will be able to (and probably should) introduce
all of these things overnight, so that they're a part of a consistent new
paradigm and not a slow steady stream of breakage.  We could (and probably
should) make it strict from the get go - and not just with types - but also
with ops, variable declarations, etc.  We could change array behavior to
differentiate between integers and integer-looking-numbers.  And probably
quite a few other things that currently bother some of us.  And we could do
all that without sacrificing compatibility.

There's another advantage to doing that - it will allow us to rebrand.
It's no secret that PHP has a negative reputation among many developers.
Without getting into the question of whether it's justified or not -
starting with something that's a lot closer to a clean slate - and under a
different name - can make a much bigger impact than slow, gradual evolution
under the same name (which, as I've been working hard to illustrate for a
long time, also has substantial downsides).

Now, the PHP (old/current) flavor won’t stagnate either - it will still
benefit from evolution in extensions, other evolving pieces (like JIT or
other improvements in the runtime) and security updates.  Things which
those who care primarily about keeping their code working, or that don’t
care for an ever evolving stricter language (and there’s many of them) -
will be able to continue enjoying.

I admit, I haven't thought about every possible corner case we may have
here, and it's still very raw.  But at a high level, it seems to make a lot
of sense to me, and I think the advantages of going in this direction -
both technology related, and in restoring calm (and perhaps even renewing
enthusiasm) around internals@ - are strong enough for us to brainstorm
about it.

Thoughts?

Zeev
  106454
August 8, 2019 21:02 nikita.ppv@gmail.com (Nikita Popov)
On Thu, Aug 8, 2019 at 10:17 PM Zeev Suraski <zeev@php.net> wrote:

> [... and not in the Sith Lord kind of way.] > > Looking at some of the recent (& not so recent) discussions on internals@, > some of the recent proposals, as well as some of the statements made > regarding the future direction of the language - makes it fairly clear that > we have a growing sense of polarization. > > As Peter put it yesterday (I may be paraphrasing a bit) - some folks just > want to clear some legacy stuff. I think that in practice it goes well > beyond that - many on internals@ see parts of PHP as in bad need of repair > (scoop: I agree with some of that), while other capabilities, that exist in > other competing languages - are - in their opinion - sorely missing. > > At the other end of the spectrum, we have folks who think that we should > retain the strong bias for downwards compatibility we always had, that PHP > isn't in dire need of an overhauling repair and that as far as features go > - less is more - and we don't have to race to replicate features from other > languages - but rather opt for keeping PHP simple. > > To a large degree, these views are diametrically opposed. This made many > internals@ discussions turn into literally zero sum games - where when one > side 'wins', the other side 'loses', and vice versa. > > It's fair to say that I'm a lot closer in the way I view things to the > latter camp that the former one. But, at the same time - I understand that > there's merit to the other POV. Even when my POV 'wins', it often feels as > a bit of a Pyrrhic victory, as the negative vibes from these zero sum > discussions and the feeling of disappointment felt by folks in the other > group - many of which I have very high respect for - are definitely not > good for the project (I hope that at least some of them feel in the same > way when things happen in reverse). > > Now, what if there was a way to truly make both 'camps' happy? I think > there may be. > > There are several successful examples for how languages evolved > dramatically while doing exactly that - retaining downwards compatibility > while introducing radical changes - including compatibility breaking ones - > at the same time. > > The most obvious example that comes to mind if C++. It's a whole new > language, that clearly borrows a much of its basic syntax from C, but also > adds many fundamental new features on top of it - and changes behavior in > many situations. When I say that C++ is compatible with C - it's not that > you can run (or compile) any given piece of C code on C++ - you definitely > cannot - but you can call C code from C++ code fairly transparently, and > you wouldn't have to change anything at all in your C code. If you have a > piece of code written in C and you don't care about C++ - you don't have to > do anything at all. In the same way, if you're a C developer, and don't > care much for C++ - you're not forced to learn it - as long as you work on > C-based projects. That will never change. > > Another somewhat similar example is ES6 - where a lot of new capabilities > are added without breaking anything about the underlying ES5. > > By now I think the idea should be obvious - what if we did something > similar for PHP? > > Essentially - radically slow down the amount of language-level (read: > syntax) changes - both additions, deprecations and modifications in PHP > itself; But, simultaneously - make the engine understand a new flavor of > the language (phure? phun? phlex? phuture?) - a flavor where we'd in > fact be able to introduce a wide range of changes overnight - a lot more > rapidly than even folks in the former camp feel comfortable doing today. > Since the vast majority of contention between the two camps has to do with > either downwards compatibility or 'language fit' - introducing a new flavor > of the language, which is available in addition to the current one instead > of replacing it - can provide a fundamental solution to both of these > points of contention. > > We actually have a substantial advantage over both of the above-mentioned > language sets (C/C++ and JS/ES6) as for all practical purposes - we control > the single relevant implementation of the language. At this point - I also > see no reason of why that implementation wouldn't be able to handle both > flavors of the language - sharing the same compiler and runtime - and > allowing them to run simultaneously alongside each other, in a similar way > that C++ code can run and interoperate with C code at runtime, despite > being substantially different languages. The runtime will simply know how > to run in two different modes - depending on the file at hand - similarly > to how we do strict types (and we could probably entertain other options as > well, like doing it on a namespace level). > > I want to illustrate what I think this will buy us, at least from my POV. > > In P++ (temp code name) - we'd be able to get rid of elements that have > little going for them other than backwards compatibility - such as short > tags (not sure about hebrev :)). > > But more importantly - we could make much more radical changes a lot more > quickly. Since migration would be opt-in - we won't have to worry about > breaking people's code, and will be able to (and probably should) introduce > all of these things overnight, so that they're a part of a consistent new > paradigm and not a slow steady stream of breakage. We could (and probably > should) make it strict from the get go - and not just with types - but also > with ops, variable declarations, etc. We could change array behavior to > differentiate between integers and integer-looking-numbers. And probably > quite a few other things that currently bother some of us. And we could do > all that without sacrificing compatibility. > > There's another advantage to doing that - it will allow us to rebrand. > It's no secret that PHP has a negative reputation among many developers. > Without getting into the question of whether it's justified or not - > starting with something that's a lot closer to a clean slate - and under a > different name - can make a much bigger impact than slow, gradual evolution > under the same name (which, as I've been working hard to illustrate for a > long time, also has substantial downsides). > > Now, the PHP (old/current) flavor won’t stagnate either - it will still > benefit from evolution in extensions, other evolving pieces (like JIT or > other improvements in the runtime) and security updates. Things which > those who care primarily about keeping their code working, or that don’t > care for an ever evolving stricter language (and there’s many of them) - > will be able to continue enjoying. > > I admit, I haven't thought about every possible corner case we may have > here, and it's still very raw. But at a high level, it seems to make a lot > of sense to me, and I think the advantages of going in this direction - > both technology related, and in restoring calm (and perhaps even renewing > enthusiasm) around internals@ - are strong enough for us to brainstorm > about it. > > Thoughts? > > Zeev >
This is basically what I have been advocating for a while now already, somewhat hidden between all the other noise of the "namespace-scoped declares" thread. The model I would like to follow are Rust editions ( https://doc.rust-lang.org/edition-guide/editions/index.html). In PHP right now, the way to do this technically would be based on a declare(edition=2020) in every file. I was hoping to make this a per-package declaration instead, but haven't found the perfect way to do this right now. I think that introducing this kind of concept for PHP is very, very important. We have a long list of issues that we cannot address due to backwards compatibility constraints and will never be able to address, on any timescale, without having the ability of opt-in migration. I do plan to create an RFC on this topic. Nikita
  106456
August 8, 2019 21:22 nikita.ppv@gmail.com (Nikita Popov)
On Thu, Aug 8, 2019 at 11:02 PM Nikita Popov ppv@gmail.com> wrote:

> On Thu, Aug 8, 2019 at 10:17 PM Zeev Suraski <zeev@php.net> wrote: > >> [... and not in the Sith Lord kind of way.] >> >> Looking at some of the recent (& not so recent) discussions on internals@ >> , >> some of the recent proposals, as well as some of the statements made >> regarding the future direction of the language - makes it fairly clear >> that >> we have a growing sense of polarization. >> >> As Peter put it yesterday (I may be paraphrasing a bit) - some folks just >> want to clear some legacy stuff. I think that in practice it goes well >> beyond that - many on internals@ see parts of PHP as in bad need of >> repair >> (scoop: I agree with some of that), while other capabilities, that exist >> in >> other competing languages - are - in their opinion - sorely missing. >> >> At the other end of the spectrum, we have folks who think that we should >> retain the strong bias for downwards compatibility we always had, that PHP >> isn't in dire need of an overhauling repair and that as far as features go >> - less is more - and we don't have to race to replicate features from >> other >> languages - but rather opt for keeping PHP simple. >> >> To a large degree, these views are diametrically opposed. This made many >> internals@ discussions turn into literally zero sum games - where when >> one >> side 'wins', the other side 'loses', and vice versa. >> >> It's fair to say that I'm a lot closer in the way I view things to the >> latter camp that the former one. But, at the same time - I understand >> that >> there's merit to the other POV. Even when my POV 'wins', it often feels >> as >> a bit of a Pyrrhic victory, as the negative vibes from these zero sum >> discussions and the feeling of disappointment felt by folks in the other >> group - many of which I have very high respect for - are definitely not >> good for the project (I hope that at least some of them feel in the same >> way when things happen in reverse). >> >> Now, what if there was a way to truly make both 'camps' happy? I think >> there may be. >> >> There are several successful examples for how languages evolved >> dramatically while doing exactly that - retaining downwards compatibility >> while introducing radical changes - including compatibility breaking ones >> - >> at the same time. >> >> The most obvious example that comes to mind if C++. It's a whole new >> language, that clearly borrows a much of its basic syntax from C, but also >> adds many fundamental new features on top of it - and changes behavior in >> many situations. When I say that C++ is compatible with C - it's not that >> you can run (or compile) any given piece of C code on C++ - you definitely >> cannot - but you can call C code from C++ code fairly transparently, and >> you wouldn't have to change anything at all in your C code. If you have a >> piece of code written in C and you don't care about C++ - you don't have >> to >> do anything at all. In the same way, if you're a C developer, and don't >> care much for C++ - you're not forced to learn it - as long as you work on >> C-based projects. That will never change. >> >> Another somewhat similar example is ES6 - where a lot of new capabilities >> are added without breaking anything about the underlying ES5. >> >> By now I think the idea should be obvious - what if we did something >> similar for PHP? >> >> Essentially - radically slow down the amount of language-level (read: >> syntax) changes - both additions, deprecations and modifications in PHP >> itself; But, simultaneously - make the engine understand a new flavor of >> the language (phure? phun? phlex? phuture?) - a flavor where we'd in >> fact be able to introduce a wide range of changes overnight - a lot more >> rapidly than even folks in the former camp feel comfortable doing today. >> Since the vast majority of contention between the two camps has to do with >> either downwards compatibility or 'language fit' - introducing a new >> flavor >> of the language, which is available in addition to the current one instead >> of replacing it - can provide a fundamental solution to both of these >> points of contention. >> >> We actually have a substantial advantage over both of the above-mentioned >> language sets (C/C++ and JS/ES6) as for all practical purposes - we >> control >> the single relevant implementation of the language. At this point - I >> also >> see no reason of why that implementation wouldn't be able to handle both >> flavors of the language - sharing the same compiler and runtime - and >> allowing them to run simultaneously alongside each other, in a similar way >> that C++ code can run and interoperate with C code at runtime, despite >> being substantially different languages. The runtime will simply know how >> to run in two different modes - depending on the file at hand - similarly >> to how we do strict types (and we could probably entertain other options >> as >> well, like doing it on a namespace level). >> >> I want to illustrate what I think this will buy us, at least from my POV.. >> >> In P++ (temp code name) - we'd be able to get rid of elements that have >> little going for them other than backwards compatibility - such as short >> tags (not sure about hebrev :)). >> >> But more importantly - we could make much more radical changes a lot more >> quickly. Since migration would be opt-in - we won't have to worry about >> breaking people's code, and will be able to (and probably should) >> introduce >> all of these things overnight, so that they're a part of a consistent new >> paradigm and not a slow steady stream of breakage. We could (and probably >> should) make it strict from the get go - and not just with types - but >> also >> with ops, variable declarations, etc. We could change array behavior to >> differentiate between integers and integer-looking-numbers. And probably >> quite a few other things that currently bother some of us. And we could >> do >> all that without sacrificing compatibility. >> >> There's another advantage to doing that - it will allow us to rebrand. >> It's no secret that PHP has a negative reputation among many developers. >> Without getting into the question of whether it's justified or not - >> starting with something that's a lot closer to a clean slate - and under a >> different name - can make a much bigger impact than slow, gradual >> evolution >> under the same name (which, as I've been working hard to illustrate for a >> long time, also has substantial downsides). >> >> Now, the PHP (old/current) flavor won’t stagnate either - it will still >> benefit from evolution in extensions, other evolving pieces (like JIT or >> other improvements in the runtime) and security updates. Things which >> those who care primarily about keeping their code working, or that don’t >> care for an ever evolving stricter language (and there’s many of them) - >> will be able to continue enjoying. >> >> I admit, I haven't thought about every possible corner case we may have >> here, and it's still very raw. But at a high level, it seems to make a >> lot >> of sense to me, and I think the advantages of going in this direction - >> both technology related, and in restoring calm (and perhaps even renewing >> enthusiasm) around internals@ - are strong enough for us to brainstorm >> about it. >> >> Thoughts? >> >> Zeev >> > > This is basically what I have been advocating for a while now already, > somewhat hidden between all the other noise of the "namespace-scoped > declares" thread. The model I would like to follow are Rust editions ( > https://doc.rust-lang.org/ > <https://doc.rust-lang.org/edition-guide/editions/index.html> > edition-guide/editions/index.html > <https://doc.rust-lang.org/edition-guide/editions/index.html>). In PHP > right now, the way to do this technically would be based on a > declare(edition=2020) in every file. I was hoping to make this a > per-package declaration instead, but haven't found the perfect way to do > this right now. > > I think that introducing this kind of concept for PHP is very, very > important. We have a long list of issues that we cannot address due to > backwards compatibility constraints and will never be able to address, on > any timescale, without having the ability of opt-in migration. > > I do plan to create an RFC on this topic. >
After reading your mail again, I think what I have in mind is maybe quite different from what you have in mind after all, even if the motivation and purpose (language evolution without breaking legacy code) is the same. In particular, you seem to have a pretty strong focus on introducing a "new" language with a new name that just happens to interoperate with PHP. I don't think that's a direction we should be going down. One of the larger issues with that is that it only works once: You have one BC break point going between PHP and PHP++, but that's it. Unless you want to rebrand your language every five years ;) What we need is something that is sustainable in the long term. I also don't like the idea of rebranding as a new language. While PHP has a bad reputation, I really don't think that introducing PHP++ will do anything positive to that. PHP should stay PHP. The core language should remain the same across all editions/epochs/whatever -- just with the possibility of addressing specific issues. As discussed in a recent thread, a new edition could require & annotations at call-sites and gain all the benefits that entails without breaking the ecosystem. Nikita
  106458
August 8, 2019 21:58 zeev@php.net (Zeev Suraski)
On Fri, Aug 9, 2019 at 12:22 AM Nikita Popov ppv@gmail.com> wrote:

> On Thu, Aug 8, 2019 at 11:02 PM Nikita Popov ppv@gmail.com> wrote: > >> On Thu, Aug 8, 2019 at 10:17 PM Zeev Suraski <zeev@php.net> wrote: >> >> This is basically what I have been advocating for a while now already, >> somewhat hidden between all the other noise of the "namespace-scoped >> declares" thread. The model I would like to follow are Rust editions ( >> https://doc.rust-lang.org/ >> <https://doc.rust-lang.org/edition-guide/editions/index.html> >> edition-guide/editions/index.html >> <https://doc.rust-lang.org/edition-guide/editions/index.html>). In PHP >> right now, the way to do this technically would be based on a >> declare(edition=2020) in every file. I was hoping to make this a >> per-package declaration instead, but haven't found the perfect way to do >> this right now. >> >> I think that introducing this kind of concept for PHP is very, very >> important. We have a long list of issues that we cannot address due to >> backwards compatibility constraints and will never be able to address, on >> any timescale, without having the ability of opt-in migration. >> >> I do plan to create an RFC on this topic. >> > > After reading your mail again, I think what I have in mind is maybe quite > different from what you have in mind after all, even if the motivation and > purpose (language evolution without breaking legacy code) is the same. >
I'd describe my motivations quite differently than that. First, I want to point out that my very first motivation was in fact a human one - hence the subject line. I think there's substantial value in finding a solution for the constant contention on internals, without neither camp giving up on their principals and beliefs. Secondly - the current language-base of PHP (7.x) won't be 'legacy'. I think there's going to be a lot of new code written in it, and I think a lot of people would prefer it over P++ - even in 5 or 10 years. Again, C/C++ is a very good analogy here. If one camp remains 'missionary' about forcing the other camp to assimilate as the long term goal - that's not at all what I'm talking about. This is also why an edition named 'PHP2020' is somewhat problematic - as it implies you're behind if you're not using it. My goal is to have two sister languages, with both PHP and P++ being equal among equals, and not PHP being the 'dead language walking' and P++ being the end goal of everything. In particular, you seem to have a pretty strong focus on introducing a
> "new" language with a new name that just happens to interoperate with PHP. >
Not quite - it doesn't just happen to interoperate with PHP. It shares the same runtime; It shares the same extensions; It shares many of the same tools; And most importantly - it's very similar in its syntax. Again, here too, the C/C++ analogy works really well. Would you say C++ is a new language that just happens to interoperate with C? It's obviously a lot more than that. I don't think that's a direction we should be going down.
>
Oh well :|
> One of the larger issues with that is that it only works once: You have > one BC break point going between PHP and PHP++, but that's it. Unless you > want to rebrand your language every five years ;) What we need is something > that is sustainable in the long term. >
I think that the one, big-scoped compatibility breakage is a feature, not a bug. At the risk of sounding like a broken record - the C/C++ analogy works well here too, this time specifically C++. You can evolve the new language - even substantially - but C++ always stayed C++ and C always stayed C. Yes, there's C++03, C++11, etc. - but at the end of the day - the language is C++, and these editions are similar to the evolution we introduce in feature releases. If your goal is to have major BC breaks every five years, then I doubt we can find common grounds. But I'm not sure how many folks here think that's a good idea either. There's a big gap between thinking we should break away from 20+ year old chains that are they're fundamentally unhappy about, and moving to a 'let's redo the language every five years'.
> I also don't like the idea of rebranding as a new language. While PHP has > a bad reputation, I really don't think that introducing PHP++ will do > anything positive to that. PHP should stay PHP. The core language should > remain the same across all editions/epochs/whatever -- just with the > possibility of addressing specific issues. As discussed in a recent thread, > a new edition could require & annotations at call-sites and gain all the > benefits that entails without breaking the ecosystem. >
I'm sorry to hear that. In this particular case I really think you're wrong (FWIW) - rebranding can actually do a lot of positive things. It can stir interest. It can result in articles being written. It can make developers, development leaders and companies who have ruled out PHP reconsider their decision since "this is no longer PHP". A new version of PHP, or for that matter a new edition of PHP - will simply not have the same impact. As much as we're all technical people here, marketing matters. And in this particular case - this type of positioning does make sense - as with many of the proposed changes - this really is no longer PHP. Another thing it can also do is radically simplify the end-user understanding of our vision of what goes where, and what's in store for PHP as we currently know it. I'm truly hopeful that others on the list (and perhaps you as well) evaluate this proposal with an open mind. I did run by a few folks (from the 'other' camp) prior to publishing it, and response was very positive. Thanks, Zeev
  106467
August 9, 2019 05:11 brendt@stitcher.io (Brent)
Hi Zeev

Happy to see this proposal pop up, it's good to know that the "other side" is also open for long-term solutions. I think there needs to be a thorough analysis about the pros and cons of the two paths to take: a sister language vs. Nikita's proposal. To me, a userland developer, both solutions would have the same result in the end, so I trust internals to make a well-informed decision.

There's one thing I haven't seen mentioned yet though: what about the added workload for the core developers? You'll have to maintain two implementations of PHP, be it in the same runtime. Is this a load the core developers are able to carry? Aren't you afraid that development of the "old" version of PHP would quickly decline? If that were to happen, there's little difference in tagging a new major release with the breaking changes/cleanup we want.

Lastly, how do you envision interop between this two sister languages? Would a "normal" composer package be able to run in P++ ? You did mention P++ would share the same runtime, extensions, etc, but whether the runtime would be able to switch between the old and new version depending on the code wasn't clear to me.

Kind regards
Brent
On 8 Aug 2019, 23:59 +0200, Zeev Suraski <zeev@php.net>, wrote:
> On Fri, Aug 9, 2019 at 12:22 AM Nikita Popov ppv@gmail.com> wrote: > > > On Thu, Aug 8, 2019 at 11:02 PM Nikita Popov ppv@gmail.com> wrote: > > > > > On Thu, Aug 8, 2019 at 10:17 PM Zeev Suraski <zeev@php.net> wrote: > > > > > > This is basically what I have been advocating for a while now already, > > > somewhat hidden between all the other noise of the "namespace-scoped > > > declares" thread. The model I would like to follow are Rust editions ( > > > https://doc.rust-lang.org/ > > > <https://doc.rust-lang.org/edition-guide/editions/index.html> > > > edition-guide/editions/index.html > > > <https://doc.rust-lang.org/edition-guide/editions/index.html>). In PHP > > > right now, the way to do this technically would be based on a > > > declare(edition=2020) in every file. I was hoping to make this a > > > per-package declaration instead, but haven't found the perfect way to do > > > this right now. > > > > > > I think that introducing this kind of concept for PHP is very, very > > > important. We have a long list of issues that we cannot address due to > > > backwards compatibility constraints and will never be able to address, on > > > any timescale, without having the ability of opt-in migration. > > > > > > I do plan to create an RFC on this topic. > > > > > > > After reading your mail again, I think what I have in mind is maybe quite > > different from what you have in mind after all, even if the motivation and > > purpose (language evolution without breaking legacy code) is the same. > > > > I'd describe my motivations quite differently than that. > > First, I want to point out that my very first motivation was in fact a > human one - hence the subject line. I think there's substantial value in > finding a solution for the constant contention on internals, without > neither camp giving up on their principals and beliefs. > > Secondly - the current language-base of PHP (7.x) won't be 'legacy'. I > think there's going to be a lot of new code written in it, and I think a > lot of people would prefer it over P++ - even in 5 or 10 years. Again, > C/C++ is a very good analogy here. If one camp remains 'missionary' about > forcing the other camp to assimilate as the long term goal - that's not at > all what I'm talking about. This is also why an edition named 'PHP2020' is > somewhat problematic - as it implies you're behind if you're not using it. > > My goal is to have two sister languages, with both PHP and P++ being equal > among equals, and not PHP being the 'dead language walking' and P++ being > the end goal of everything. > > In particular, you seem to have a pretty strong focus on introducing a > > "new" language with a new name that just happens to interoperate with PHP. > > > > Not quite - it doesn't just happen to interoperate with PHP. It shares the > same runtime; It shares the same extensions; It shares many of the same > tools; And most importantly - it's very similar in its syntax. Again, > here too, the C/C++ analogy works really well. Would you say C++ is a new > language that just happens to interoperate with C? It's obviously a lot > more than that. > > I don't think that's a direction we should be going down. > > > > Oh well :| > > > > One of the larger issues with that is that it only works once: You have > > one BC break point going between PHP and PHP++, but that's it. Unless you > > want to rebrand your language every five years ;) What we need is something > > that is sustainable in the long term. > > > > I think that the one, big-scoped compatibility breakage is a feature, not a > bug. At the risk of sounding like a broken record - the C/C++ analogy > works well here too, this time specifically C++. You can evolve the new > language - even substantially - but C++ always stayed C++ and C always > stayed C. Yes, there's C++03, C++11, etc. - but at the end of the day - > the language is C++, and these editions are similar to the evolution we > introduce in feature releases. If your goal is to have major BC breaks > every five years, then I doubt we can find common grounds. But I'm not > sure how many folks here think that's a good idea either. There's a big > gap between thinking we should break away from 20+ year old chains that are > they're fundamentally unhappy about, and moving to a 'let's redo the > language every five years'. > > > > I also don't like the idea of rebranding as a new language. While PHP has > > a bad reputation, I really don't think that introducing PHP++ will do > > anything positive to that. PHP should stay PHP. The core language should > > remain the same across all editions/epochs/whatever -- just with the > > possibility of addressing specific issues. As discussed in a recent thread, > > a new edition could require & annotations at call-sites and gain all the > > benefits that entails without breaking the ecosystem. > > > > I'm sorry to hear that. In this particular case I really think you're > wrong (FWIW) - rebranding can actually do a lot of positive things. It can > stir interest. It can result in articles being written. It can make > developers, development leaders and companies who have ruled out PHP > reconsider their decision since "this is no longer PHP". A new version of > PHP, or for that matter a new edition of PHP - will simply not have the > same impact. As much as we're all technical people here, marketing > matters. And in this particular case - this type of positioning does make > sense - as with many of the proposed changes - this really is no longer > PHP. Another thing it can also do is radically simplify the end-user > understanding of our vision of what goes where, and what's in store for PHP > as we currently know it. > > I'm truly hopeful that others on the list (and perhaps you as well) > evaluate this proposal with an open mind. I did run by a few folks (from > the 'other' camp) prior to publishing it, and response was very positive. > > Thanks, > > Zeev
  106468
August 9, 2019 06:52 php-lists@koalephant.com (Stephen Reay)
> On 9 Aug 2019, at 12:11, Brent <brendt@stitcher.io> wrote: > > Hi Zeev > > Happy to see this proposal pop up, it's good to know that the "other side" is also open for long-term solutions. I think there needs to be a thorough analysis about the pros and cons of the two paths to take: a sister language vs. Nikita's proposal. To me, a userland developer, both solutions would have the same result in the end, so I trust internals to make a well-informed decision. > > There's one thing I haven't seen mentioned yet though: what about the added workload for the core developers? You'll have to maintain two implementations of PHP, be it in the same runtime. Is this a load the core developers are able to carry? Aren't you afraid that development of the "old" version of PHP would quickly decline? If that were to happen, there's little difference in tagging a new major release with the breaking changes/cleanup we want. > > Lastly, how do you envision interop between this two sister languages? Would a "normal" composer package be able to run in P++ ? You did mention P++ would share the same runtime, extensions, etc, but whether the runtime would be able to switch between the old and new version depending on the code wasn't clear to me. > > Kind regards > Brent >> On 8 Aug 2019, 23:59 +0200, Zeev Suraski <zeev@php.net>, wrote: >>> On Fri, Aug 9, 2019 at 12:22 AM Nikita Popov ppv@gmail.com> wrote: >>> >>>> On Thu, Aug 8, 2019 at 11:02 PM Nikita Popov ppv@gmail.com> wrote: >>>> >>>> On Thu, Aug 8, 2019 at 10:17 PM Zeev Suraski <zeev@php.net> wrote: >>>> >>>> This is basically what I have been advocating for a while now already, >>>> somewhat hidden between all the other noise of the "namespace-scoped >>>> declares" thread. The model I would like to follow are Rust editions ( >>>> https://doc.rust-lang.org/ >>>> <https://doc.rust-lang.org/edition-guide/editions/index.html> >>>> edition-guide/editions/index.html >>>> <https://doc.rust-lang.org/edition-guide/editions/index.html>). In PHP >>>> right now, the way to do this technically would be based on a >>>> declare(edition=2020) in every file. I was hoping to make this a >>>> per-package declaration instead, but haven't found the perfect way to do >>>> this right now. >>>> >>>> I think that introducing this kind of concept for PHP is very, very >>>> important. We have a long list of issues that we cannot address due to >>>> backwards compatibility constraints and will never be able to address, on >>>> any timescale, without having the ability of opt-in migration. >>>> >>>> I do plan to create an RFC on this topic. >>>> >>> >>> After reading your mail again, I think what I have in mind is maybe quite >>> different from what you have in mind after all, even if the motivation and >>> purpose (language evolution without breaking legacy code) is the same. >>> >> >> I'd describe my motivations quite differently than that. >> >> First, I want to point out that my very first motivation was in fact a >> human one - hence the subject line. I think there's substantial value in >> finding a solution for the constant contention on internals, without >> neither camp giving up on their principals and beliefs. >> >> Secondly - the current language-base of PHP (7.x) won't be 'legacy'. I >> think there's going to be a lot of new code written in it, and I think a >> lot of people would prefer it over P++ - even in 5 or 10 years. Again, >> C/C++ is a very good analogy here. If one camp remains 'missionary' about >> forcing the other camp to assimilate as the long term goal - that's not at >> all what I'm talking about. This is also why an edition named 'PHP2020' is >> somewhat problematic - as it implies you're behind if you're not using it.. >> >> My goal is to have two sister languages, with both PHP and P++ being equal >> among equals, and not PHP being the 'dead language walking' and P++ being >> the end goal of everything. >> >> In particular, you seem to have a pretty strong focus on introducing a >>> "new" language with a new name that just happens to interoperate with PHP. >>> >> >> Not quite - it doesn't just happen to interoperate with PHP. It shares the >> same runtime; It shares the same extensions; It shares many of the same >> tools; And most importantly - it's very similar in its syntax. Again, >> here too, the C/C++ analogy works really well. Would you say C++ is a new >> language that just happens to interoperate with C? It's obviously a lot >> more than that. >> >> I don't think that's a direction we should be going down. >>> >> >> Oh well :| >> >> >>> One of the larger issues with that is that it only works once: You have >>> one BC break point going between PHP and PHP++, but that's it. Unless you >>> want to rebrand your language every five years ;) What we need is something >>> that is sustainable in the long term. >>> >> >> I think that the one, big-scoped compatibility breakage is a feature, not a >> bug. At the risk of sounding like a broken record - the C/C++ analogy >> works well here too, this time specifically C++. You can evolve the new >> language - even substantially - but C++ always stayed C++ and C always >> stayed C. Yes, there's C++03, C++11, etc. - but at the end of the day - >> the language is C++, and these editions are similar to the evolution we >> introduce in feature releases. If your goal is to have major BC breaks >> every five years, then I doubt we can find common grounds. But I'm not >> sure how many folks here think that's a good idea either. There's a big >> gap between thinking we should break away from 20+ year old chains that are >> they're fundamentally unhappy about, and moving to a 'let's redo the >> language every five years'. >> >> >>> I also don't like the idea of rebranding as a new language. While PHP has >>> a bad reputation, I really don't think that introducing PHP++ will do >>> anything positive to that. PHP should stay PHP. The core language should >>> remain the same across all editions/epochs/whatever -- just with the >>> possibility of addressing specific issues. As discussed in a recent thread, >>> a new edition could require & annotations at call-sites and gain all the >>> benefits that entails without breaking the ecosystem. >>> >> >> I'm sorry to hear that. In this particular case I really think you're >> wrong (FWIW) - rebranding can actually do a lot of positive things. It can >> stir interest. It can result in articles being written. It can make >> developers, development leaders and companies who have ruled out PHP >> reconsider their decision since "this is no longer PHP". A new version of >> PHP, or for that matter a new edition of PHP - will simply not have the >> same impact. As much as we're all technical people here, marketing >> matters. And in this particular case - this type of positioning does make >> sense - as with many of the proposed changes - this really is no longer >> PHP. Another thing it can also do is radically simplify the end-user >> understanding of our vision of what goes where, and what's in store for PHP >> as we currently know it. >> >> I'm truly hopeful that others on the list (and perhaps you as well) >> evaluate this proposal with an open mind. I did run by a few folks (from >> the 'other' camp) prior to publishing it, and response was very positive. >> >> Thanks, >> >> Zeev
As a userland dev (both writing apps and maintaining a library/framework) I’m glad there is discussion about how to move forward, and if I understand his suggestion correctly, Nikita’s approach would be that language features are fundamentally enabled by declare statements as strict_types is now, but that there’d also be “collections” that can be set on, to enable multiple language features at once, AND ideally both single declares and the higher level collections would be able to be set at a level more broad than file based (eg namespace based). I like that this approach gives us a way forward with options for both fine and course grained choices on language features. However I’m also not sure how that particular approach would “solve” the open tags issue that (partly) started this discussion. I guess that whatever sets NS-based declares could define what tag is accepted for later loaded files, but that just moves an ini setting into a declare really. I’ll admit I can’t quite picture how Zeevs proposal would work, and honestly I have concerns it’d turn into a Python2 vs Python3 scenario. It would (seemingly) solve the open tags issue more easily though.. Cheers Stephen
  106457
August 8, 2019 21:25 zeev@php.net (Zeev Suraski)
On Fri, Aug 9, 2019 at 12:02 AM Nikita Popov ppv@gmail.com> wrote:

> This is basically what I have been advocating for a while now already, > somewhat hidden between all the other noise of the "namespace-scoped > declares" thread. The model I would like to follow are Rust editions ( > https://doc.rust-lang.org/edition-guide/editions/index.html). In PHP > right now, the way to do this technically would be based on a > declare(edition=2020) in every file. I was hoping to make this a > per-package declaration instead, but haven't found the perfect way to do > this right now. >
I think it's similar, but not quite the same, at least as far as what I understood from what you were saying on that thread (I just reread it). First, I think it's important we don't only focus on what we're going to change - but also on what we're going to keep. The motivation should not be slow eventual migration from one codebase to another. We would have two, long-term supported codebases - a lot closer to C and C++ than to different editions of a single language. The distance between them would be quite substantial from the get-go - and will likely grow farther as time goes by, similarly to the situation with C and C++. Also - I think that we should do our very best to get this "P++" right the first time, as opposed to iterate on it and release editions that provide a steady stream of change and breakage. Of course - we can add new features and evolve existing ones - but this should be a lot more similar to the mini versions / feature releases we currently have. It's certainly similar in concept, but not quite the same. Zeev
  106472
August 9, 2019 07:22 nikita.ppv@gmail.com (Nikita Popov)
On Thu, Aug 8, 2019 at 11:25 PM Zeev Suraski <zeev@php.net> wrote:

> > > On Fri, Aug 9, 2019 at 12:02 AM Nikita Popov ppv@gmail.com> wrote: > >> This is basically what I have been advocating for a while now already, >> somewhat hidden between all the other noise of the "namespace-scoped >> declares" thread. The model I would like to follow are Rust editions ( >> https://doc.rust-lang.org/edition-guide/editions/index.html). In PHP >> right now, the way to do this technically would be based on a >> declare(edition=2020) in every file. I was hoping to make this a >> per-package declaration instead, but haven't found the perfect way to do >> this right now. >> > > I think it's similar, but not quite the same, at least as far as what I > understood from what you were saying on that thread (I just reread it). > First, I think it's important we don't only focus on what we're going to > change - but also on what we're going to keep. The motivation should not > be slow eventual migration from one codebase to another. We would have > two, long-term supported codebases - a lot closer to C and C++ than to > different editions of a single language. The distance between them would > be quite substantial from the get-go - and will likely grow farther as time > goes by, similarly to the situation with C and C++. >
I think this part is unrealistic from a simple manpower perspective. We have something like ~2 full time developers working on PHP. Even if you can rally some additional interest around this idea, I don't think we have the resources to create a *substantially* different language in any reasonable amount of time. Doing feature additions and changes to PHP is Hard. Even simple changes require a fair bit of design and engineering effort to integrate with the large complexity of the existing language. This would not change for a hypothetical P++, because we still need to interoperate with PHP. Even if I agreed with the idea (which I'm pretty skeptical about in this particular form), I really don't think we have the resources to do something like this. Nikita
> Also - I think that we should do our very best to get this "P++" right the > first time, as opposed to iterate on it and release editions that provide a > steady stream of change and breakage. Of course - we can add new features > and evolve existing ones - but this should be a lot more similar to the > mini versions / feature releases we currently have. > > It's certainly similar in concept, but not quite the same. > > Zeev > > >
  106473
August 9, 2019 07:33 kris.craig@gmail.com (Kris Craig)
On Fri, Aug 9, 2019 at 12:22 AM Nikita Popov ppv@gmail.com> wrote:

> On Thu, Aug 8, 2019 at 11:25 PM Zeev Suraski <zeev@php.net> wrote: > > > > > > > On Fri, Aug 9, 2019 at 12:02 AM Nikita Popov ppv@gmail.com> > wrote: > > > >> This is basically what I have been advocating for a while now already, > >> somewhat hidden between all the other noise of the "namespace-scoped > >> declares" thread. The model I would like to follow are Rust editions ( > >> https://doc.rust-lang.org/edition-guide/editions/index.html). In PHP > >> right now, the way to do this technically would be based on a > >> declare(edition=2020) in every file. I was hoping to make this a > >> per-package declaration instead, but haven't found the perfect way to do > >> this right now. > >> > > > > I think it's similar, but not quite the same, at least as far as what I > > understood from what you were saying on that thread (I just reread it). > > First, I think it's important we don't only focus on what we're going to > > change - but also on what we're going to keep. The motivation should not > > be slow eventual migration from one codebase to another. We would have > > two, long-term supported codebases - a lot closer to C and C++ than to > > different editions of a single language. The distance between them would > > be quite substantial from the get-go - and will likely grow farther as > time > > goes by, similarly to the situation with C and C++. > > > > I think this part is unrealistic from a simple manpower perspective. We > have something like ~2 full time developers working on PHP. Even if you can > rally some additional interest around this idea, I don't think we have the > resources to create a *substantially* different language in any reasonable > amount of time. Doing feature additions and changes to PHP is Hard. Even > simple changes require a fair bit of design and engineering effort to > integrate with the large complexity of the existing language. This would > not change for a hypothetical P++, because we still need to interoperate > with PHP. > > Even if I agreed with the idea (which I'm pretty skeptical about in this > particular form), I really don't think we have the resources to do > something like this. > > Nikita > > I think it should also be pointed out that there's nothing stopping anyone
from forking PHP into a new project as Zeev described and maintain feature parity. As I understand, the reason something like this hasn't happened already is because it would involve a ton of work and nobody wants to deal with it. But if you or anyone else does manage to put a team together and make something like this happen as a separate project, I'd certainly have no objection. --Kris
  106474
August 9, 2019 07:38 krakjoe@gmail.com (Joe Watkins)
*alongside patch

Cheers
Joe

On Fri, 9 Aug 2019, 09:33 Kris Craig, craig@gmail.com> wrote:

> On Fri, Aug 9, 2019 at 12:22 AM Nikita Popov ppv@gmail.com> wrote: > > > On Thu, Aug 8, 2019 at 11:25 PM Zeev Suraski <zeev@php.net> wrote: > > > > > > > > > > > On Fri, Aug 9, 2019 at 12:02 AM Nikita Popov ppv@gmail.com> > > wrote: > > > > > >> This is basically what I have been advocating for a while now already, > > >> somewhat hidden between all the other noise of the "namespace-scoped > > >> declares" thread. The model I would like to follow are Rust editions ( > > >> https://doc.rust-lang.org/edition-guide/editions/index.html). In PHP > > >> right now, the way to do this technically would be based on a > > >> declare(edition=2020) in every file. I was hoping to make this a > > >> per-package declaration instead, but haven't found the perfect way to > do > > >> this right now. > > >> > > > > > > I think it's similar, but not quite the same, at least as far as what I > > > understood from what you were saying on that thread (I just reread it). > > > First, I think it's important we don't only focus on what we're going > to > > > change - but also on what we're going to keep. The motivation should > not > > > be slow eventual migration from one codebase to another. We would have > > > two, long-term supported codebases - a lot closer to C and C++ than to > > > different editions of a single language. The distance between them > would > > > be quite substantial from the get-go - and will likely grow farther as > > time > > > goes by, similarly to the situation with C and C++. > > > > > > > I think this part is unrealistic from a simple manpower perspective. We > > have something like ~2 full time developers working on PHP. Even if you > can > > rally some additional interest around this idea, I don't think we have > the > > resources to create a *substantially* different language in any > reasonable > > amount of time. Doing feature additions and changes to PHP is Hard. Even > > simple changes require a fair bit of design and engineering effort to > > integrate with the large complexity of the existing language. This would > > not change for a hypothetical P++, because we still need to interoperate > > with PHP. > > > > Even if I agreed with the idea (which I'm pretty skeptical about in this > > particular form), I really don't think we have the resources to do > > something like this. > > > > Nikita > > > > > I think it should also be pointed out that there's nothing stopping anyone > from forking PHP into a new project as Zeev described and maintain feature > parity. As I understand, the reason something like this hasn't happened > already is because it would involve a ton of work and nobody wants to deal > with it. But if you or anyone else does manage to put a team together and > make something like this happen as a separate project, I'd certainly have > no objection. > > --Kris >
  106475
August 9, 2019 07:39 sergey@s-panteleev.ru (Sergey Panteleev)
As I understand, in P++ it was planned to drop the legacy code, add new functionality and painlessly implement BC.

Who wants – migrates the PHP project in P++, who doesn't – continues to use PHP.

New projects, for example, will use P++ already.

Well, how is this different from the new version of PHP (e.g. PHP 9)?

Who wants – adapts his code for PHP 8/9 with all its BCs, who doesn't – continued to use PHP 7/8.

Because this discussion flows smoothly from a neighboring branch, let me remind you that a few percentages of users who continue to use short tags were discussed there.

Perhaps the same percentage of users will remain in PHP instead of the discussed P++.

Will the development of a new language be justified due to the few percentages of users?

—
Sincerely,
Sergey Panteleev
https://s-panteleev.ru
Telegram: @saundefined
E-mail: sergey@s-panteleev.ru
On 9 Aug 2019, 10:33 +0300, Kris Craig craig@gmail.com>, wrote:
> On Fri, Aug 9, 2019 at 12:22 AM Nikita Popov ppv@gmail.com> wrote: > > > On Thu, Aug 8, 2019 at 11:25 PM Zeev Suraski <zeev@php.net> wrote: > > > > > > > > > > > On Fri, Aug 9, 2019 at 12:02 AM Nikita Popov ppv@gmail.com> > > wrote: > > > > > > > This is basically what I have been advocating for a while now already, > > > > somewhat hidden between all the other noise of the "namespace-scoped > > > > declares" thread. The model I would like to follow are Rust editions ( > > > > https://doc.rust-lang.org/edition-guide/editions/index.html). In PHP > > > > right now, the way to do this technically would be based on a > > > > declare(edition=2020) in every file. I was hoping to make this a > > > > per-package declaration instead, but haven't found the perfect way to do > > > > this right now. > > > > > > > > > > I think it's similar, but not quite the same, at least as far as what I > > > understood from what you were saying on that thread (I just reread it). > > > First, I think it's important we don't only focus on what we're going to > > > change - but also on what we're going to keep. The motivation should not > > > be slow eventual migration from one codebase to another. We would have > > > two, long-term supported codebases - a lot closer to C and C++ than to > > > different editions of a single language. The distance between them would > > > be quite substantial from the get-go - and will likely grow farther as > > time > > > goes by, similarly to the situation with C and C++. > > > > > > > I think this part is unrealistic from a simple manpower perspective. We > > have something like ~2 full time developers working on PHP. Even if you can > > rally some additional interest around this idea, I don't think we have the > > resources to create a *substantially* different language in any reasonable > > amount of time. Doing feature additions and changes to PHP is Hard. Even > > simple changes require a fair bit of design and engineering effort to > > integrate with the large complexity of the existing language. This would > > not change for a hypothetical P++, because we still need to interoperate > > with PHP. > > > > Even if I agreed with the idea (which I'm pretty skeptical about in this > > particular form), I really don't think we have the resources to do > > something like this. > > > > Nikita > > > > > I think it should also be pointed out that there's nothing stopping anyone > from forking PHP into a new project as Zeev described and maintain feature > parity. As I understand, the reason something like this hasn't happened > already is because it would involve a ton of work and nobody wants to deal > with it. But if you or anyone else does manage to put a team together and > make something like this happen as a separate project, I'd certainly have > no objection. > > --Kris
  106476
August 9, 2019 08:15 michal.brzuchalski@gmail.com (=?UTF-8?Q?Micha=C5=82_Brzuchalski?=)
Hi Sergey,

pt., 9 sie 2019, 09:40 użytkownik Sergey Panteleev <sergey@s-panteleev..ru>
napisał:

> As I understand, in P++ it was planned to drop the legacy code, add new > functionality and painlessly implement BC. > > Who wants – migrates the PHP project in P++, who doesn't – continues to > use PHP. > > New projects, for example, will use P++ already. > > Well, how is this different from the new version of PHP (e.g. PHP 9)? > > Who wants – adapts his code for PHP 8/9 with all its BCs, who doesn't – > continued to use PHP 7/8. >
As I understand editions concept it would be far more easy to interoperate with old edition written library than in separate languages like PHP and P++. If new edition introduce syntax breaking change it would be still possible to to interoperate with old code in old edition and work on a project based on new edition. That way you can end up on for eg PHP8 supporting edition=2020 with new features which break compatibility but still working with PHP7.4 treated perhaps by default as edition=2019 in future versions. Cheers, Michał
>
  106484
August 9, 2019 12:23 zeev@php.net (Zeev Suraski)
On Fri, Aug 9, 2019 at 11:15 AM Michał Brzuchalski <
michal.brzuchalski@gmail.com> wrote:

> Hi Sergey, > > pt., 9 sie 2019, 09:40 użytkownik Sergey Panteleev <sergey@s-panteleev.ru> > napisał: > > > As I understand, in P++ it was planned to drop the legacy code, add new > > functionality and painlessly implement BC. > > > > Who wants – migrates the PHP project in P++, who doesn't – continues to > > use PHP. > > > > New projects, for example, will use P++ already. > > > > Well, how is this different from the new version of PHP (e.g. PHP 9)? > > > > Who wants – adapts his code for PHP 8/9 with all its BCs, who doesn't – > > continued to use PHP 7/8. > > > > As I understand editions concept it would be far more easy to interoperate > with old edition written library than in separate languages like PHP and > P++. If new edition introduce syntax breaking change it would be still > possible to to interoperate with old code in old edition and work on a > project based on new edition. >
If we intend to break syntax frequently, then yes. But this is poor language design. If we take a couple of years to focus on the fundamentals of what folks find objectionable about PHP today, and introduce P++ with solutions to these issues - there's no reason that every new version continues to break compatibility - certainly not in a substantial manner. We need to focus on the painful changes at the first stage, when P++ is introduced - while keeping other elements - ones which are incremental but do not introduce compatibility breaks - to a later time (if we don't have the developer-power to deliver them). If we let ourselves off the hook, and do these breakages in stages - editions are basically a workaround. Yes, editions would allow you to work around the fact that your code breaks every time you upgrade - but at a fundamental level, people are still wasting their time writing and rewriting and then rewriting once more the same code. Not to mention that unless I'm missing something, maintaining the implementation for all different editions would be more complicated than having just two dialects. Now, it doesn't come to say that P++ will never be able to break compatibility. We also break compatibility in PHP, in major versions. But it does mean that something along the lines of moving from dynamic to static, can't happen further down the line. Changing operator or type-conversion behavior - has to happen now and not further down the line. Features such as union types and others - can happen at a later stage. I don't think there's a need for editions for that purpose, the versions we have are sufficiently granular. Even more so since this will likely effect P++ more frequently than PHP - a crowd which appears to have a much stronger bias for features than for downwards compatibility. That way you can end up on for eg PHP8 supporting edition=2020 with new
> features which break compatibility but still working with PHP7.4 treated > perhaps by default as edition=2019 in future versions. >
I could be wrong, but I don't think that even Nikita thinks we'd have a new edition every year. Zeev
  106488
August 9, 2019 12:43 michal.brzuchalski@gmail.com (=?UTF-8?Q?Micha=C5=82_Brzuchalski?=)
Hi Zeev,

pt., 9 sie 2019, 14:23 użytkownik Zeev Suraski <zeev@php.net> napisał:

> > > On Fri, Aug 9, 2019 at 11:15 AM Michał Brzuchalski < > michal.brzuchalski@gmail.com> wrote: > >> Hi Sergey, >> >> pt., 9 sie 2019, 09:40 użytkownik Sergey Panteleev <sergey@s-panteleev.ru >> > >> napisał: >> >> > As I understand, in P++ it was planned to drop the legacy code, add new >> > functionality and painlessly implement BC. >> > >> > Who wants – migrates the PHP project in P++, who doesn't – continues to >> > use PHP. >> > >> > New projects, for example, will use P++ already. >> > >> > Well, how is this different from the new version of PHP (e.g. PHP 9)? >> > >> > Who wants – adapts his code for PHP 8/9 with all its BCs, who doesn't – >> > continued to use PHP 7/8. >> > >> >> As I understand editions concept it would be far more easy to interoperate >> with old edition written library than in separate languages like PHP and >> P++. If new edition introduce syntax breaking change it would be still >> possible to to interoperate with old code in old edition and work on a >> project based on new edition. >> > > If we intend to break syntax frequently, then yes. But this is poor > language design. > If we take a couple of years to focus on the fundamentals of what folks > find objectionable about PHP today, and introduce P++ with solutions to > these issues - there's no reason that every new version continues to break > compatibility - certainly not in a substantial manner. We need to focus on > the painful changes at the first stage, when P++ is introduced - while > keeping other elements - ones which are incremental but do not introduce > compatibility breaks - to a later time (if we don't have the > developer-power to deliver them). >
I've got an impression that you're the only one who sees a good direction in splitting the language in two different dialects and am not sure about sincere intentions. I may be wrong about that but I read this as a way to get evolutionary camp focus on own dialect and leave PHP in peace. But I think their interests are in language evolution and not in writing own language.
> If we let ourselves off the hook, and do these breakages in stages - > editions are basically a workaround. Yes, editions would allow you to work > around the fact that your code breaks every time you upgrade - but at a > fundamental level, people are still wasting their time writing and > rewriting and then rewriting once more the same code. Not to mention that > unless I'm missing something, maintaining the implementation for all > different editions would be more complicated than having just two dialects. > > Now, it doesn't come to say that P++ will never be able to break > compatibility. We also break compatibility in PHP, in major versions. But > it does mean that something along the lines of moving from dynamic to > static, can't happen further down the line. Changing operator or > type-conversion behavior - has to happen now and not further down the > line. Features such as union types and others - can happen at a later > stage. I don't think there's a need for editions for that purpose, the > versions we have are sufficiently granular. Even more so since this will > likely effect P++ more frequently than PHP - a crowd which appears to have > a much stronger bias for features than for downwards compatibility. > > That way you can end up on for eg PHP8 supporting edition=2020 with new >> features which break compatibility but still working with PHP7.4 treated >> perhaps by default as edition=2019 in future versions. >> > > I could be wrong, but I don't think that even Nikita thinks we'd have a > new edition every year. >
That's just an example. BR, Michał
>
  106491
August 9, 2019 13:12 zeev@php.net (Zeev Suraski)
On Fri, Aug 9, 2019 at 3:43 PM Michał Brzuchalski <
michal.brzuchalski@gmail.com> wrote:

> I've got an impression that you're the only one who sees a good direction > in splitting the language in two different dialects and am not sure about > sincere intentions. >
This isn't splitting the languages, much like TS/JS aren't "split languages" and C/C++ aren't "split languages". They're sister languages. For me, sisterhood implies a fairly close relationship. They would be sharing much of their syntax; They'd be sharing their runtime, and the developers who develop that runtime; They'd be sharing their extensions, and the developers who develop them; They'd be sharing most of their tools.
> I may be wrong about that but I read this as a way to get evolutionary > camp focus on own dialect and leave PHP in peace. >
If that's the impression I gave, I did a lousy job presenting my idea. I'm talking about creating P++ as a first-class citizen alongside PHP, on top of our unified runtime. When you download PHP - you'd be downloading P++ as well, and vice versa. They'd be versioned and released together. They'll share bugfixes. They'll share pretty much everything - except for the deltas in certain syntax elements and behavior. In a nutshell: would be PHP, while would be P++. That's on the same setup, two-in-one, same binaries (of course - name/tags/format subject to change, that's just an illustration). But I think their interests are in language evolution and not in writing
> own language. >
That languages have to evolve their syntax isn't an axiom. Much if not most of the evolution in most mature, popular languages happens at the layers above the language - the standard library, frameworks, apps. It's not a given that PHP's destiny is to become strictly typed and introduce more and more BC breaks. If you go back to my original piece, I'm trying to solve a fundamental problem that there are two huge camps who have diametrically opposing view about what needs to happen. It's clear what camp you're on, and that's absolutely fine - you're among many awesome people. But you need to realize that there's another huge camp, that thinks very differently than you about what needs to happen next. With such opposing views, there are two potential outcomes: - A zero sum game. A win for one camp is a loss for the other. We've been mostly in this mode for the last few years. It's not pleasant for anybody. - A creative solution that allows both camps to get what they want. Zeev
>
  106483
August 9, 2019 12:07 zeev@php.net (Zeev Suraski)
On Fri, Aug 9, 2019 at 10:40 AM Sergey Panteleev <sergey@s-panteleev.ru>
wrote:

> As I understand, in P++ it was planned to drop the legacy code,
Correct.
> add new functionality
Correct.
> and painlessly implement BC. >
Probably correct - but to phrase it more accurately - when we introduce P++ - we won't be bound by the same level of BC that we're bound by today - simply because migration would be opt in.
> Who wants – migrates the PHP project in P++, who doesn't – continues to > use PHP. >
Correct. Going forward, things begin to be less correct. P++ isn't "the future of PHP". It's something different, a sister language - that has a different philosophy. It's strongly typed, and has capabilities that many of the folks who want a more advanced/complex language appreciate. New projects, for example, will use P++ already.
>
Some will, some won't. There'll be plenty of new projects who will be written in PHP. And probably, plenty of new projects written in P++. Well, how is this different from the new version of PHP (e.g. PHP 9)?
>
It's very, very different. With this approach, even down the line in 2029, PHP remains PHP. None of us has a crystal ball to predict the future, but my guess is that WordPress will stick with PHP, and not move to P++. Based on feedback - Laravel (the most popular PHP framework) - will stick with PHP, and most probably many if not most of the new Laravel-based projects will do the same. If we stick with the current way of doing things, the tension between the strict camp and the dynamic camp (to oversimplify the distinction between them) are going to stay constant or get worse - essentially as many in the strict camp views the dynamic nature of PHP as 'legacy' (you're kind of alluding to that in your question). As much as it doesn't appear to be reflected on internals@ - there are TONS of people out there that like PHP's dynamic nature, and have absolutely no wish to become more and more strict as time passes by. Who wants – adapts his code for PHP 8/9 with all its BCs, who doesn't –
> continued to use PHP 7/8. >
No, that's not an option for a variety of reasons - for starters, it means that those who are unhappy with the direction the language is going towards, are essentially forced to leave it sooner or later - as they'd get no security updates, no performance improvements, no bugfixes, no new extensions, etc. Also, consider it a given that PHP has to stay a dynamic language. Making it exclusively strict simply isn't an option. Introducing strict while keeping the dynamic ones is an option - but it's a complicated one, and also entails inherent tensions - especially because many in the strict camp view this as a transition, and not an addition. The separation into two 'dialects' can provide a clean way for solving this long term. Because this discussion flows smoothly from a neighboring branch, let me
> remind you that a few percentages of users who continue to use short tags > were discussed there. >
I don't think that's relevant, but regardless - we have no data about how many people use short tags. 1% wasn't an estimate, it was just an illustration that even if it's 1% - it's a huge number of people. My guesstimate is that it's a lot more than 1%.
> Perhaps the same percentage of users will remain in PHP instead of the > discussed P++. >
No, not at all. There are a lot more folks who prefer the dynamic nature of PHP than folks who care about short tags. WordPress developers, Laravel developers - two of the biggest ecosystems in PHP (if not the biggest ones) - seem to generally prefer that. That in itself can easily be several tens of percents of the userbase.
> Will the development of a new language be justified due to the few > percentages of users? >
The ones who want to develop a new language aren't the ones in the dynamic camp. They're the ones in the strict camp. My proposal allows them to do exactly that, while living in peace with the dynamic camp. Zeev
  106486
August 9, 2019 12:38 lester@lsces.uk (Lester Caine)
On 09/08/2019 13:07, Zeev Suraski wrote:
> It's very, very different. > > With this approach, even down the line in 2029, PHP remains PHP. None of > us has a crystal ball to predict the future, but my guess is that WordPress > will stick with PHP, and not move to P++. Based on feedback - Laravel (the > most popular PHP framework) - will stick with PHP, and most probably many > if not most of the new Laravel-based projects will do the same. As a simplistic view isn't it just another framework? Haven't the the
likes of WordPress developed their own API on top of PHP and P++ is just another one? It just has the advantage that it can link deeper into the core engine than ones which simply sit on top? In exactly the same way C++ sits on top of C ? -- Lester Caine
  106479
August 9, 2019 10:44 robert@korulczyk.pl (Robert Korulczyk)
> I think it should also be pointed out that there's nothing stopping anyone > from forking PHP into a new project as Zeev described and maintain feature > parity. As I understand, the reason something like this hasn't happened > already is because it would involve a ton of work and nobody wants to deal > with it. But if you or anyone else does manage to put a team together and > make something like this happen as a separate project, I'd certainly have > no objection.
It does not need to be a fork. AFAIK there is no technical obstacle to extend lifetime of particular version on PHP and create some kind of LTS line. For example, PHP 7.4 could be supported for 10-20 years (probably with security patches only), so everyone who has "legacy - do not touch it!" code can stick to 7.4 line. Everyone else could just move on and use PHP 8 with all new features and BC breaks. Regards, Robert Korulczyk
  106487
August 9, 2019 12:39 zeev@php.net (Zeev Suraski)
On Fri, Aug 9, 2019 at 1:44 PM Robert Korulczyk <robert@korulczyk.pl> wrote:

> > I think it should also be pointed out that there's nothing stopping > anyone > > from forking PHP into a new project as Zeev described and maintain > feature > > parity. As I understand, the reason something like this hasn't happened > > already is because it would involve a ton of work and nobody wants to > deal > > with it. But if you or anyone else does manage to put a team together > and > > make something like this happen as a separate project, I'd certainly have > > no objection. > > It does not need to be a fork. AFAIK there is no technical obstacle to > extend lifetime of particular version on PHP and create some kind of LTS > line. > For example, PHP 7.4 could be supported for 10-20 years (probably with > security patches only), so everyone who has "legacy - do not touch it!" code > can stick to 7.4 line. Everyone else could just move on and use PHP 8 with > all new features and BC breaks. > > Kris, Robert,
I'm not sure what you're saying here exactly, but if you are suggesting that PHP.future, whatever this future version number is - is going to be a strictly typed language, with total disregard for BC - as folks who want to go on using and developing for the dynamic version of PHP, and/or want their existing humongous code bases to go on working - are forced to stick around with a dead-end version of the language, then no, it is simply not going to happen, ever. I think it would be a lousy outcome, but if that's what the "strict camp" wants, it's going to have to be that camp that forks. Whether it's a fork or LTS - this is a *radical* duplication of effort. The language engine is just one element - extension development, bug fixes, security fixes - all of these are critically important in order for either of these projects. If the two diverge - except for the immediate near term, these efforts would effectively have to happen twice, separately for each project. Because I think it's a lousy outcome for everyone - we should (IMHO) take it off the table, and focus on other outcomes that don't involve forking or de-facto forking (unlimited-term LTS). I believe my solution gives both camps virtually all of what they want - with perhaps the lack of indulgence of some missionary elements in the pro-change/strict/anti-BC camp. Since the dynamic camp isn't going anywhere, we really have two options - come to terms that there'll never be a fully strict version of PHP, or create some sort of mechanism to allow for both. Both Nikita's idea and mine are a form of the latter, although it *seems* Nikita's idea does have a long term goal of moving people - gently and not so gently - towards strict (over a long period of time). My idea treats both these dialects as equal among equals - and IMHO, also has some other advantages as far as clear messaging, market perception and potentially also maintainability. Zeev
  106489
August 9, 2019 13:06 robert@korulczyk.pl (Robert Korulczyk)
> I'm not sure what you're saying here exactly, but if you are suggesting > that PHP.future, whatever this future version number is - is going to be a > strictly typed language, with total disregard for BC /../
I'm suggesting that PHP could stop worrying about "super legacy code which uses short open tags and nobody wants to touch it" and move on. Code that nobody wants to touch can just use PHP LTS and PHP project could focus on programmers and actively developed projects.
> Whether it's a fork or LTS - this is a *radical* duplication of effort.
Bigger than creating P++ and having two different and competing languages? I highly doubt. Also, the LTS line could (and probably should) be sponsored. For example, most of BC breaks does not seem to be a problem for OSS. This is mostly a problem for companies with big and legacy applications, who don't want to spend money on upgrading them. If BC breaks are really such a big problem for thousands of companies, there should be no problem to find founders to pay ~1 developer for maintaining LTS line and backporting security fixes. Regards, Robert Korulczyk
  106493
August 9, 2019 13:25 zeev@php.net (Zeev Suraski)
On Fri, Aug 9, 2019 at 10:22 AM Nikita Popov ppv@gmail.com> wrote:

> On Thu, Aug 8, 2019 at 11:25 PM Zeev Suraski <zeev@php.net> wrote: > > I think this part is unrealistic from a simple manpower perspective. We > have something like ~2 full time developers working on PHP. Even if you can > rally some additional interest around this idea, I don't think we have the > resources to create a *substantially* different language in any reasonable > amount of time. Doing feature additions and changes to PHP is Hard. Even > simple changes require a fair bit of design and engineering effort to > integrate with the large complexity of the existing language. This would > not change for a hypothetical P++, because we still need to interoperate > with PHP. >
I think we should focus on the changes, and have additions as 2nd priority. We'll likely to get to some additions, just not all - it's fine to add them at a later stage, like the following mini version. Regardless of which direction we go for, it will probably be a good idea for us to pause for a moment and think about what are the major issues we'd want to address in PHP. I don't think the list of *changes* is that long that we can't pull off at least the majority of it in 2 years. Factor in the fact that instead of having heated discussions on internals@ and beyond - about language fit and BC - we'd be able to focus exclusively on the best solution for the problem - in the eyes of the folks in the 'strict' camp.
> Even if I agreed with the idea (which I'm pretty skeptical about in this > particular form), I really don't think we have the resources to do > something like this.
That may be, but I don't think that's the case. Perhaps it would help if we started a wiki page with topics that we'd want to address in such a hypothetical project. Strict ops, changes to type conversions, array indices, variable declarations, etc. I don't know that the list is *that* long. Even if we go for your 'edition' approach (which by the way, isn't entirely mutually exclusive from my idea - we could have these editions for P++ if we thought it made sense) - our users would be a lot better served if we handled the major BC breaks at first, as opposed to providing them in a steady flow of breakage. It would be a pretty lousy outcome if PHP2020-native frameworks and apps became fundamentally broken when upgrading to PHP2024. Zeev
  106512
August 9, 2019 21:57 kjarli@gmail.com (Lynn)
On Thu, Aug 8, 2019 at 11:02 PM Nikita Popov ppv@gmail.com> wrote:

> This is basically what I have been advocating for a while now already, > somewhat hidden between all the other noise of the "namespace-scoped > declares" thread. The model I would like to follow are Rust editions ( > https://doc.rust-lang.org/edition-guide/editions/index.html). In PHP right > now, the way to do this technically would be based on a > declare(edition=2020) in every file. I was hoping to make this a > per-package declaration instead, but haven't found the perfect way to do > this right now. > > I think that introducing this kind of concept for PHP is very, very > important. We have a long list of issues that we cannot address due to > backwards compatibility constraints and will never be able to address, on > any timescale, without having the ability of opt-in migration. > > I do plan to create an RFC on this topic. > > Nikita >
Hi, After reading several replies and discussing several solutions, I'd like to add my feedback to this. Regardless of implementation details, I prefer a structure similar to the control we have over strict types. I like the idea of being able to configure this per file, or per "package" (however this may be implemented). The benefit here is that a certain file, or package, could run in fancy mode, while (possibly legacy) application code can run in classic mode. I do assume here that it's primarily behavior changes, perhaps adding/removing/deprecating functions/classes etc, or throwing exceptions instead of returning false. I expect that both would be using the same parser in this scenario. I'm not exactly sure if this will fix the backwards compatibility concerns though, at some points BC will have to broken to advance in the classic mode. Who will decide when a feature should be added in classic mode, or a behavioral change should be done? One could assume that anything that's not backwards incompatible could be added without issues. Would that mean that only "big" BC breaking changes would be added to the fancy version? Would we be looking at the removal of `==` comparisons in this fancy mode for example? Regards, Lynn van der Berg
  106459
August 8, 2019 22:25 markyr@gmail.com (Mark Randall)
On 08/08/2019 21:17, Zeev Suraski wrote:
> [... and not in the Sith Lord kind of way.] > Thoughts?
I'm going to speak strictly as a userland PHP developer, for that is what I am. The idea of PHP being held hostage to eternal backwards compatibility fills me with absolute dread. I've built most of my career on PHP, I find it a very powerful platform, but I find it lacking in some major areas. Some of those have reasonable workarounds (React, Swoole) and some of them do not (var level type enforcement, generics, universal annotations, first class functions and other symbols, union types, CoW classes etc). I hope that some day, these problems are going to be fixed, but in the process I understand they may pose backwards compatibility issues. If PHP as a language cannot push forwards out of a concern for perpetual backwards compatibility, then I have to start questioning if it makes sense for me, and those I work with, to continue using it in the long run, vs a platform which is willing to find a way to make those changes and push things forward. I'm thinking 5 - 10 years here. As a developer, having to spend time on fixing BC breaks is obviously a cost. However, not having things that would have saved me time, or allowed me to write better code if they were there, but weren't added because of BC, is also a cost. To my mind, I would be happy to see a situation where I can stick a declare in my file that says "Give me the good stuff and I will find a way to deal with the BC breaks". I can deal with short term pain for long term gain. What I would struggle to deal with is committing myself and my clients to a language and ecosystem where history was constantly allowed to trump pragmatism. I understand it's obviously a big challenge for the internals team and its contributors to create coexistent systems with versioning, but I would simply offer the following: If you're not going forward, you're falling behind, and sometimes going forward requires sacrifice. Mark Randall
  106477
August 9, 2019 10:25 arvids.godjuks@gmail.com (Arvids Godjuks)
чт, 8 авг. 2019 г. в 22:17, Zeev Suraski <zeev@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 `godjuks@gmail.com Skype: psihius Telegram: @psihius https://t.me/psihius
  106490
August 9, 2019 13:12 Danack@basereality.com (Dan Ackroyd)
On Thu, 8 Aug 2019 at 21:17, Zeev Suraski <zeev@php.net> wrote:
> > My goal is to have two sister languages, with both PHP and P++ > being equal among equals
PHP internals is already lacking programming resources to do everything we want to be doing. Maintaining two versions at once would be more work, so this idea is not feasible without a dramatic increase in the number of people working on PHP core.
> I think that we should do our very best to get this > "P++" right the first time,
That's a fundamentally bad approach to designing a system. If an approach is worth doing, it's worth doing even if it's done poorly. https://www.amazon.co.uk/Systems-Bible-Beginners-Guide-Large/dp/0961825170 cheers Dan Ack
  106494
August 9, 2019 13:41 zeev@php.net (Zeev Suraski)
On Fri, Aug 9, 2019 at 4:12 PM Dan Ackroyd <Danack@basereality.com> wrote:

> On Thu, 8 Aug 2019 at 21:17, Zeev Suraski <zeev@php.net> wrote: > > > > My goal is to have two sister languages, with both PHP and P++ > > being equal among equals > > PHP internals is already lacking programming resources to do > everything we want to be doing. > > Maintaining two versions at once would be more work, so this idea is > not feasible without a dramatic increase in the number of people > working on PHP core. >
No, it won't. It will take no additional resources, and in fact, unless I'm missing something - Nikita's approach would in fact take more resources in the long run - as we'd have to maintain not just two dialects, but an open ended number of them. Much like it's hardly more work for us to maintain both strict and weak type hints, it shouldn't be significantly more work to maintain both dialects. The vast majority of work would be the one going into actually implementing the changed behavior and new features. Since even with Nikita's idea he's talking about providing a migration path, this is really not any more work *at all*. The only valid concern as far as efforts go, is whether we can pull off the main fundamental changes - the ones which will likely break any app if we don't introduce them from the get go - within a reasonable timeframe. I think it can be, but it remains to be seen.
> I think that we should do our very best to get this > > "P++" right the first time, > > That's a fundamentally bad approach to designing a system.
That's true, but we're not designing a system. We're designing a language. And to be more accurate - we're *re*designing a language, with ample experience, data and opinions on what we should have done differently. This is a lot closer to designing an API. And to keep the analogy working - it's like designing v2 of an API, after you've had a remarkably popular v1 and collected an endless amount of feedback about both what's good in it and what's bad. You'd be hard pressed to convince anybody that trying to get v2 - a version that breaks compatibility significantly and requires everyone to audit and refactor their code - right from the get go isn't a good idea that's well worth investing efforts in. Sure, you may not get around to implementing everything people are asking for - but if you're forced to break compatibility and are essentially asking people to partially rewrite their apps - you'd better make sure you do your best so that you don't have to ask them again a couple of years later down the line. With language design, it's actually a much bigger deal than with APIs (few APIs have the level of coupling with someone's code as their programming language does - hence the cost associated with fixing language-design mistakes is typically much, much bigger). Zeev
  106495
August 9, 2019 14:42 arnold.adaniels.nl@gmail.com (Arnold Daniels)
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:
  106498
August 9, 2019 16:30 peterkokot@gmail.com (Peter Kokot)
Hello,

On Thu, 8 Aug 2019 at 22:17, Zeev Suraski <zeev@php.net> wrote:
> > [... and not in the Sith Lord kind of way.] > > Looking at some of the recent (& not so recent) discussions on internals@, > some of the recent proposals, as well as some of the statements made > regarding the future direction of the language - makes it fairly clear that > we have a growing sense of polarization. > > As Peter put it yesterday (I may be paraphrasing a bit) - some folks just > want to clear some legacy stuff. I think that in practice it goes well > beyond that - many on internals@ see parts of PHP as in bad need of repair > (scoop: I agree with some of that), while other capabilities, that exist in > other competing languages - are - in their opinion - sorely missing. > > At the other end of the spectrum, we have folks who think that we should > retain the strong bias for downwards compatibility we always had, that PHP > isn't in dire need of an overhauling repair and that as far as features go > - less is more - and we don't have to race to replicate features from other > languages - but rather opt for keeping PHP simple. > > To a large degree, these views are diametrically opposed. This made many > internals@ discussions turn into literally zero sum games - where when one > side 'wins', the other side 'loses', and vice versa. > > It's fair to say that I'm a lot closer in the way I view things to the > latter camp that the former one. But, at the same time - I understand that > there's merit to the other POV. Even when my POV 'wins', it often feels as > a bit of a Pyrrhic victory, as the negative vibes from these zero sum > discussions and the feeling of disappointment felt by folks in the other > group - many of which I have very high respect for - are definitely not > good for the project (I hope that at least some of them feel in the same > way when things happen in reverse). > > Now, what if there was a way to truly make both 'camps' happy? I think > there may be. > > There are several successful examples for how languages evolved > dramatically while doing exactly that - retaining downwards compatibility > while introducing radical changes - including compatibility breaking ones - > at the same time. > > The most obvious example that comes to mind if C++. It's a whole new > language, that clearly borrows a much of its basic syntax from C, but also > adds many fundamental new features on top of it - and changes behavior in > many situations. When I say that C++ is compatible with C - it's not that > you can run (or compile) any given piece of C code on C++ - you definitely > cannot - but you can call C code from C++ code fairly transparently, and > you wouldn't have to change anything at all in your C code. If you have a > piece of code written in C and you don't care about C++ - you don't have to > do anything at all. In the same way, if you're a C developer, and don't > care much for C++ - you're not forced to learn it - as long as you work on > C-based projects. That will never change. > > Another somewhat similar example is ES6 - where a lot of new capabilities > are added without breaking anything about the underlying ES5. > > By now I think the idea should be obvious - what if we did something > similar for PHP? > > Essentially - radically slow down the amount of language-level (read: > syntax) changes - both additions, deprecations and modifications in PHP > itself; But, simultaneously - make the engine understand a new flavor of > the language (phure? phun? phlex? phuture?) - a flavor where we'd in > fact be able to introduce a wide range of changes overnight - a lot more > rapidly than even folks in the former camp feel comfortable doing today. > Since the vast majority of contention between the two camps has to do with > either downwards compatibility or 'language fit' - introducing a new flavor > of the language, which is available in addition to the current one instead > of replacing it - can provide a fundamental solution to both of these > points of contention. > > We actually have a substantial advantage over both of the above-mentioned > language sets (C/C++ and JS/ES6) as for all practical purposes - we control > the single relevant implementation of the language. At this point - I also > see no reason of why that implementation wouldn't be able to handle both > flavors of the language - sharing the same compiler and runtime - and > allowing them to run simultaneously alongside each other, in a similar way > that C++ code can run and interoperate with C code at runtime, despite > being substantially different languages. The runtime will simply know how > to run in two different modes - depending on the file at hand - similarly > to how we do strict types (and we could probably entertain other options as > well, like doing it on a namespace level). > > I want to illustrate what I think this will buy us, at least from my POV. > > In P++ (temp code name) - we'd be able to get rid of elements that have > little going for them other than backwards compatibility - such as short > tags (not sure about hebrev :)). > > But more importantly - we could make much more radical changes a lot more > quickly. Since migration would be opt-in - we won't have to worry about > breaking people's code, and will be able to (and probably should) introduce > all of these things overnight, so that they're a part of a consistent new > paradigm and not a slow steady stream of breakage. We could (and probably > should) make it strict from the get go - and not just with types - but also > with ops, variable declarations, etc. We could change array behavior to > differentiate between integers and integer-looking-numbers. And probably > quite a few other things that currently bother some of us. And we could do > all that without sacrificing compatibility. > > There's another advantage to doing that - it will allow us to rebrand. > It's no secret that PHP has a negative reputation among many developers. > Without getting into the question of whether it's justified or not - > starting with something that's a lot closer to a clean slate - and under a > different name - can make a much bigger impact than slow, gradual evolution > under the same name (which, as I've been working hard to illustrate for a > long time, also has substantial downsides). > > Now, the PHP (old/current) flavor won’t stagnate either - it will still > benefit from evolution in extensions, other evolving pieces (like JIT or > other improvements in the runtime) and security updates. Things which > those who care primarily about keeping their code working, or that don’t > care for an ever evolving stricter language (and there’s many of them) - > will be able to continue enjoying. > > I admit, I haven't thought about every possible corner case we may have > here, and it's still very raw. But at a high level, it seems to make a lot > of sense to me, and I think the advantages of going in this direction - > both technology related, and in restoring calm (and perhaps even renewing > enthusiasm) around internals@ - are strong enough for us to brainstorm > about it. > > Thoughts? > > Zeev
From my understanding the core thought and philosophy here is very great. Also thank you that we even have such discussion. It shows that PHP cares for future changes after all. Maybe instead of making two languages there probably is also some kind of other middle way (like it was mentioned in one of your emails in the past I think a bit): Something such as "legacy" extension (or better named to not cause issues with meaning that something like short tags will go away in future - the "traditional" extension) or something like that. Where developer would have option to enable it and use "traditional" or whatever named PHP functionalities such as short tags and things that cause so many issues and being sidelines. Without enabling (or importing that), PHP would behave more futuristic oriented. There will still be a need to take compromises in either case. Even in the PHP vs PHP++ case where people will want to change something in the PHP or do differently in PHP++. That's quite normal. Important thing is that everyone has a bit of an overview of everyone else also. One camp that recommends going without short tags and the other that wants these in, as an example. -- Peter Kokot