Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106498
MIME-Version: 1.0
References: <CAJHtznz+vMtytUxnf73L474TcDUqsZpTHLTnhHL4E53CCQdibA@mail.gmail.com>
In-Reply-To: <CAJHtznz+vMtytUxnf73L474TcDUqsZpTHLTnhHL4E53CCQdibA@mail.gmail.com>
Date: Fri, 9 Aug 2019 18:30:29 +0200
Message-ID: <CAAfnsFV+QHxUF655JRcK2JR0Sk-dxZufAgmE34aTrjb6U211Xg@mail.gmail.com>
To: Zeev Suraski <zeev@php.net>
Cc: 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: 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 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

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.

--=20
Peter Kokot