1. PHP's "programmer workflow" is unmatched. The development model is: "modify code, reload page." That's it. Simple and effective-- nearly optimal in fact for rapid development of code.
2. Program State: all PHP programs start as a web request with an empty heap and empty namespace. Cross-request state must always be saved explicitly and this tends to reduce bugs considerably at the cost of 10ms or so additional processing time for each request.
3. Concurrency model that relies on the request/server architecture rather than a specific language feature. PHP's strict enforcement of one thread per program per request forces you to use this model. The downside is that it's not applicable outside of the web server environment. Which, he argues, is fine since you want a tool optimized for the job you're trying to do.
Also:
0. He reviewed a number of PHP weaknesses, accepted that they are legitimate flaws in the language, and that if you had a PHP do-over there's no good reason to make all those mistakes again. But, he'll accept these flaws to benefit from the strengths listed above. He also shared the observation that a wide variety of programmers seem capable of becoming productive in PHP rather quickly, even if they've never used it before.
4. He reviewed tool they are developing, called Hack, to add better typing capability to PHP.
Interestingly, that's pretty much how I feel about writing Python web apps in Flask.
The built in reloading webserver gives (1.), the flask docs are fairly explicit about global/request state, how to share it, etc, giving near as anything (2.), the concurrency is handled by whatever server you use, be it gunicorn, waitress, uwsgi, or whatever, thanks to the wsgi protocol of python, giving (3.).
There's the auto-reloading build in web server, which will crash on any syntax errors in any changed code, so I don't even have to explore every possible path to find them.
Some other big deals, to me in python are the fact that requests, and input/output are all extremely separated. You never get the white-page-of-death-with-no-explanation of PHP. You never get random plugins printing something, and screwing up the headers. You never get issues with forgetting to use the appropriate number of op_cache function calls to keep slightly-less-trusted code under control.
Also, keeping templates, libraries, static files, and caches totally separate always seems like a good idea to me, but PHP doesn't encourage that. I know it's possible, but so many major projects (wordpress, joomla, drupal, etc) don't enforce that, making permissions in deployment a nightmare.
PHP's "reload page" methodology is extremely biased towards producing web pages and is a massive liability in other domains.
This is probably the biggest problem with PHP as it stands. It's so dead-focused on producing web pages that it's super awkward to use outside of that context.
Comments
The speaker makes the following case:
1. PHP's "programmer workflow" is unmatched. The development model is: "modify code, reload page." That's it. Simple and effective-- nearly optimal in fact for rapid development of code.
2. Program State: all PHP programs start as a web request with an empty heap and empty namespace. Cross-request state must always be saved explicitly and this tends to reduce bugs considerably at the cost of 10ms or so additional processing time for each request.
3. Concurrency model that relies on the request/server architecture rather than a specific language feature. PHP's strict enforcement of one thread per program per request forces you to use this model. The downside is that it's not applicable outside of the web server environment. Which, he argues, is fine since you want a tool optimized for the job you're trying to do.
Also:
0. He reviewed a number of PHP weaknesses, accepted that they are legitimate flaws in the language, and that if you had a PHP do-over there's no good reason to make all those mistakes again. But, he'll accept these flaws to benefit from the strengths listed above. He also shared the observation that a wide variety of programmers seem capable of becoming productive in PHP rather quickly, even if they've never used it before.
4. He reviewed tool they are developing, called Hack, to add better typing capability to PHP.
Interestingly, that's pretty much how I feel about writing Python web apps in Flask.
The built in reloading webserver gives (1.), the flask docs are fairly explicit about global/request state, how to share it, etc, giving near as anything (2.), the concurrency is handled by whatever server you use, be it gunicorn, waitress, uwsgi, or whatever, thanks to the wsgi protocol of python, giving (3.).
There's the auto-reloading build in web server, which will crash on any syntax errors in any changed code, so I don't even have to explore every possible path to find them.
Some other big deals, to me in python are the fact that requests, and input/output are all extremely separated. You never get the white-page-of-death-with-no-explanation of PHP. You never get random plugins printing something, and screwing up the headers. You never get issues with forgetting to use the appropriate number of op_cache function calls to keep slightly-less-trusted code under control.
Also, keeping templates, libraries, static files, and caches totally separate always seems like a good idea to me, but PHP doesn't encourage that. I know it's possible, but so many major projects (wordpress, joomla, drupal, etc) don't enforce that, making permissions in deployment a nightmare.
PHP's "reload page" methodology is extremely biased towards producing web pages and is a massive liability in other domains.
This is probably the biggest problem with PHP as it stands. It's so dead-focused on producing web pages that it's super awkward to use outside of that context.