Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106453
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:From:Date:X-Gmail-Original-Message-Id:Message-ID:Subject:To:Content-Type;
	b=rOFh7VBY8M5HZWIwVLUZwwFzmY8RBC9oqNlOgkPSDPwl5spA6svtpeC+CvW3Wb
	t9oTdLIRTC1dGfQPyxsjhYHkhQ82dBcd/0ZttggxuCx6F9m42vdvLvM5g9sOApK9
	7VqRydMBH66jZxNhxwQeRg0rdljxbJkykMULFVJKzaXkw=;
MIME-Version: 1.0
Date: Thu, 8 Aug 2019 23:17:04 +0300
Message-ID: <CAJHtznz+vMtytUxnf73L474TcDUqsZpTHLTnhHL4E53CCQdibA@mail.gmail.com>
To: Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000005ed925058fa0bed1"
Subject: Bringing Peace to the Galaxy
From: zeev@php.net (Zeev Suraski)

--0000000000005ed925058fa0bed1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

[... 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 that
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 repair
(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 PHP
isn't in dire need of an overhauling repair and that as far as features 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 many
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 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 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 definitely
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 on
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 with
either downwards compatibility or 'language fit' - introducing a new flavor
of the language, which is available in addition to the current one instead
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 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 both
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 - 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) 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 probably
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 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 evolution
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 s=
till
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 th=
em) -
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 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 renewing
enthusiasm) around internals@ - are strong enough for us to brainstorm
about it.

Thoughts?

Zeev

--0000000000005ed925058fa0bed1--