[... 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
