On Thu, Aug 8, 2019 at 10:17 PM Zeev Suraski <z...@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 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’t 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’t > care for an ever evolving stricter language (and there’s 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 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 >
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=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. Nikita
