4 ms·

Why PHP? I would argue that in this day and age, that is a bad decision. There are simply better, lighter weight languages to use that will get you going faster

Why PHP? I would argue that in this day and age, that is a bad decision. There are simply better, lighter weight languages to use that will get you going faster and cause less problems down the road. Maybe not you personally if you're a PHP wizard, but certainly the industry in average. I'd recommend you skate to where the puck is going. :)

arasmussen 12y ago
If you downvoted, feel free to share your opinion on why this is wrong. I could care less about the votes, I want to hear your discussion! Why would you use PHP? Here's an excerpt from a Facebook engineer explaining why we still use PHP: "The reason Facebook hasn't migrated away from PHP is because it has incumbent inertia (it's what's there) and Facebook's engineers have managed to work around many of its flaws through a combination of patches at all levels of the stack and excellent internal discipline via code convention and style - the worst attributes of the language are avoided and coding style is rigidly enforced through a fairly tight culture of code review"
- federico3 12y ago
  Vulnerabilities in the vm only, not including libraries and frameworks: http://www.cvedetails.com/vendor/74/PHP.html http://www.cvedetails.com/vendor/74/PHP.html Feel free to compare it with other languages.
  - tene 12y ago
    I'm curious what happened in 2007; why were there so many more vulnerabilities, especially code execution?
- eropple 12y ago
  I'm not a habitual PHP user, and I have perturbed many electrons on why I wouldn't use it for nontrivial projects, but I could slam out something for which I don't care about security or performance in a very short period of time. Rails, Play, etc. have some friction; Sinatra makes you reinvent a lot of wheels. You really can just fart something out in PHP very rapidly.
  - marco1 12y ago
    It's important to state that I do care about security here, but I don't care about performance that much.
- swalkergibson 12y ago
  You answered the question yourself. If someone is a wizard in PHP, then they should use PHP. People that get caught up in the decision of what language to use don't ship code. Shipped code > language decision circle jerks.
  - SuperKlaus 12y ago
    Exactly! Done > Perfect
- sarciszewski 12y ago
  Funny, I've fixed a flaw in the Facebook SDK already, so they aren't that imprevious to making the same mistake :P
- opendais 12y ago
  I downvoted because you make grandiose claims without any real, non-FUD sources beyond you work at Facebook. You just say there are "BETTER THINGS!!!" without listing at least one and why. 1) From a productivity standpoint PHP is pretty hard to beat in general....if you already know PHP. 2) A poor craftsman blames the tool. 3) PHP's inertia extends to the entire ecosystem really, not just the tool.
marco1 12y ago
I don't think this is a bad decision, but I'm sure that it's not the optimal solution, either. I chose PHP just for the sake of rapid prototyping. I actually planned to rewrite the complete server-side code in Node.js or Go, but haven't managed to do so yet.
sarciszewski 12y ago
PHP isn't inherently a bad decision. The ecosystem is full of good examples of what not to do, but that's not a failing of the language itself. It can be done right. Yes, there are design warts. There are also RFCs to iron them out. (I opened one recently to deprecate MCRYPT_RAND so people can stop generating weak random IVs in their crypto libraries one day). Personally, I spend a lot of my free time opening issues and submitting pull requests to PHP projects on github to increase the likelihood of a budding developer being exposed to better code.
- marco1 12y ago
  Agree. And for PHP, there are also quite promising things that you can expect, e.g. HHVM, Hack, etc. But also in PHP itself, e.g. https://news.ycombinator.com/item?id=8036707 https://news.ycombinator.com/item?id=8036707
domiono 12y ago
This with parse would have been awesome. Super easy, out of the box and pretty much platform agnostic.
- marco1 12y ago
  You mean that the backend should have been based on parse.com and not be written in PHP? Well, there are several reasons I didn't do this: (a) I wasn't familiar with parse.com (b) PHP code is independent from a single commercial provider (c) you can easily host the PHP code on Heroku etc. (d) I wasn't really sure if parse.com was appropriate for more complex tasks, encryption, etc.

arasmussen 12y ago

If you downvoted, feel free to share your opinion on why this is wrong. I could care less about the votes, I want to hear your discussion! Why would you use PHP? Here's an excerpt from a Facebook engineer explaining why we still use PHP: "The reason Facebook hasn't migrated away from PHP is because it has incumbent inertia (it's what's there) and Facebook's engineers have managed to work around many of its flaws through a combination of patches at all levels of the stack and excellent internal discipline via code convention and style - the worst attributes of the language are avoided and coding style is rigidly enforced through a fairly tight culture of code review"

federico3 12y ago
Vulnerabilities in the vm only, not including libraries and frameworks: http://www.cvedetails.com/vendor/74/PHP.html http://www.cvedetails.com/vendor/74/PHP.html Feel free to compare it with other languages.
- tene 12y ago
  I'm curious what happened in 2007; why were there so many more vulnerabilities, especially code execution?
eropple 12y ago
I'm not a habitual PHP user, and I have perturbed many electrons on why I wouldn't use it for nontrivial projects, but I could slam out something for which I don't care about security or performance in a very short period of time. Rails, Play, etc. have some friction; Sinatra makes you reinvent a lot of wheels. You really can just fart something out in PHP very rapidly.
- marco1 12y ago
  It's important to state that I do care about security here, but I don't care about performance that much.
swalkergibson 12y ago
You answered the question yourself. If someone is a wizard in PHP, then they should use PHP. People that get caught up in the decision of what language to use don't ship code. Shipped code > language decision circle jerks.
- SuperKlaus 12y ago
  Exactly! Done > Perfect
sarciszewski 12y ago
Funny, I've fixed a flaw in the Facebook SDK already, so they aren't that imprevious to making the same mistake :P
opendais 12y ago
I downvoted because you make grandiose claims without any real, non-FUD sources beyond you work at Facebook. You just say there are "BETTER THINGS!!!" without listing at least one and why. 1) From a productivity standpoint PHP is pretty hard to beat in general....if you already know PHP. 2) A poor craftsman blames the tool. 3) PHP's inertia extends to the entire ecosystem really, not just the tool.

marco1 12y ago

I don't think this is a bad decision, but I'm sure that it's not the optimal solution, either. I chose PHP just for the sake of rapid prototyping. I actually planned to rewrite the complete server-side code in Node.js or Go, but haven't managed to do so yet.

sarciszewski 12y ago

PHP isn't inherently a bad decision. The ecosystem is full of good examples of what not to do, but that's not a failing of the language itself. It can be done right. Yes, there are design warts. There are also RFCs to iron them out. (I opened one recently to deprecate MCRYPT_RAND so people can stop generating weak random IVs in their crypto libraries one day). Personally, I spend a lot of my free time opening issues and submitting pull requests to PHP projects on github to increase the likelihood of a budding developer being exposed to better code.

marco1 12y ago
Agree. And for PHP, there are also quite promising things that you can expect, e.g. HHVM, Hack, etc. But also in PHP itself, e.g. https://news.ycombinator.com/item?id=8036707 https://news.ycombinator.com/item?id=8036707

domiono 12y ago

This with parse would have been awesome. Super easy, out of the box and pretty much platform agnostic.

marco1 12y ago
You mean that the backend should have been based on parse.com and not be written in PHP? Well, there are several reasons I didn't do this: (a) I wasn't familiar with parse.com (b) PHP code is independent from a single commercial provider (c) you can easily host the PHP code on Heroku etc. (d) I wasn't really sure if parse.com was appropriate for more complex tasks, encryption, etc.