Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106454
MIME-Version: 1.0
References: <CAJHtznz+vMtytUxnf73L474TcDUqsZpTHLTnhHL4E53CCQdibA@mail.gmail.com>
In-Reply-To: <CAJHtznz+vMtytUxnf73L474TcDUqsZpTHLTnhHL4E53CCQdibA@mail.gmail.com>
Date: Thu, 8 Aug 2019 23:02:04 +0200
Message-ID: <CAF+90c-5CeZfyo2zBeoM63NDK-j2h6WTjvdT-yiKy040wVUm-w@mail.gmail.com>
To: Zeev Suraski <zeev@php.net>
Cc: Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000b0c863058fa15ff6"
Subject: Re: [PHP-DEV] Bringing Peace to the Galaxy
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000b0c863058fa15ff6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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 th=
at
> 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 repai=
r
> (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 PH=
P
> isn't in dire need of an overhauling repair and that as far as features g=
o
> - less is more - and we don't have to race to replicate features from oth=
er
> 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 on=
e
> 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 th=
at
> 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 als=
o
> 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 tha=
t
> you can run (or compile) any given piece of C code on C++ - you definitel=
y
> 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 o=
n
> 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 wit=
h
> either downwards compatibility or 'language fit' - introducing a new flav=
or
> of the language, which is available in addition to the current one instea=
d
> 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 contr=
ol
> the single relevant implementation of the language.  At this point - I al=
so
> 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 wa=
y
> that C++ code can run and interoperate with C code at runtime, despite
> being substantially different languages.  The runtime will simply know ho=
w
> 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) introdu=
ce
> 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 probabl=
y
> should) make it strict from the get go - and not just with types - but al=
so
> 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 evoluti=
on
> 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=E2=80=99t 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=E2=
=80=99t
> care for an ever evolving stricter language (and there=E2=80=99s 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 l=
ot
> 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=3D2020) 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

--000000000000b0c863058fa15ff6--