Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106458
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
	s=turbo-smtp; d=php.net;
	h=Received:Received:X-TurboSMTP-Tracking:X-Gm-Message-State:X-Google-Smtp-Source:X-Received:MIME-Version:References:In-Reply-To:From:Date:X-Gmail-Original-Message-Id:Message-ID:Subject:To:Cc:Content-Type;
	b=YghayJW6zDdp8l+6ERC62iJpF2tIe0d87nqDJtE0w83d6UYZjSIdak9rEbLYdc
	t7FLixt27c9TtUSWy35R2hW0Lv1ASL6W7fRjzbWYBW7wjagVCktV7qeRpPJLUAKP
	LO56kHnqW54BmcyVspIDWDwI/eYIWfcz4OnfEC/YgXTH0=;
MIME-Version: 1.0
References: <CAJHtznz+vMtytUxnf73L474TcDUqsZpTHLTnhHL4E53CCQdibA@mail.gmail.com> <CAF+90c-5CeZfyo2zBeoM63NDK-j2h6WTjvdT-yiKy040wVUm-w@mail.gmail.com> <CAF+90c_etW4HU1ae9TLaZzKtaLtYbfkq2TKy4ydKOM=3XDRDXw@mail.gmail.com>
In-Reply-To: <CAF+90c_etW4HU1ae9TLaZzKtaLtYbfkq2TKy4ydKOM=3XDRDXw@mail.gmail.com>
Date: Fri, 9 Aug 2019 00:58:47 +0300
Message-ID: <CAJHtznxHR4wGv995yA7qGQ4ouJDwYU_m-93L5MXvQ-5vb24OEw@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000002c435e058fa22a78"
Subject: Re: [PHP-DEV] Bringing Peace to the Galaxy
From: zeev@php.net (Zeev Suraski)

--0000000000002c435e058fa22a78
Content-Type: text/plain; charset="UTF-8"

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

--0000000000002c435e058fa22a78--