Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106467
Date: Fri, 9 Aug 2019 07:11:52 +0200
To: Nikita Popov <nikita.ppv@gmail.com>, Zeev Suraski <zeev@php.net>
Cc: Internals <internals@lists.php.net>
Message-ID: <78d32666-9a9d-43ac-8c72-930d11cc1dff@Spark>
In-Reply-To: <CAJHtznxHR4wGv995yA7qGQ4ouJDwYU_m-93L5MXvQ-5vb24OEw@mail.gmail.com>
References: <CAJHtznz+vMtytUxnf73L474TcDUqsZpTHLTnhHL4E53CCQdibA@mail.gmail.com>
 <CAF+90c-5CeZfyo2zBeoM63NDK-j2h6WTjvdT-yiKy040wVUm-w@mail.gmail.com>
 <CAF+90c_etW4HU1ae9TLaZzKtaLtYbfkq2TKy4ydKOM=3XDRDXw@mail.gmail.com>
 <CAJHtznxHR4wGv995yA7qGQ4ouJDwYU_m-93L5MXvQ-5vb24OEw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="5d4d009d_4516dde9_15e39"
Subject: Re: [PHP-DEV] Bringing Peace to the Galaxy
From: brendt@stitcher.io (Brent)

--5d4d009d_4516dde9_15e39
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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 <nikita.ppv@gmail.com> wrote:
>
> > On Thu, Aug 8, 2019 at 11:02 PM Nikita Popov <nikita.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

--5d4d009d_4516dde9_15e39--