4 ms·

There is so much to dislike about PHP that the only thing I can say nice about PHP is that it's the easiest way to just deploy to any server ever. Beyond that,

There is so much to dislike about PHP that the only thing I can say nice about PHP is that it's the easiest way to just deploy to any server ever. Beyond that, I don't think I would look to PHP to do anything ever if I had a choice of project language.

shuzchen 13y ago
As someone that has had to mess with deploying large PHP project in a previous life, I'd have to disagree. Using mod_php? Better fix your file permissions. Use any non-trivial language feature? - better make sure you have the right minor version installed. Use functions from the supposed standard library (e.g., anything from gd_*, xml, process control, cryptography modules)? - better pray PHP was compiled with those enabled. Use routing in your PHP app (and you're crazy if you don't)? - better pray apache is configured to accept your .htaccess, or port the mod_rewrite rules for the non-apache server you're on. And then all of this while futzing with the 3 different php.ini files scattered around the filesystem. Between virtualenv and pip, deploying python has been loads easier, as is getting team members up and running with a dev server.
- stephenr 13y ago
  Out of the box php generally works, which is often touted as a benefit. Personally i think if you can afford a server you can afford 20 minutes time for someone who knows what they're doing. Every one of your examples tells me that you chose not to invest in those 20 minutes. Here's a hint: there is a reason "developer" and "administrator" are usually different roles.
  - shuzchen 13y ago
    Out of the box php generally works so long as you have trivial php code (that doesn't take advantage of new language features, doesn't need routing, doesn't need to write to the filesystem, and doesn't common library modules). Needless to say, that generally rules out any serious project out there. I'm not saying I chose not to invest in those 20 minutes, I'm saying there's nothing about PHP that makes it inherently easier than other things to deploy real projects. You still have to deal with version incompatibilities, you still have to deal with configuration, you still have to deal with differing resources. That applies to all stacks.

shuzchen 13y ago

As someone that has had to mess with deploying large PHP project in a previous life, I'd have to disagree. Using mod_php? Better fix your file permissions. Use any non-trivial language feature? - better make sure you have the right minor version installed. Use functions from the supposed standard library (e.g., anything from gd_*, xml, process control, cryptography modules)? - better pray PHP was compiled with those enabled. Use routing in your PHP app (and you're crazy if you don't)? - better pray apache is configured to accept your .htaccess, or port the mod_rewrite rules for the non-apache server you're on. And then all of this while futzing with the 3 different php.ini files scattered around the filesystem. Between virtualenv and pip, deploying python has been loads easier, as is getting team members up and running with a dev server.

stephenr 13y ago
Out of the box php generally works, which is often touted as a benefit. Personally i think if you can afford a server you can afford 20 minutes time for someone who knows what they're doing. Every one of your examples tells me that you chose not to invest in those 20 minutes. Here's a hint: there is a reason "developer" and "administrator" are usually different roles.
- shuzchen 13y ago
  Out of the box php generally works so long as you have trivial php code (that doesn't take advantage of new language features, doesn't need routing, doesn't need to write to the filesystem, and doesn't common library modules). Needless to say, that generally rules out any serious project out there. I'm not saying I chose not to invest in those 20 minutes, I'm saying there's nothing about PHP that makes it inherently easier than other things to deploy real projects. You still have to deal with version incompatibilities, you still have to deal with configuration, you still have to deal with differing resources. That applies to all stacks.