Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106818
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, 30 Aug 2019 18:39:01 +0200
Message-ID: <CAH0Uv3GoB7d79Zn-wid_uxQHKOesHtDzgm6a_yuScjB0nfrVRQ@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: Zeev Suraski <zeev@php.net>, Internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Bringing Peace to the Galaxy
From: andreas@dqxtech.net (Andreas Hennings)

I would very much like to see "editions" or "generations".

> I do plan to create an RFC on this topic.

I am looking forward to this Proposal from Nikita.

So, at the risk of repeating some ideas that Nikita already mentioned
elsewhere, I am sharing my own thoughts..


## Motivation

In this mailing list, it often comes across as if BC support vs
"modernizing" the language is a matter of personal preference.
The reality is: After a given time, a complex PHP project (whether it
be a website or something else) will be a collection of old and new,
custom and 3rd party code.

The same applies to framework ecosystems, or the entire ecosystem of
3rd party libraries (in composer/packagist and elsewhere).

As a (website) project developer:
- I want to use the newest tricks of the language, and have the
strictest warnings possible, in new custom code.
- I want to pick from a wide variety of (old and new) 3rd party libraries.
- I don't want to be forced to update or replace legacy 3rd party
libraries, that might have been added before I even joined the
project, and I have no idea what they do.
- I don't want to be forced to fix old legacy custom code, of which I
don't know what it does. Or rather, I want to choose when to do this
based on the project life cycle.
- After phases of active development, I want to be able to put the
site in a mode where it "just works", until the client wants a major
revamp.
- I want the project to run on different local and server
environments, possibly sharing the space with other projects.

As a library/packge developer:
- I want to use the newest tricks of the language, and have the
strictest warnings possible, in new code.
- I want my library to be compatible with a wide audience with
different PHP versions. Existing projects should have the option to
include my library without throwing away or revamping all their old
stuff.
- If developing within a framework ecosystem (e.g. Drupal), I want my
library to be compatible with other packages in the same ecosystem,
and the PHP version(s) most commonly used within that ecosystem.
- After a phase of active development on (a major version of) the
package, I want the package (or that major version) to turn into a
low-maintenance mode, and focus either on the new major version, or on
other things in life. People should be able to use the aging package
without major disruption.

As a PHP language designer (which I cannot claim to be, but doing it anyway=
):
- I want modern PHP to be a "competitive" language.
- At the same time I want PHP to maintain the reputation of being a
stable and reliable platform for existing projects.
- I want a continuous, incremental evolution of the language, with one
change at a time, to allow for sufficient discussion and not lose the
community.
- I want to allow for future changes which I cannot even dream of today.

So I constantly want to "have my cake and eat it, too".
Not based on personal preference, but on real-world requirements.


## Proposal / Idea

The only way to make this possible is to either deny all progress, or
to make a distinction on file level (or "package level", whatever that
means).
So, opt-in BC breaks.

To me the "file level" seems most realistic.
If someone can make a convincing point of what "package level" would
mean technically, why not.
I just think that "package" is not a clearly defined term, and often
all you have is a file (e.g. with symlink, or when downloading a file
from some place).
And sometimes you might want different versions / generations in the
same package.

This would mean:
- A PHP file can specifiy the "generation" or "edition" or simply the
version of PHP that it claims to be compatible with. One (perhaps
silly) idea would be to have an alternative open tag like "<?php8". I
only hope we can come up with a syntax that feels natural and not
cryptic.
- The PHP installation on a given system could have multiple engines
which each have a different compatibility range. This range could be
further limited with runtime parameters.
- PHP engines with a narrower range might have better performance,
because they can be optimized for a specific generation of code
compatibility.
- Each PHP process (e.g. a web request) might have its own choice of
engine and runtime parameters.

Perhaps this sounds like a nightmare from a language / engine
maintainer perspective - not up to me to judge.


-- Andreas

On Thu, 8 Aug 2019 at 23:22, 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:
> >
> >> [... and not in the Sith Lord kind of way.]
> >>
> >> Looking at some of the recent (& not so recent) discussions on interna=
ls@
> >> ,
> >> 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 j=
ust
> >> want to clear some legacy stuff.  I think that in practice it goes wel=
l
> >> 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 exi=
st
> >> in
> >> other competing languages - are - in their opinion - sorely missing.
> >>
> >> At the other end of the spectrum, we have folks who think that we shou=
ld
> >> 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 feature=
s 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 m=
any
> >> 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 fee=
ls
> >> 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 oth=
er
> >> group - many of which I have very high respect for - are definitely no=
t
> >> good for the project (I hope that at least some of them feel in the sa=
me
> >> way when things happen in reverse).
> >>
> >> Now, what if there was a way to truly make both 'camps' happy?  I thin=
k
> >> there may be.
> >>
> >> There are several successful examples for how languages evolved
> >> dramatically while doing exactly that - retaining downwards compatibil=
ity
> >> while introducing radical changes - including compatibility breaking o=
nes
> >> -
> >> 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 defini=
tely
> >> cannot - but you can call C code from C++ code fairly transparently, a=
nd
> >> you wouldn't have to change anything at all in your C code.  If you ha=
ve a
> >> piece of code written in C and you don't care about C++ - you don't ha=
ve
> >> 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 wor=
k on
> >> C-based projects.  That will never change.
> >>
> >> Another somewhat similar example is ES6 - where a lot of new capabilit=
ies
> >> 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 PH=
P
> >> itself;  But, simultaneously - make the engine understand a new flavor=
 of
> >> the language (phure?  phun?  phlex?  phuture?) - a flavor where we'd i=
n
> >> fact be able to introduce a wide range of changes overnight - a lot mo=
re
> >> rapidly than even folks in the former camp feel comfortable doing toda=
y.
> >> 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 ins=
tead
> >> 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-mentio=
ned
> >> 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 bo=
th
> >> 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 - simila=
rly
> >> to how we do strict types (and we could probably entertain other optio=
ns
> >> as
> >> well, like doing it on a namespace level).
> >>
> >> I want to illustrate what I think this will buy us, at least from my P=
OV.
> >>
> >> In P++ (temp code name) - we'd be able to get rid of elements that hav=
e
> >> little going for them other than backwards compatibility - such as sho=
rt
> >> tags (not sure about hebrev :)).
> >>
> >> But more importantly - we could make much more radical changes a lot m=
ore
> >> quickly.  Since migration would be opt-in - we won't have to worry abo=
ut
> >> 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 prob=
ably
> >> 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 proba=
bly
> >> quite a few other things that currently bother some of us.  And we cou=
ld
> >> 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 developer=
s.
> >> 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 und=
er 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 fo=
r a
> >> long time, also has substantial downsides).
> >>
> >> Now, the PHP (old/current) flavor won=E2=80=99t stagnate either - it w=
ill 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 hav=
e
> >> 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 renew=
ing
> >> 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=3D2020) in every file. I was hoping to make this a
> > per-package declaration instead, but haven't found the perfect way to d=
o
> > 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 an=
d
> 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 larg=
er
> 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 yo=
ur
> language every five years ;) What we need is something that is sustainabl=
e
> 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 threa=
d,
> a new edition could require & annotations at call-sites and gain all the
> benefits that entails without breaking the ecosystem.
>
> Nikita