| Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision |
| pplusplus:faq [2019/08/12 10:05] – It's not "dynamic vs strict" but "loose dynamic vs strict dynamic" jasny | pplusplus:faq [2019/08/12 12:43] – Add Hack comparison zeev |
|---|
| There's no right or wrong here. Both points of view are valid. When we look at potential solutions to bridge between these two contradictory points of views, there aren't too many of them available: | There's no right or wrong here. Both points of view are valid. When we look at potential solutions to bridge between these two contradictory points of views, there aren't too many of them available: |
| |
| - **Stick with loose (aka weak) dynamic PHP**. This will not be accepted by the proponents of a stricter language. | - **Stick with dynamic PHP**. This will not be accepted by the proponents of a stricter language. |
| - **Evolve towards strict (aka strong) dynamic PHP**. This will not be accepted by the proponents of a loosely typed language. | - **Evolve towards a stricter PHP**. This will not be accepted by the proponents of a more dynamic language. |
| - **Fork the codebase**. This is a net loss option for everyone involved, regardless of how it's done. There's no technological advantage to doing that, and we don't have enough contributors to do that even if we wanted to (which we don't). | - **Fork the codebase**. This is a net loss option for everyone involved, regardless of how it's done. There's no technological advantage to doing that, and we don't have enough contributors to do that even if we wanted to (which we don't). |
| - **Come up with some creative solution to cater to both audiences**. This is what this proposal attempts to do. It does that while keeping the project itself unified, and while ensuring perpetual interoperability between the two dialects - so that while there'll be some level of fragmentation, it will be the minimal one possible that still addresses everyone's primary needs. | - **Come up with some creative solution to cater to both audiences**. This is what this proposal attempts to do. It does that while keeping the project itself unified, and while ensuring perpetual interoperability between the two dialects - so that while there'll be some level of fragmentation, it will be the minimal one possible that still addresses everyone's primary needs. |
| There's no shortage of challenges before we can run our first P++ app. | There's no shortage of challenges before we can run our first P++ app. |
| |
| - We need to get buy-in. That means that folks from both schools of though need to give up on a dream of having PHP be entirely dynamic or entirely typed, while disregarding those who think differently from them. This appears to be a very substantial challenge. | - We need to get buy-in. That means that folks from both schools of thought need to give up on a dream of having PHP be entirely dynamic or entirely statically typed while disregarding those who think differently from them. This appears to be a very substantial challenge. |
| - In order to be successful, the first version of P++ should deal with all, or at least most of compatibility-breaking changes from PHP - so that developers who make the (probably fairly painful) switch won't have to reaudit/radically refactor their code once more in the future. Some have voiced concern that they may be too optimistic to do in one installment with the limited developer-power we have. We'd have to evaluate that once we have a better idea of what that list is. Note that it does not mean we need to implement any and all ideas we may have for P++ at this first version - just that we should prioritize elements that would trigger substantial end-user code rewrites - and try to handle them before our first release. | - In order to be successful, the first version of P++ should deal with all, or at least most of compatibility-breaking changes from PHP - so that developers who make the (probably fairly painful) switch won't have to reaudit/radically refactor their code once more in the future. Some have voiced concern that they may be too optimistic to do in one installment with the limited developer-power we have. We'd have to evaluate that once we have a better idea of what that list is. Note that it does not mean we need to implement any and all ideas we may have for P++ at this first version - just that we should prioritize elements that would trigger substantial end-user code rewrites - and try to handle them before our first release. |
| - Of course, the most challenging of all - we need to find a reasonable name for this new dialect. | - Of course, the most challenging of all - we need to find a reasonable name for this new dialect. |
| |
| | |
| | ==== This is Hack all over again, isn't it? Why would it fair any better? ==== |
| | |
| | While conceptually the motivations for both P++ and Hack are similar - there are at least two critical differences between the two - each of which is likely sufficiently big to change the expected outcome. |
| | |
| | * Hack was/is developed by a single company, and not as an open process by volunteers. Even if the vendor that's behind it is gigantic - companies and individuals were often reluctant to standardize on a such a platform. |
| | * Perhaps more importantly - Hack (and HHVM) did not have PHP's gigantic distribution vehicle. |
| | * For Hack, it was an uphill battle for users to even give it a try: |
| | * They had to learn about its existence, and be sufficiently interested to learn more about it. |
| | * Assuming they were interested enough to give it a try - they had to go through the trouble of setting it up - using entirely different methods from the ones they were used to from the PHP days (different layout, different configuration, different everything). |
| | * With P++ - this is a radically different story from the ground up: |
| | * Every user of PHP (starting with 8.0, or whenever we make it available) - will have it available on their servers. You will not have to install anything, or set anything up - it will simply be there. |
| | * This in turn means that virtually anybody running a Linux distro, a recent version of WAMP, a recent version of MAMP - millions of servers and development workstations will have access to P++ without having to do anything proactively. |
| | * In terms of awareness - since P++ will be a big part of the "What's new in PHP 8" - it will enjoy free marketing like Hack could only dream of - similar to the PHP 7 performance splash (few in the PHP world are unaware of it). |
| | * Of course, it doesn't mean that everyone will want to start using it - but the barrier to entry with P++ is many orders of magnitude lower than what Hack to face. |
| | |
| | ==== What are the general concerns? ==== |
| | |
| | Arnold Daniels compiled [[https://wiki.php.net/pplusplus/concerns|a list of concerns]] about this proposal. |