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.
There are many things that are popular or successful that nevertheless I cannot take seriously. Cheech and Chong for example.
"Taking it seriously" implies something more than just recognizing that it exists and is prevalent. In fact, I would go so far as to say that if you are forced to work in PHP, you should never take it seriously for your own safety and sanity. Always assume it will be and act janky, so that it cannot catch you off guard.
Modern PHP with a proper framework isn't really that bad, from a development point of view. You certainly don't have to deal in spaghetti code if you don't have to.
No comment on whether that's due to modern PHP frameworks splitting the difference between pretending to be Ruby or pretending to be Java, though. Of the major server-side languages it seems to be the most adapted to its purpose - churning out web resources with as little effort as possible.
Of course not. It only runs a paltry ~80% of the web. Just ignore it. Maybe it'll go away.
One of the nicest things about Kieth's talk is that he specifically did not make the case that network effect is a reason to take PHP seriously. He mentioned it as a data point that should pique curiosity, and proceeded to discuss concrete strengths at length instead.
I also find it funny that people who hate on PHP used to hate on JavaScript for many of the same reasons and they now have an unhealthy, public love affair with it. That and people who tried jamming WordPress or some CMS into every use-case 10 years ago are commenting on how they don't like PHP. IMO, PHP has kept it's charm but added a lot of good stuff from other languages like Java. PHP is the language of choice and getting shit done. Oh, and not having to worry about lack of work.
I also find it funny that people who hate on PHP used to hate on JavaScript for many of the same reasons and they now have an unhealthy, public love affair with it.
Javascript used to be clunky due to cross-browser issues. These are mostly resolved now (at the language level).
PHP, on the other hand, has always been clunky. For example, it's often said that parsing is a solved problem. Try telling that to PHP:
$y = new stdClass;
$y->foo = function() { echo "World"; };
$y->foo(); // "No such method 'foo'"??!
I've written quite a few parsers, but still have no idea how PHP's could end up like this. Here are some recent 'features' from PHP 5.4 and 5.5 which every other parser on the planet would have handled from day 1:
- Passing an arbitrary expression instead of a variable to empty() is now supported. (PHP 5.5)
- Function array dereferencing has been added, e.g. foo()[0]. (PHP 5.4)
- Class member access on instantiation has been added, e.g. (new Foo)->bar(). (PHP 5.4)
I've written quite a few parsers, but still have no idea how PHP's could end up like this.
Have you ever tried to parse code with a set of context sensitive rules (like, not using yacc, but writting your parser case by case at hand) and context free regular expression (don't use look ahead at all, and you also can't look behind)? PHP errors look a lot like this.
I also find it funny that people who hate on PHP used to hate on JavaScript for many of the same reasons and they now have an unhealthy, public love affair with it.
I think JQuery and Coffeescript, have gone a long way to mollify people's opinions about javascript in a similar way to frameworks in PHP. And compared to PHP, some of javascript's syntax (particularly arrays, objects and anonymous functions) are a lot easier to deal with than in PHP, so there's some appreciation of that in the Node community, no doubt. But yeah, it does seem as if PHP and javascript are sort of the black sheep of the web app world.
Well, kind of. Apparently ~20% of the web is wordpress, ~3% use Joomla, ~2% Drupal, and many other PHP CMS's after that.
So, yes, they are running PHP, but most of the PHP usage is simply running 'standard' software, and if you're not developing within those, (either core, or plugins), then it's a much smaller percent of sites which actually are custom written by programmers which actually run PHP.
So, I guess my point is, that even if a lot of the web is 'running' PHP, how much future development actually will use it? And as 'hackers', people writing new, cutting edge, different websites & apps, does PHP have anything to offer really, beyond easy to set up blogging and CMS systems for non-programmer clients?
As far as I understand it, PHP is used at FB only really because that's what it was originally written in. If Mark Z. had chosen Ruby, would FB now be working on ruby compilers and so on?
Perhaps, but aren't the bulk of today's non-PHP sites running on the standard frameworks for those languages? How many 'hackers' write Android apps without spending the bulk of their time in Eclipse, working with other people's code? There aren't a lot of pgs out there deciding to reinvent every wheel on the train.
I don't think you can necessarily dismiss the impact of 'blogging and CMS' systems when judging the future of a web application language. They may not be sexy, but almost everything everybody wants to do amounts to a CRUD app turning database records into html, and you can do that in any language.
I wouldn't recommend PHP for general purpose scripting though. Right now I like python for that.
I just said that I do take them seriously! What I mean is that their system and the logic embodied within the tax code has about the same amount of sensibility as PHP.
Comments
Is such a thing even possible?
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.
Of course not. It only runs a paltry ~80% of the web. Just ignore it. Maybe it'll go away.
There are many things that are popular or successful that nevertheless I cannot take seriously. Cheech and Chong for example.
"Taking it seriously" implies something more than just recognizing that it exists and is prevalent. In fact, I would go so far as to say that if you are forced to work in PHP, you should never take it seriously for your own safety and sanity. Always assume it will be and act janky, so that it cannot catch you off guard.
Modern PHP with a proper framework isn't really that bad, from a development point of view. You certainly don't have to deal in spaghetti code if you don't have to.
No comment on whether that's due to modern PHP frameworks splitting the difference between pretending to be Ruby or pretending to be Java, though. Of the major server-side languages it seems to be the most adapted to its purpose - churning out web resources with as little effort as possible.
Of course not. It only runs a paltry ~80% of the web. Just ignore it. Maybe it'll go away.
One of the nicest things about Kieth's talk is that he specifically did not make the case that network effect is a reason to take PHP seriously. He mentioned it as a data point that should pique curiosity, and proceeded to discuss concrete strengths at length instead.
I also find it funny that people who hate on PHP used to hate on JavaScript for many of the same reasons and they now have an unhealthy, public love affair with it. That and people who tried jamming WordPress or some CMS into every use-case 10 years ago are commenting on how they don't like PHP. IMO, PHP has kept it's charm but added a lot of good stuff from other languages like Java. PHP is the language of choice and getting shit done. Oh, and not having to worry about lack of work.
Javascript used to be clunky due to cross-browser issues. These are mostly resolved now (at the language level).
PHP, on the other hand, has always been clunky. For example, it's often said that parsing is a solved problem. Try telling that to PHP:
$x = function() { return function() { echo "Hello"; }; }; $x()(); // Syntax error??!
$y = new stdClass; $y->foo = function() { echo "World"; }; $y->foo(); // "No such method 'foo'"??!
I've written quite a few parsers, but still have no idea how PHP's could end up like this. Here are some recent 'features' from PHP 5.4 and 5.5 which every other parser on the planet would have handled from day 1: - Passing an arbitrary expression instead of a variable to empty() is now supported. (PHP 5.5) - Function array dereferencing has been added, e.g. foo()[0]. (PHP 5.4) - Class member access on instantiation has been added, e.g. (new Foo)->bar(). (PHP 5.4)
Have you ever tried to parse code with a set of context sensitive rules (like, not using yacc, but writting your parser case by case at hand) and context free regular expression (don't use look ahead at all, and you also can't look behind)? PHP errors look a lot like this.
I think JQuery and Coffeescript, have gone a long way to mollify people's opinions about javascript in a similar way to frameworks in PHP. And compared to PHP, some of javascript's syntax (particularly arrays, objects and anonymous functions) are a lot easier to deal with than in PHP, so there's some appreciation of that in the Node community, no doubt. But yeah, it does seem as if PHP and javascript are sort of the black sheep of the web app world.
Well, kind of. Apparently ~20% of the web is wordpress, ~3% use Joomla, ~2% Drupal, and many other PHP CMS's after that.
So, yes, they are running PHP, but most of the PHP usage is simply running 'standard' software, and if you're not developing within those, (either core, or plugins), then it's a much smaller percent of sites which actually are custom written by programmers which actually run PHP.
So, I guess my point is, that even if a lot of the web is 'running' PHP, how much future development actually will use it? And as 'hackers', people writing new, cutting edge, different websites & apps, does PHP have anything to offer really, beyond easy to set up blogging and CMS systems for non-programmer clients?
As far as I understand it, PHP is used at FB only really because that's what it was originally written in. If Mark Z. had chosen Ruby, would FB now be working on ruby compilers and so on?
Perhaps, but aren't the bulk of today's non-PHP sites running on the standard frameworks for those languages? How many 'hackers' write Android apps without spending the bulk of their time in Eclipse, working with other people's code? There aren't a lot of pgs out there deciding to reinvent every wheel on the train.
I don't think you can necessarily dismiss the impact of 'blogging and CMS' systems when judging the future of a web application language. They may not be sexy, but almost everything everybody wants to do amounts to a CRUD app turning database records into html, and you can do that in any language.
I wouldn't recommend PHP for general purpose scripting though. Right now I like python for that.
I take it seriously in the same way I have conceded to take Windows and the IRS seriously.
You may want to take the IRS seriously...
I just said that I do take them seriously! What I mean is that their system and the logic embodied within the tax code has about the same amount of sensibility as PHP.
Watch the talk to find out.