Yeah that is interesting. I think Hack dropped support for some popular frameworks awhile ago, hence dropping PHP compatibility.
I’m neither a PHP or Hack developer, but from the outside it looks like the two groups had diverging interests and couldn’t work together. Not saying that’s good or bad.
I did think Hack was a good idea, i.e. to rescue a bad but useful language, but I guess there is more than one way to do it.
There are two big, substantial schools of thought in the PHP world. The first likes PHP roughly the way it is - dynamic, with strong BC bias and emphasis on simplicity
FWIW this is essentially what I’m doing with Oil now: avoiding a fork of the language by making modes that are backward compatible.
I was originally leaning toward something more clean slate that you can translate to. But there are problems with that strategy. Besides being A LOT more work (more than I anticipated), it also:
significantly increases the bug surface area of the project (languages are full of corners; two languages are full of twice as many corners)
creates an unnatural “wall” in the user experience. Most people don’t know shell very well; making them learn a separate shell language and Oil language is a tall order.
Splits the ecosystem/community, etc. You don’t want to have two sets of libraries – it would be a similar pain as the decade-long maintenance of Python 2 and 3 compatibility via six.py and so forth.
You can argue that PHP is terrible and shell is terrible (and they are in many ways. They also both unquestionably get a lot of work done).
You can argue that we should invent time machines and go back and fix all the mistakes that were made.
But what doesn’t make sense is to argue that everyone should just start from scratch now from something clean – unless you actually pursue that yourself, in which case you will probably change your opinion after a few years. There are definitely a whole bunch of PHP-like languages that you probably don’t use because they don’t have the ecosystem around them.
Also, I plan to blog about these things, but for those who want to log in to Zulip (with Github, etc.), here are some examples:
shopt -s static-word-eval gets solves the “!QEFS problem”:
This doesn’t change the syntax – it improves the semantics.
There is also new syntax with shopt -s oil-parse-at to allow proper array and splicing, e.g. @a instead of "${a[@]}" (2 chars instead of an awkward 8 character dance)
BTW I am looking for feedback on those 2 features! Either here or on Zulip. I rewrote some shell snippets using them.
Also, after reading this PHP doc more carefully, I agree with the general gist, but there some places where I can tell they haven’t tried it yet. I had some similar misconceptions about implementing 2 dialects of the same language a couple years ago. The issue of “if statements” interspersed throughout the interpreter and the file-level syntax and semantic changes jumped out at me. I think it will be significantly harder to do for PHP than to do for shell, and shell is already hard. But I wish them luck!
I think PHP has lost its identity. I think P++ only muddies the waters more. The problems that PHP was originally meant to solve are now minor issues. The PHP team needs to decide on what niche or market they want to target and then go after it. They have spent years trying to be a little bit of everything but not the best at anything.
Another terrible PHP kludge from the people who’ve been bringing you PHP kludges for years
I’m being overly negative, but this whole document reads like a justification for not making a decision and ending up with something that is still attempting to mash together a hot mess with some clean ideas - placating and attempting to artificially hold together a whole community at the expense of clarity, specificity and different groups being able to specialise into their own areas.
If you’ve got to write something like ‘this isn’t a fork’ that many times, it’ll probably fork.
To me it reads like they want to avoid another Python 3 drama,to me that makes a lot of sense!
I’m being overly negative
Yeah, you don’t like PHP, based on an opinion formed in 2003? :)
The worst parts of PHP, for me as a PHP developer, are the bindings to C libraries like libxml2 and openssl. They are truly horrible and not really fixable, but that’s the same in other language because those library APIs suck.
It is not so difficult to use PHP’s “good parts”. It is very easy to write PHP code that runs on PHP 5.4 (2012) and still works great on 7.3 (2018) without any changes.
I still don’t like PHP, based on an opinion last revised two months ago.
It sounds like you believe that people, not languages, are to blame for when people write bad code in a language. But I think that the language, too, plays a role. Language helps us shape and anchor our thoughts. When a language has bad parts, not only must those parts be avoided, but they must be avoided at every junction throughout a language where we might consider using that part, or where that part intersects our thoughts. A language with bad error handling will make every call site into a hazard zone; a language with bad parsing will make a writer second-guess every usage of punctuation.
Keep in mind that a PHP environment is not just its version, but also its php.ini configuration.
As for the original article, I agree with the grandparent poster that it seems like an attempt to not confront the worst parts of PHP’s design. The language has so many misfeatures, and its core design principles are so compromised, that we really ought to not encourage any sort of backwards-compatibility. For example, the article says:
There are two big, substantial schools of thought in the PHP world. The first likes PHP roughly the way it is - dynamic, with strong BC bias and emphasis on simplicity; The other, prefers a stricter language, with reduced baggage and more advanced/complex features. There’s no ‘right’ or ‘wrong’ here. Both schools of thought are valid, and have a very substantial following.
To quote from my revised opinion:
Brent lists five tenets: active core development, performance, active ecosystem development, new features, and tooling. Eevee also lists five tenets: predictability, consistency, concision, reliability, and debuggability. Brent derives value from PHP by using PHP to solve problems for clients; PHP is a tool. However, Eevee considers PHP as an expressive medium, similar to natural languages or bytestrings, and asks how we might improve our ability to understand utterances of PHP.
It sounds like P++ is born almost entirely from Brent’s school of thought. Neither of the identified “schools of thought in the PHP world” value Eevee’s tenets at all, aside from P++ seeing concision by seeking to remove some “baggage”. However, rather than trying to improve linguistic clarity, the P++ author seeks only to remove unused language features in order to ease development and maintenance of the PHP core toolchain. In other words, this is actually a play for Brent’s desire for active core development, new features, and tooling.
A cousin comment points out that this proposal is somewhat analogous to use strict; directives in other languages. In those situations, namely Perl 5 and JS, strict dialects were an attempt to cut down on hard-to-compile, hard-to-analyze, hard-to-read, complicated, or underused language features. It’s easy to interpret P++ as seeking to reach an analogous house-cleaning.
They aren’t saying so, but it basically sounds the same as use strict from JavaScript and Perl. It specifically allows a single codebase to contain both PHP and “P++” code, unlike Python 3, and as a result allows you to incrementally migrate.
My biggest annoyance at PHP, unfortunately, is the way arrays work. And since arrays end up being part of library APIs, it’s impossible to maintain backwards compatibility while fixing it.
An incremental migration that will never be complete, so you have to drag along all that previous behaviour as well which might over time bit-rot as its usage drops to a low but non-negligible amount.
Sounds a little like the Rust “Editions” concept. I see that popping up a lot? Probably, because we have shown that it can be made work?
Not that I want to pat ourselves on the back, it’s just that I think it’s interesting to see how concepts travel. I think it would make sense to at some point make an honest writeup about what worked, what didn’t with edition 2018. (in general: it worked as intended, but there’s some stuff)
Surprisingly, no mention of Hack.
Yeah that is interesting. I think Hack dropped support for some popular frameworks awhile ago, hence dropping PHP compatibility.
I’m neither a PHP or Hack developer, but from the outside it looks like the two groups had diverging interests and couldn’t work together. Not saying that’s good or bad.
I did think Hack was a good idea, i.e. to rescue a bad but useful language, but I guess there is more than one way to do it.
The article appears to mention Hack now: https://wiki.php.net/pplusplus/faq#this_is_hack_all_over_again_isn_t_it_why_would_it_fair_any_better
What does BC mean here?
“Backwards compatibility” would be my guess.
FWIW this is essentially what I’m doing with Oil now: avoiding a fork of the language by making modes that are backward compatible.
I was originally leaning toward something more clean slate that you can translate to. But there are problems with that strategy. Besides being A LOT more work (more than I anticipated), it also:
six.pyand so forth.You can argue that PHP is terrible and shell is terrible (and they are in many ways. They also both unquestionably get a lot of work done).
You can argue that we should invent time machines and go back and fix all the mistakes that were made.
But what doesn’t make sense is to argue that everyone should just start from scratch now from something clean – unless you actually pursue that yourself, in which case you will probably change your opinion after a few years. There are definitely a whole bunch of PHP-like languages that you probably don’t use because they don’t have the ecosystem around them.
Also, I plan to blog about these things, but for those who want to log in to Zulip (with Github, etc.), here are some examples:
shopt -s static-word-evalgets solves the “!QEFS problem”:https://oilshell.zulipchat.com/#narrow/stream/121540-oil-discuss/topic/New.20static-word-eval.20mode
This doesn’t change the syntax – it improves the semantics.
shopt -s oil-parse-atto allow proper array and splicing, e.g.@ainstead of"${a[@]}"(2 chars instead of an awkward 8 character dance)https://oilshell.zulipchat.com/#narrow/stream/121540-oil-discuss/topic/New.20Oil.20language.20features!
That is, I finally implemented the proposal in Thirteen Incorrect Ways and Two Awkward Ways to Use Arrays which I wrote almost 3 years ago!!!
BTW I am looking for feedback on those 2 features! Either here or on Zulip. I rewrote some shell snippets using them.
Also, after reading this PHP doc more carefully, I agree with the general gist, but there some places where I can tell they haven’t tried it yet. I had some similar misconceptions about implementing 2 dialects of the same language a couple years ago. The issue of “if statements” interspersed throughout the interpreter and the file-level syntax and semantic changes jumped out at me. I think it will be significantly harder to do for PHP than to do for shell, and shell is already hard. But I wish them luck!
I think PHP has lost its identity. I think P++ only muddies the waters more. The problems that PHP was originally meant to solve are now minor issues. The PHP team needs to decide on what niche or market they want to target and then go after it. They have spent years trying to be a little bit of everything but not the best at anything.
Another terrible PHP kludge from the people who’ve been bringing you PHP kludges for years
I’m being overly negative, but this whole document reads like a justification for not making a decision and ending up with something that is still attempting to mash together a hot mess with some clean ideas - placating and attempting to artificially hold together a whole community at the expense of clarity, specificity and different groups being able to specialise into their own areas.
If you’ve got to write something like ‘this isn’t a fork’ that many times, it’ll probably fork.
To me it reads like they want to avoid another Python 3 drama,to me that makes a lot of sense!
Yeah, you don’t like PHP, based on an opinion formed in 2003? :)
The worst parts of PHP, for me as a PHP developer, are the bindings to C libraries like libxml2 and openssl. They are truly horrible and not really fixable, but that’s the same in other language because those library APIs suck.
It is not so difficult to use PHP’s “good parts”. It is very easy to write PHP code that runs on PHP 5.4 (2012) and still works great on 7.3 (2018) without any changes.
I still don’t like PHP, based on an opinion last revised two months ago.
It sounds like you believe that people, not languages, are to blame for when people write bad code in a language. But I think that the language, too, plays a role. Language helps us shape and anchor our thoughts. When a language has bad parts, not only must those parts be avoided, but they must be avoided at every junction throughout a language where we might consider using that part, or where that part intersects our thoughts. A language with bad error handling will make every call site into a hazard zone; a language with bad parsing will make a writer second-guess every usage of punctuation.
Keep in mind that a PHP environment is not just its version, but also its
php.iniconfiguration.As for the original article, I agree with the grandparent poster that it seems like an attempt to not confront the worst parts of PHP’s design. The language has so many misfeatures, and its core design principles are so compromised, that we really ought to not encourage any sort of backwards-compatibility. For example, the article says:
To quote from my revised opinion:
It sounds like P++ is born almost entirely from Brent’s school of thought. Neither of the identified “schools of thought in the PHP world” value Eevee’s tenets at all, aside from P++ seeing concision by seeking to remove some “baggage”. However, rather than trying to improve linguistic clarity, the P++ author seeks only to remove unused language features in order to ease development and maintenance of the PHP core toolchain. In other words, this is actually a play for Brent’s desire for active core development, new features, and tooling.
A cousin comment points out that this proposal is somewhat analogous to
use strict;directives in other languages. In those situations, namely Perl 5 and JS, strict dialects were an attempt to cut down on hard-to-compile, hard-to-analyze, hard-to-read, complicated, or underused language features. It’s easy to interpret P++ as seeking to reach an analogous house-cleaning.I’m not yet being overly negative.
They aren’t saying so, but it basically sounds the same as
use strictfrom JavaScript and Perl. It specifically allows a single codebase to contain both PHP and “P++” code, unlike Python 3, and as a result allows you to incrementally migrate.My biggest annoyance at PHP, unfortunately, is the way arrays work. And since arrays end up being part of library APIs, it’s impossible to maintain backwards compatibility while fixing it.
An incremental migration that will never be complete, so you have to drag along all that previous behaviour as well which might over time bit-rot as its usage drops to a low but non-negligible amount.
Sounds a little like the Rust “Editions” concept. I see that popping up a lot? Probably, because we have shown that it can be made work?
Not that I want to pat ourselves on the back, it’s just that I think it’s interesting to see how concepts travel. I think it would make sense to at some point make an honest writeup about what worked, what didn’t with edition 2018. (in general: it worked as intended, but there’s some stuff)