Article P++ is a bad idea for non-technical reasons
Last week the idea of changing PHP to include two languages "PHP" (Classic) and "P++" was proposed on the internals mailing list by Zeev and in more detail by a FAQ answering questions. For context, Zeev is one of the original authors of the Zend Engine in PHP 3 and 4 and co-founder of the Zend company, so the proposal got a lot of responses and additional discussions on Reddit and HackerNews.
The goal of the propsal is find a way to evolve the language PHP using a new dialect (P++) and stay backwards compatible by continuing to support the old dialect (PHP).
Zeev proposes a new tag would
<?p++ that sets the PHP compiler into a
different mode than
<?php now does, providing a "clean start" with BC
breaks and more strict typing syntax.
tl;dr: The proposal for P++ is at the core a proposal to have the PHP runtime support multiple versions of the PHP language at the same time. Other languages already have this distinction for ages (C with 89, 99, 11, ...). By going with a language version number instead of a new language name, we can avoid a lot of non-technical issues with P++.
I will start with a few non-technical arguments why I think this is a bad idea to introduce a distinct language called "P++" or any other name, with its own name and brand:
- From a "governing" perspective, introducing P++ is like a big bang that would force the community on a path without knowing all the implementation details up front. This goes against the current governing model of PHP where each larger technical decision is made democratically using the RFC process. At this point we have to respect and accept the fact that without a benelovant dictator, you cannot make these big bang changes in an open source project anymore. Improvements have to be made in incremental steps and P++ would not fit into this model.
- From an evolutionary perspective, the premise that the PHP community and internal teams can design a new language from the ivory tower, and get the details right the first time is pretence of knowledge fallacy. It is much more likely mistakes are made and then in 5 years we are back with the same problem. The P++ proposal sounds like a perpetual experimental version. It would be better to find a long term strategy to cope with incremental change to the language instead of a big bang change every 10 years.
- From a marketing perspective, introducing a new brand "P++" is going to be extremely hard to bring to the market. With "the PHP company" Zend swallowed by larger companies, there is no company with the primary goal of bringing forward the language anymore. PHP is truely a community effort now, without even a foundation. There is no centralized body that can effectively lead the marketing effort for this new P++ brand. We are not in 1979 anymore when C++ was invented, the language market is highly fought for and we as the PHP community are protected by PHPs enormous market share that we should not give up by fragmenting.
- I recognize "P++" is just a working name right now, a name without special characters is certainly a better idea. But a name different from PHP introduces even more problems w.r.t to SEO/Google and the way the PHP project is organized right now there isn't even a good process defined that would lead to a great outcome.
- From a documentation perspective, one of PHPs unique selling points is its awesome docs living on "php.net". As both dialects PHP and P++ would run on the same engine, it becomes much harder to represent this on the website. Here the argument that the P++ project is feasible even with few internal developers falls apart. It would require a completly overhauled new website, an approach to represent both dialects sufficiently without confusing users, new mailing lists, new everything.
- From a documentation perspective, assuming P++ were to break BC on Core APIs compared to PHP. Would php.net/strpos show the PHP and the P++ function body with haystack and needle switched? Or Would we need to copy the entire documentation? This would be a huge documentation team effort whose time hasn't been accounted for by the P++ FAQ/proposal.
- From a teaching perspective, Code examples in the wild on blogs, mailing lists and other sources often would need to make an extra effort to target either PHP, P++ or both. Knowledge would become clustered into two groups.
- From an ecosystem perspective, a second name/brand would complicate everything for third party vendors, conferences, magazines. Examples: "PHPStorm, the lightning smart PHP & P++ IDE", "Xdebug - Debugger and Profiler for PHP and P++", "Dutch PHP and P++ conference", "PHP and P++ Magazine". We would probably need to introduce another name for the runtime, say PVM, to allow to make a precise distiction. This adds even more confusion.
- From a SEO perspeective, Google and other search engines are a primary tool for software developers. If PHP and P++ now start fragmenting the communtiy it becomes much harder for developers to find solutions to problems, because "PHP sort array" will not find the articles "P++ sort array" that offer the same solution.
- A long time ago, PHP was described to me as the Borg of programming languages. Assimilating APIs, features, paradigms from everywhere. This is still a very good analogy. And today it supports even more paradigms than 15 years ago and gives users extreme freedom to choose between dynamic or strict typing. This has been done in a way with as few BC breaks as possible. Python 3 and Perl 6 are examples of languages that made it much much harder for users to upgrade. I don't see why suddenly now this approach is not possible anymore and requires two separate dialects.
The P++ proposal makes a few analogys to arrive at the P++ idea, but they are both flawed in my opinion:
- The analogy that P++ is to PHP what C++ is to C is wrong. C++ introduced a completly new paradigm (object oriented programming). P++ as proposed is PHP with some BC breaks. Its more comparable to Python 2 to 3.
With my arugments I have hopefully established enough non-technical arguments why separating PHP into two separate dialects is not a good idea.
But what are the alternatives to evolve the PHP language?
PHP could avoid all the non-technical problems that P++ would introduce by going with an approach like C, C++, ECMAScript or Rust have: Define different versions of the language that the Runtime/Compiler can all support. Currently PHP combines runtime and language and upgrading to PHP 7 runtime requires you to update your code to PHP 7 semantics.
In C you specify to the compiler according to which version of the standard the file should be compiled.:
gcc -std=c89 file.c gcc -std=c99 file.c
And then you can combine their output to a new binary which includes code compiled with both versions.
Rust has a smiliar concept named editions. In ECMAscript you use a third party compiler (like Babel) to compile one version down into another.
Essentially the proposed semantics of P++ boil down to defining a new version of PHPs language, they don't warrant a new language.
If we allow the PHP runtime to support several standards at the same time we can avoid fragmentation of the community, avoiding all the non-technical issues listed above.
PHP already uses
declare for this kind of decisions at the moment, so it
would be natural to introduce a construct to PHP and make it responsible for
switching the Compiler between different versions. Example with made up option
name and version:
This could be defined to automatically include strict_types=1, but also include some cleanup to type juggling rules for example. The sky is the limit. If we improve the language for the next version, we can introduce the next standard version, but the compiler could still support the old ones for a few years.
PHP users could upgrade to the latest version of the PHP runtime, get security patches, bugfixes, and performance improvements, but can keep the semantics of the version their software was written against. This would simplify the process of keeping backwards compatibility.
Deciding on the actual naming and syntax would be a minor technical problem.