Reasons to use PHP(eschrade.com)
eschrade.com
Reasons to use PHP
http://www.eschrade.com/page/10-reasons-to-use-php-for-your-mobile-project/
21 comments
And this is why you should learn your abstractions, kids!
1. The same is true of share-nothing architectures in Ruby, Python, Perl, Java, or C# (including Rails and Django). All you have to do is get more app servers - no fuss. Of course, the hard thing is scaling the data store which is something PHP (or other language) users will still face.
2. I don't think PHP is any easier than Python or Ruby - in fact, in many ways I consider it more difficult personally. There may be a higher number of people that advertise PHP skills, but many of them are people that can cut and paste and keep futzing until something mostly works in WordPress. That's not really the kind of programmer you want (at any price).
3. PHP has some nice built-ins for the web - including session/cookie handling, the $_GET and $_POST hashes, etc. However, when I use Python, Ruby, or Java, I get these things via a framework (even a microframework). Yes, one of PHP's strengths is that it includes a microframework that handles basic routing, session handling, and request information. However, all of that is available in other languages.
4. Whether it's Django, Rails, or another framework, I find that an error in one request doesn't propagate to the next. It's interesting how the author hedges and says, "well, when it does get borked, it's your fault rather than PHP's". So, PHP never fails for more than one request, unless it does in which case it's your fault. That's hard to argue against since it doesn't mean anything.
5. None of PHP's frameworks seem as mature as those available in Python, Ruby, C#, and Java and I think part of it is due to the fact that PHP is by itself a microframework.
6. PHP.net does have great docs and they're all nicely in a prominent location. However, one really needs better docs to compensate for poor design. For example, when dealing with PHP strings, do you put the needle or the haystack first? The answer is that it depends on the function. preg_match is needle first, strstr is haystack first. That brings up another inconsistency: should words be separated by an underscore? The answer is again that it depends. Every language has its warts, but PHP is known for being inconsistent.
7. PHP does have a bunch written about it, but it also has a lot of noise. There's a lot written by people who don't quite know what they're doing, but were able to cut and paste code and futz until it worked.
8. The same could be said of almost any community. It's easy to say that there's always people to help since it can't be quantified or argued against.
9. PHP does have good support for many things, but it lacks a modules system. Python has PyPI, Ruby has RubyGems, Java has Maven, and Perl has CPAN. PHP does support a lot of things, but you've provided no evidence that it supports more things than any other language (MongoDB, Pusher, and memcached are supported in many languages and those are the only things you used as examples).
10. Many languages are dynamically typed, but PHP is also weakly typed. Sometimes this is fine, but it can also be a pain and introduce subtle bugs from implicit type casting.
11. I think that many of us have chosen other languages because we believe we get things done faster in them. Writing an application isn't just getting the proof of concept out the door. It's about long-term productivity.
If you like PHP, great for you! I hope you're productive and enjoy using it. However, none of these reasons really ring as valid. PHP is not more scalable. PHP includes a microframework that you don't have to choose beyond the language, but that's not really something that interesting given that frameworks exist for most languages. Via a library, most languages have as good support for the web as PHP has - sometimes better (in my opinion). And the idea that PHP's popularity on the low end makes it an attractive option just seems like a bad argument.
Finally, the author says that PHP is where it's at for the web for the next 5 years (at least). However, what is launching around now and using PHP? Instagram was Python (Django). Quora wasn't PHP. FriendFeed was Python and Facebook seems to have moved away from PHP except for its legacy front-end. Google, Microsoft, and Apple don't use PHP. Pinterest is Python and Django. Twitter is a mix of Ruby and Scala. Github is Rails, BitBucket is Django. Groupon is Rails. Again, just because someone else is doing something isn't a reason to do it. However, if the author is arguing that PHP is the language of the next 5 years, I'd argue that it isn't the language of today.
When Facebook launched, Rails and Django didn't exist; .NET MVC didn't exist; Play! didn't exist. In some ways, Facebook seems to be the last big pre-Rails site. That doesn't mean that newer sites always use frameworks (or that some frameworks didn't exist before then). However, new and popular frameworks burst onto the scene in 2004 and 2005. It changed our web development community. Since that time, I think we've seen new projects using other languages a lot more than PHP. Again, I can't emphasize enough that just because someone is doing something doesn't make it good for you. However, if the author is going to claim that PHP is the language of the day, I'm going to refute it. That doesn't mean that you can't build good things with PHP, but I think that a lot of us are using other tools.
2. I don't think PHP is any easier than Python or Ruby - in fact, in many ways I consider it more difficult personally. There may be a higher number of people that advertise PHP skills, but many of them are people that can cut and paste and keep futzing until something mostly works in WordPress. That's not really the kind of programmer you want (at any price).
3. PHP has some nice built-ins for the web - including session/cookie handling, the $_GET and $_POST hashes, etc. However, when I use Python, Ruby, or Java, I get these things via a framework (even a microframework). Yes, one of PHP's strengths is that it includes a microframework that handles basic routing, session handling, and request information. However, all of that is available in other languages.
4. Whether it's Django, Rails, or another framework, I find that an error in one request doesn't propagate to the next. It's interesting how the author hedges and says, "well, when it does get borked, it's your fault rather than PHP's". So, PHP never fails for more than one request, unless it does in which case it's your fault. That's hard to argue against since it doesn't mean anything.
5. None of PHP's frameworks seem as mature as those available in Python, Ruby, C#, and Java and I think part of it is due to the fact that PHP is by itself a microframework.
6. PHP.net does have great docs and they're all nicely in a prominent location. However, one really needs better docs to compensate for poor design. For example, when dealing with PHP strings, do you put the needle or the haystack first? The answer is that it depends on the function. preg_match is needle first, strstr is haystack first. That brings up another inconsistency: should words be separated by an underscore? The answer is again that it depends. Every language has its warts, but PHP is known for being inconsistent.
7. PHP does have a bunch written about it, but it also has a lot of noise. There's a lot written by people who don't quite know what they're doing, but were able to cut and paste code and futz until it worked.
8. The same could be said of almost any community. It's easy to say that there's always people to help since it can't be quantified or argued against.
9. PHP does have good support for many things, but it lacks a modules system. Python has PyPI, Ruby has RubyGems, Java has Maven, and Perl has CPAN. PHP does support a lot of things, but you've provided no evidence that it supports more things than any other language (MongoDB, Pusher, and memcached are supported in many languages and those are the only things you used as examples).
10. Many languages are dynamically typed, but PHP is also weakly typed. Sometimes this is fine, but it can also be a pain and introduce subtle bugs from implicit type casting.
11. I think that many of us have chosen other languages because we believe we get things done faster in them. Writing an application isn't just getting the proof of concept out the door. It's about long-term productivity.
If you like PHP, great for you! I hope you're productive and enjoy using it. However, none of these reasons really ring as valid. PHP is not more scalable. PHP includes a microframework that you don't have to choose beyond the language, but that's not really something that interesting given that frameworks exist for most languages. Via a library, most languages have as good support for the web as PHP has - sometimes better (in my opinion). And the idea that PHP's popularity on the low end makes it an attractive option just seems like a bad argument.
Finally, the author says that PHP is where it's at for the web for the next 5 years (at least). However, what is launching around now and using PHP? Instagram was Python (Django). Quora wasn't PHP. FriendFeed was Python and Facebook seems to have moved away from PHP except for its legacy front-end. Google, Microsoft, and Apple don't use PHP. Pinterest is Python and Django. Twitter is a mix of Ruby and Scala. Github is Rails, BitBucket is Django. Groupon is Rails. Again, just because someone else is doing something isn't a reason to do it. However, if the author is arguing that PHP is the language of the next 5 years, I'd argue that it isn't the language of today.
When Facebook launched, Rails and Django didn't exist; .NET MVC didn't exist; Play! didn't exist. In some ways, Facebook seems to be the last big pre-Rails site. That doesn't mean that newer sites always use frameworks (or that some frameworks didn't exist before then). However, new and popular frameworks burst onto the scene in 2004 and 2005. It changed our web development community. Since that time, I think we've seen new projects using other languages a lot more than PHP. Again, I can't emphasize enough that just because someone is doing something doesn't make it good for you. However, if the author is going to claim that PHP is the language of the day, I'm going to refute it. That doesn't mean that you can't build good things with PHP, but I think that a lot of us are using other tools.
1. Until you hit facebook levels and have to write your own interpreter.
2. Sure, but your code will also suck and be hard to maintain.
3. Nonsense. You might as well say that everyone should use C because it was the first language with a TCP socket API.
4. Nonsense. You can fuck up royally in any language.
5. Irrelevant. The only framework that matters is the one you end up using. Pick a good one and stick with it.
6. For some valuation of "best". Other popular web frameworks and languages also have very good documentation. I'll give PHP the benefit of the doubt on this one, since I don't really know.
7. Again, lots of blogs for other languages too. Also, many PHP blogs are full of shit code (as are many other blogs). Generally, you know what you're doing or you don't. Unless you're reading a type theory blog, you're not going to magically become a good programmer by reading blogs.
8. No experience with PHP's community, but again, lots of other languages have good communities.
9. Lots of other languages integrate with everything too. These last four bullet points aren't really "PHP is good" but just "popular languages have lots of libraries", i.e. tautologies.
10. Heh.
11. So does everything else. Not a strong point in PHP's favor.
Color me unconvinced.
2. Sure, but your code will also suck and be hard to maintain.
3. Nonsense. You might as well say that everyone should use C because it was the first language with a TCP socket API.
4. Nonsense. You can fuck up royally in any language.
5. Irrelevant. The only framework that matters is the one you end up using. Pick a good one and stick with it.
6. For some valuation of "best". Other popular web frameworks and languages also have very good documentation. I'll give PHP the benefit of the doubt on this one, since I don't really know.
7. Again, lots of blogs for other languages too. Also, many PHP blogs are full of shit code (as are many other blogs). Generally, you know what you're doing or you don't. Unless you're reading a type theory blog, you're not going to magically become a good programmer by reading blogs.
8. No experience with PHP's community, but again, lots of other languages have good communities.
9. Lots of other languages integrate with everything too. These last four bullet points aren't really "PHP is good" but just "popular languages have lots of libraries", i.e. tautologies.
10. Heh.
11. So does everything else. Not a strong point in PHP's favor.
Color me unconvinced.
For performance, not even Facebook levels. If you're having "scaling" issues that benefit from fast executing code (as opposed to a massive dataset management issue), PHP isn't really that fast at all. So why would you want to throw away CPU cycles when there are expressive languages that have a fast compiled representation, too?
I value dev productivity over performance in most cases, but it's silly to try to make a performance argument for PHP.
I value dev productivity over performance in most cases, but it's silly to try to make a performance argument for PHP.
Couldn't the same be said of any interpreted language.
> 1. Until you hit facebook levels and have to write your own interpreter.
Facebook levels of load would be a great problem to have. Until then, who cares?
> 2. Sure, but your code will also suck and be hard to maintain.
Doubtful, but this isn't even a good point. Working software is the important deliverable.
> 3. Nonsense. You might as well say that everyone should use C because it was the first language with a TCP socket API.
You missed the point. Writing a web app with a language that's basically tied to the web makes sense. It's not the most important point, but it isn't 'nonsense'.
> 4. Nonsense. You can fuck up royally in any language.
He said as much in that point. Did you bother reading and thinking about the article, or just trip over your own drool racing to the comments section? I'm just going to stop here.
Color me unimpressed.
Facebook levels of load would be a great problem to have. Until then, who cares?
> 2. Sure, but your code will also suck and be hard to maintain.
Doubtful, but this isn't even a good point. Working software is the important deliverable.
> 3. Nonsense. You might as well say that everyone should use C because it was the first language with a TCP socket API.
You missed the point. Writing a web app with a language that's basically tied to the web makes sense. It's not the most important point, but it isn't 'nonsense'.
> 4. Nonsense. You can fuck up royally in any language.
He said as much in that point. Did you bother reading and thinking about the article, or just trip over your own drool racing to the comments section? I'm just going to stop here.
Color me unimpressed.
How can you argue that both "tied to the web" and "frameworks" are benefits, yet keep a straight face?
Frameworks in any language plug the language into the web—that's what they exist to do.
And if you're using the parts of PHP that are tied to the web, then you must not be using a framework, or those would surely be wrapped.
...but those parts of PHP must suck, or you wouldn't need to use a framework!
So then... PHP is good because it solves the problems it causes? I don't get it.
Frameworks in any language plug the language into the web—that's what they exist to do.
And if you're using the parts of PHP that are tied to the web, then you must not be using a framework, or those would surely be wrapped.
...but those parts of PHP must suck, or you wouldn't need to use a framework!
So then... PHP is good because it solves the problems it causes? I don't get it.
> Facebook levels of load would be a great problem to have. Until then, who cares?
It shows up a lot faster than at Facebook levels of load. Because php throws everything out at the end of every request, you're going to need to buy a lot more servers a lot more often if your app does take off. Or you end up paying zend lots of money for things like caching that are built into nearly every other language.
> Doubtful, but this isn't even a good point. Working software is the important deliverable.
Until you're stymied next year because your current codebase is falling apart.
> You missed the point. Writing a web app with a language that's basically tied to the web makes sense. It's not the most important point, but it isn't 'nonsense'.
I'd much rather have a language isn't tied to any particular ideology. Yes, your clients are web-based at the moment, but your database isn't web-based, your mail server isn't web-based, etc. Driving everything by your presentation layer is a terrible, superficial way of looking at problems.
> He said as much in that point. Did you bother reading and thinking about the article, or just trip over your own drool racing to the comments section? I'm just going to stop here.
The original blog author posted this with an air of php exceptionalism. Other languages equally have no problem handling the issues that this author claims exist.
This blog post, and your response, is a classic example of the php hammer syndrome. Yes, it kind of works, and seems neat at a superficial level, but once you start to use it, you start seeing all of the glaring flaws in the actual delivery of the product. Workarounds become dogma, and everyone suffers as a result.
It shows up a lot faster than at Facebook levels of load. Because php throws everything out at the end of every request, you're going to need to buy a lot more servers a lot more often if your app does take off. Or you end up paying zend lots of money for things like caching that are built into nearly every other language.
> Doubtful, but this isn't even a good point. Working software is the important deliverable.
Until you're stymied next year because your current codebase is falling apart.
> You missed the point. Writing a web app with a language that's basically tied to the web makes sense. It's not the most important point, but it isn't 'nonsense'.
I'd much rather have a language isn't tied to any particular ideology. Yes, your clients are web-based at the moment, but your database isn't web-based, your mail server isn't web-based, etc. Driving everything by your presentation layer is a terrible, superficial way of looking at problems.
> He said as much in that point. Did you bother reading and thinking about the article, or just trip over your own drool racing to the comments section? I'm just going to stop here.
The original blog author posted this with an air of php exceptionalism. Other languages equally have no problem handling the issues that this author claims exist.
This blog post, and your response, is a classic example of the php hammer syndrome. Yes, it kind of works, and seems neat at a superficial level, but once you start to use it, you start seeing all of the glaring flaws in the actual delivery of the product. Workarounds become dogma, and everyone suffers as a result.
> Facebook levels of load would be a great problem to have. Until then, who cares?
Good question, why did he bring it up? As others pointed out, it doesn't even make sense: your data store is where you have to scale, not the language itself.
> Doubtful, but this isn't even a good point. Working software is the important deliverable.
Hmm. I thought the goal was working and maintainable software?
> You missed the point. Writing a web app with a language that's basically tied to the web makes sense. It's not the most important point, but it isn't 'nonsense'.
No, it makes sense to choose the most powerful language. A language that's "basically tied to the web" means that you can't use it to do other things when your business needs change.
> He said as much in that point.
No, he said that php makes it less easy to screw up, which is simply not true. What if, late at night, I call mysql_escape_string (because, hey, the name makes sense!) instead of mysql_real_escape_string? Type systems make it harder to screw up. Poorly named escape functions, ridiculous type coercion, and a gigantic global namespace do not.
> Did you bother reading and thinking about the article, or just trip over your own drool racing to the comments section? I'm just going to stop here.
They see me trollin', they hatin'.
Good question, why did he bring it up? As others pointed out, it doesn't even make sense: your data store is where you have to scale, not the language itself.
> Doubtful, but this isn't even a good point. Working software is the important deliverable.
Hmm. I thought the goal was working and maintainable software?
> You missed the point. Writing a web app with a language that's basically tied to the web makes sense. It's not the most important point, but it isn't 'nonsense'.
No, it makes sense to choose the most powerful language. A language that's "basically tied to the web" means that you can't use it to do other things when your business needs change.
> He said as much in that point.
No, he said that php makes it less easy to screw up, which is simply not true. What if, late at night, I call mysql_escape_string (because, hey, the name makes sense!) instead of mysql_real_escape_string? Type systems make it harder to screw up. Poorly named escape functions, ridiculous type coercion, and a gigantic global namespace do not.
> Did you bother reading and thinking about the article, or just trip over your own drool racing to the comments section? I'm just going to stop here.
They see me trollin', they hatin'.
Doubtful, but this isn't even a good point. Working software is the important deliverable.
An unmaintainable codebase makes it hard to deliver working software in the future.
An unmaintainable codebase makes it hard to deliver working software in the future.
So programming in PHP means that your code base will be unmaintainable?
No, deciding not to hire good programmers means that your codebase will be unmaintainable.
Next time, maybe try reading the thread before commenting? Here's the discussion up to this point:
OP: "If the event that my new ventures grow and I need to hire on more programmers I do not need the best and brightest to get the job done."
tych0: "Sure, but your code will also suck and be hard to maintain."
Domenic_S: "Doubtful, but this isn't even a good point. Working software is the important deliverable."
argv_empty: "An unmaintainable codebase makes it hard to deliver working software in the future."
You: "So programming in PHP means that your code base will be unmaintainable?"
Next time, maybe try reading the thread before commenting? Here's the discussion up to this point:
OP: "If the event that my new ventures grow and I need to hire on more programmers I do not need the best and brightest to get the job done."
tych0: "Sure, but your code will also suck and be hard to maintain."
Domenic_S: "Doubtful, but this isn't even a good point. Working software is the important deliverable."
argv_empty: "An unmaintainable codebase makes it hard to deliver working software in the future."
You: "So programming in PHP means that your code base will be unmaintainable?"
I did read the thread, thank you.
"An unmaintainable codebase makes it hard to deliver working software in the future." is a truism that I chose to respond with a question, because I am not of the opinion that Domenic_S was even remotely suggesting that anyone write unmaintainable code.
Domenic_S's argument of "working software is the most important deliverable" isn't really a bad point, regardless of what language you're using. If you have maintainable code that doesn't address the application's requirements, how much does maintainability matter then?
In the real world, there is hierarchy of priorities, and for most, working is at the top of the priority list.
"An unmaintainable codebase makes it hard to deliver working software in the future." is a truism that I chose to respond with a question, because I am not of the opinion that Domenic_S was even remotely suggesting that anyone write unmaintainable code.
Domenic_S's argument of "working software is the most important deliverable" isn't really a bad point, regardless of what language you're using. If you have maintainable code that doesn't address the application's requirements, how much does maintainability matter then?
In the real world, there is hierarchy of priorities, and for most, working is at the top of the priority list.
[deleted]
You'll have to talk to tych0 about that. I'm just responding to the idea of setting aside maintainability in order to produce working code.
1. Pretty sure Facebook is the only one hitting Facebook levels. Facebook is an outlier, don't use this as an example to invalidate his entire point.
2. There are great PHP programmers...just because you're writing something in PHP doesn't mean your code sucks. There is a ton of crap PHP code, but not all. Ruby and python also have their fair share of terrible developers and shitty code.
2. There are great PHP programmers...just because you're writing something in PHP doesn't mean your code sucks. There is a ton of crap PHP code, but not all. Ruby and python also have their fair share of terrible developers and shitty code.
> 1. Until you hit facebook levels and have to write your own interpreter.
Or use the one that Facebook open sourced.
Or use the one that Facebook open sourced.
The documentation for PHP is great. But in order to do many useful things in PHP, you really, really need the documentation. FWIW, I don't find other solutions hinging their success on documentation as much as PHP.
"1. PHP is stupid easy to scale...shared nothing"
How is that a language-level feature? Unless the comparison is to framework level features like ASP.NET Session State, but PHP would only work around that by using memcached or something, right? Or is this referring to the fact that I can't have shared variables at all, so I can't cache super common data structures in a local piece of RAM?
"2. I won’t need experts" - It must be nice, if boring, to be working on really simple codebases where anyone that can hack PHP can work on your application.
"10. Dynamic typing" - There are plenty of neat reasons for dynamic typing, like easy metaprogramming and whatnot. Having crazy type coercion isn't one of them. And "HTTP is untyped so should PHP"; I'm not sure what to make of this.
This goes along with "11. It plain works" -- yea, depends on how you define works. "A lot of that is based on “assumptions” (or shortcuts) that PHP takes to solve a problem. Most often those shortcuts work, and the workarounds are very easy to implement (I’m thinking mainly about strict type checking here)."
And that's the real issue that I can see with PHP. Sometimes, some stuff might sorta make sense, and the rest of the time you're in this weird "gotcha" land, with the inconsistent API and language design.
The only compelling reason I've seen for using PHP is "well, pretty much every server has it installed, and it's super easy to get working with a webserver". PHP seems to surpass everything else in that particular area. Apart from that, come on...
How is that a language-level feature? Unless the comparison is to framework level features like ASP.NET Session State, but PHP would only work around that by using memcached or something, right? Or is this referring to the fact that I can't have shared variables at all, so I can't cache super common data structures in a local piece of RAM?
"2. I won’t need experts" - It must be nice, if boring, to be working on really simple codebases where anyone that can hack PHP can work on your application.
"10. Dynamic typing" - There are plenty of neat reasons for dynamic typing, like easy metaprogramming and whatnot. Having crazy type coercion isn't one of them. And "HTTP is untyped so should PHP"; I'm not sure what to make of this.
This goes along with "11. It plain works" -- yea, depends on how you define works. "A lot of that is based on “assumptions” (or shortcuts) that PHP takes to solve a problem. Most often those shortcuts work, and the workarounds are very easy to implement (I’m thinking mainly about strict type checking here)."
And that's the real issue that I can see with PHP. Sometimes, some stuff might sorta make sense, and the rest of the time you're in this weird "gotcha" land, with the inconsistent API and language design.
The only compelling reason I've seen for using PHP is "well, pretty much every server has it installed, and it's super easy to get working with a webserver". PHP seems to surpass everything else in that particular area. Apart from that, come on...
>> Or is this referring to the fact that I can't have shared variables at all, so I can't cache super common data structures in a local piece of RAM?
This isn't true. You can store variables in APC and they are available in local RAM across all PHP processes (within CGI + webserver at least, the same APC cache is not available to cronjobs and other scripts).
>> "2. I won’t need experts" - It must be nice, if boring, to be working on really simple codebases where anyone that can hack PHP can work on your application.
This can be read as a negative, but I see it as a positive in a lot of cases, i.e. when you already have a plan for your app, and you can get by with a reasonably good developer who can follow directions and write good code. I think what the OP meant was that you're not constrained to rock-star/ninja keywords, but if you find that person, then all the better.
>> This goes along with "11. It plain works" -- yea, depends on how you define works. "A lot of that is based on “assumptions” (or shortcuts) that PHP takes to solve a problem. Most often those shortcuts work, and the workarounds are very easy to implement (I’m thinking mainly about strict type checking here)." >> And that's the real issue that I can see with PHP. Sometimes, some stuff might sorta make sense, and the rest of the time you're in this weird "gotcha" land, with the inconsistent API and language design.
Correct, PHP is not a strictly typed language and the userland function and class names are not very consistent. There's a lot of other languages that are more elegant and fun to work with.
It does have very real benefits in terms of flexibility, ease of deployment, expected behavior under heavy load, and finding developers who can learn quickly whatever is unique about your stack.
Every language and stack has it's own "gotcha" land; this issue is not unique to PHP. Honestly responding to this in threads is kind of a waste since we'll all be in this conversation again the next time another PHP good-or-bad thread pops up on HN.
This isn't true. You can store variables in APC and they are available in local RAM across all PHP processes (within CGI + webserver at least, the same APC cache is not available to cronjobs and other scripts).
>> "2. I won’t need experts" - It must be nice, if boring, to be working on really simple codebases where anyone that can hack PHP can work on your application.
This can be read as a negative, but I see it as a positive in a lot of cases, i.e. when you already have a plan for your app, and you can get by with a reasonably good developer who can follow directions and write good code. I think what the OP meant was that you're not constrained to rock-star/ninja keywords, but if you find that person, then all the better.
>> This goes along with "11. It plain works" -- yea, depends on how you define works. "A lot of that is based on “assumptions” (or shortcuts) that PHP takes to solve a problem. Most often those shortcuts work, and the workarounds are very easy to implement (I’m thinking mainly about strict type checking here)." >> And that's the real issue that I can see with PHP. Sometimes, some stuff might sorta make sense, and the rest of the time you're in this weird "gotcha" land, with the inconsistent API and language design.
Correct, PHP is not a strictly typed language and the userland function and class names are not very consistent. There's a lot of other languages that are more elegant and fun to work with.
It does have very real benefits in terms of flexibility, ease of deployment, expected behavior under heavy load, and finding developers who can learn quickly whatever is unique about your stack.
Every language and stack has it's own "gotcha" land; this issue is not unique to PHP. Honestly responding to this in threads is kind of a waste since we'll all be in this conversation again the next time another PHP good-or-bad thread pops up on HN.
For HN, this is a majorly linkbait-ey title.
Now that that's out of the way, this is a pretty spot on article. I find it very interesting that points brought up against PHP (weak typing, easy to write swiss cheese security code, framework overload) are generally it's greatest strengths as well.
Let's take the weak typing issue for example: Sorry, you should be keeping track of your variables. If you can't do this, then just define your own object and use it. I do this with just about all return types now; it's pretty nice to always know what type of variable you're going to be dealing with on the other side of your MVC. The worst thing that comes from this issue (which exists in every weakly typed language) is improper use of comparison operators (!= vs. !==, == vs. ===). Again, this is up to the developer.
PHP will give you the lumber and the rope, but it's up to the developer if you hang yourself or manage to build a galleon. Personally, I love having the option of total control with the risk of total destruction.
Now that that's out of the way, this is a pretty spot on article. I find it very interesting that points brought up against PHP (weak typing, easy to write swiss cheese security code, framework overload) are generally it's greatest strengths as well.
Let's take the weak typing issue for example: Sorry, you should be keeping track of your variables. If you can't do this, then just define your own object and use it. I do this with just about all return types now; it's pretty nice to always know what type of variable you're going to be dealing with on the other side of your MVC. The worst thing that comes from this issue (which exists in every weakly typed language) is improper use of comparison operators (!= vs. !==, == vs. ===). Again, this is up to the developer.
PHP will give you the lumber and the rope, but it's up to the developer if you hang yourself or manage to build a galleon. Personally, I love having the option of total control with the risk of total destruction.
But improper use over something as simple as typing (at least typing as implemented by popular languages these days) _should not be a problem_.
If I create a bug by multiplying by a string, I'd ideally find out immediately after writing it, as the background compiler/analyzer detects the problem. Saying "Oh, well, we'll just assume that an integer times a string is 0" is just... dumb.
Seriously, if a program has a bug like that, what's the point of continuing execution? What's the real-world use case for this? The only use case I can see is "people screwing around making a home page, where nothing really matters and if they make a mistake, hey, just try to go on and maybe that last line wasn't really important anyways". It's the Visual Basic "On Error Resume Next" mindset.
If I create a bug by multiplying by a string, I'd ideally find out immediately after writing it, as the background compiler/analyzer detects the problem. Saying "Oh, well, we'll just assume that an integer times a string is 0" is just... dumb.
Seriously, if a program has a bug like that, what's the point of continuing execution? What's the real-world use case for this? The only use case I can see is "people screwing around making a home page, where nothing really matters and if they make a mistake, hey, just try to go on and maybe that last line wasn't really important anyways". It's the Visual Basic "On Error Resume Next" mindset.
You might get behaviour that is a lot more difficult to spot in production when multiplying an integer by a string that starts with an integer, too.
Even the most skilled PHP developer will have some head scratching moments when things appear to work but actually don't.
echo 10 * "300 bananas";
// 3000
Makes total sense, doesn't it? And it could easily happen if you maintained a poorly written project with crap data stashed in the database.Even the most skilled PHP developer will have some head scratching moments when things appear to work but actually don't.
One of my least favorite things is the behavior of undefined constants.
Use an undefined constant:
Get an exception? Nope. Get an empty string? Nope.
PHP will put the name of the constant in the rendered HTML. Arg.
Use an undefined constant:
Get an exception? Nope. Get an empty string? Nope.
PHP will put the name of the constant in the rendered HTML. Arg.
there would be if an error if error_reporting(E_ALL) was used.
Sadly you have to manually set an exception handler if you want it as an exception :(
The language doesn't do something, so it's the developer's responsibility, and thus the developer's fault when it goes wrong.
This is a strange way to judge your tools.
This is a strange way to judge your tools.
"Dynamic typing – But how do you know if you’re working with an int or a string? By using your brain. HTTP does not do typing and so PHP does not do (strong) typing for scalars"
If you are going to defend dynamic typing (which, by the way, I have no problem with), at least try to bring better arguments. First of all, we can do everything just "by using our brains". Why the hell write programs at all then? Let's just use our brains!
Static type checking is a task that can be automated, compilers have been doing that for years, and it saves our asses from a lot of dumb bugs by making bad code fail as early as possible - at compile time. When you throw that away, you better have a good reason for doing so. "HTTP does no typing" is definitely not a good reason.
"Dynamic typing significantly reduces the amount of code you need to write" - only if you want your code to eventually surprise you with a subtle type-related bug.
If you are going to defend dynamic typing (which, by the way, I have no problem with), at least try to bring better arguments. First of all, we can do everything just "by using our brains". Why the hell write programs at all then? Let's just use our brains!
Static type checking is a task that can be automated, compilers have been doing that for years, and it saves our asses from a lot of dumb bugs by making bad code fail as early as possible - at compile time. When you throw that away, you better have a good reason for doing so. "HTTP does no typing" is definitely not a good reason.
"Dynamic typing significantly reduces the amount of code you need to write" - only if you want your code to eventually surprise you with a subtle type-related bug.
I don't agree with much of this, but I consider 6 & 7 to be php's great weakness. The signal to noise ratio is awful. There is so much garbage "docs" and examples that it is hard to find dependable sources. Search for python or ruby help and you can be reasonably confident that what you find isn't going to blow up in you face. This is the cost of being so popular with amateurs and semipros
It's difficult to take articles about languages like this seriously without the author demonstrating some knowledge of other more and less powerful languages. That way they at least have some idea of where they sit on the blub spectrum:
http://www.paulgraham.com/avg.html
http://www.paulgraham.com/avg.html
I find it amusing that "PHP is stupid easy to scale..." but his site is overloaded right now.
it really is amusing but i think is the server's fault :)
> Best documentation on the web
No, no, no. Poorly or completely undocumented parameters, the "comments" being seen as replacement for coherent examples ... I'm not sure if the author is joking or did actually never look at the documentation of other languages like Python's.
No, no, no. Poorly or completely undocumented parameters, the "comments" being seen as replacement for coherent examples ... I'm not sure if the author is joking or did actually never look at the documentation of other languages like Python's.
I've heard this same quip a lot, and I don't understand it either. I pored through a lot of PHP documentation to write an angry blog post about it, and it was unbelievably painful; documentation for simple extensions was broken into a dozen tiny useless pages, obvious cross-references were missing, similar items are documented in radically different places, etc. There's a lot of text, sure, but it's poorly organized and not all equally useful.
More often than not, the comments sections are just lists of various reimplimentations of the function for versions of PHP that don't have it, or have a bugged version.
Or they give horrible examples like trusting user input without the necessary disclaimers. It's just a very bad idea for an inexperienced user to rely on those.
> Poorly or completely undocumented parameters
Example?
Example?
I'll give you the one good reason to use PHP: Everyone and their dog offers PHP hosting for pennies a month. It's just there. It's the Windows of programming languages. You can distribute something like phpBB or MediaWiki and any doofus webmaster will have some understanding of how to install it and stuff the data into the shared MySQL database next door.
So if that's your target audience, or if you're happy sitting around on Dreamhost setting up your site's shopping cart as quickly as reasonable and then doing better nontechnical things, fine. Use PHP. Pray you don't get hacked, but you'll probably be praying in any language at that scale.
If you're out to sell technology or something, or handling real business (like, millions of dollars) with your website, there are probably better ways to build a long-lived robust technical solution, and most people here would appreciate it.
So if that's your target audience, or if you're happy sitting around on Dreamhost setting up your site's shopping cart as quickly as reasonable and then doing better nontechnical things, fine. Use PHP. Pray you don't get hacked, but you'll probably be praying in any language at that scale.
If you're out to sell technology or something, or handling real business (like, millions of dollars) with your website, there are probably better ways to build a long-lived robust technical solution, and most people here would appreciate it.
If you're handling "real" business on your website, there are multiple MVCs in play. Your website stack is a presentation layer that consumes internal APIs/message busses and the big data is handled elsewhere.
Yeah... and a little hacked together PHP can be the top edge of that stack if you want, but I sure hope it's not handling the important business logic on the back end of your internal message bus et cetera. In fact, just about any other language in the world would probably be a better choice.
PHP is a terrible language in which you can easily write code that will run basically anywhere. There are many cases (i.e. open source web apps) where the value of the latter vastly outweighs the former, but it's not going to be true for everyone.
I was fully expecting this to be satire.
I'm not sure who this post is aimed at. I hope it wasn't developers, for his sake. He's basically saying that a) he's only interested in hiring dim people and b) smart people moody and easily bored. Good luck recruiting people with that pitch. Eesh.
The website died...I guess PHP is not that "stupid easy to scale" after all...
The second point could have been a lot less offensive and inflammatory if the author just said "it's cheaper."
12. If your startup can only afford 16 year old wanna be hackers you will have no problem finding them.
Someone please copypasta, the blogger seems to have used his bandwidth allowance.
Google cache: http://tinyurl.com/c39mcvt
A lot of these could surely be argued reasons not to use PHP.
Site seems down :/
what? No comments yet.
PHP is stupid easy to scale
So is every other programming language. The hard part is scaling your centralized database. Considering most people using PHP are writing applications backed by a single SQL database, it's a bit disingenuous to call the language "shared nothing". While true, it's completely meaningless and true of literally every programming language ever.
It's like saying, "English makes it really easy to tell love stories."
I won’t need experts – If the event that my new ventures grow and I need to hire on more programmers I do not need the best and brightest to get the job done.
True of any language. I can hire people that are bad at programming any language, cheaply.
The deeper problem is that PHP makes it tough to multiply effort by creating good abstractions, so there is a lot of repetitive grunt-work that's best outsourced to a country where people are happy making five bucks an hour.
It is tied to the web
"PHP doesn't work very well when not serving web pages, so I use it to serve web pages." The tautology department called, they want their tautology department back.
When it fails, it doesn’t fail hard
I am not sure what this means. Each request is handled by a single UNIX process. That's, again, how the author happens to architect applications, not an intrinsic (or unique) property of PHP.
Other languages need a lot of plumbing to handle that.
Citation needed. This is standard CGI that's been around since the 80s.
There are a plethora of frameworks to chose from
That's fine. Again true of any language. Even Common Frickin' Lisp has several frameworks.
Best documentation on the web
The author does not explain why, only that he wishes he could log in with his Twitter account to propose changes. (What ever happened to emailing the author?)
Tons of blogs
True of everything, from programming languages to pictures of cats.
The PHP Community
True of pretty much every language I've ever encountered. Even C.
I like the Perl community best because of the infrastructure that the members build for each other. Want to get an email when your module's tests fail on HP-UX? Someone has built a service for that.
Answering questions is nice, but that's the tip of the community iceberg.
It integrates with everything
I read this as: "PHP has a socket API."
Dynamic typing
I'm just going to quote this one verbatim because I can't come up with anything more hilarious:
“But how do you know if you’re working with an int or a string?” By using your brain. HTTP does not do typing and so PHP does not do (strong) typing for scalars. Quite frankly, it makes complete sense to do it that way. Want an int? Cast the damn thing and stop complaining. Dynamic typing significantly reduces the amount of code you need to write and error conditions you need to check for. It plain works – Programmer’s have it wrong. The technical solution is not the end goal. Technology should be an enabler. Do you have a wonderful technical solution that doesn’t solve a problem? Bye, bye. PHP solves problems faster, easier and with a lower cost of ownership than almost anything out there. A lot of that is based on “assumptions” (or shortcuts) that PHP takes to solve a problem. Most often those shortcuts work, and the workarounds are very easy to implement (I’m thinking mainly about strict type checking here).
Little does the author know that you can have dynamic typing in any statically-typed language:
All PHP adds are operators like + that are typed Scalar -> Scalar instead of Number -> Number, making up arbitrary behavior for non-numeric values. If you wanted dynamic typing in Java, you would just write a special math library over your Scalar type and write your application in terms of those operations instead of the built-in ones. The reason nobody does that is because the static typing, though verbose, makes for nice self-documentation.
At some point you need to decide on a type for a value and most people try to do that as soon as possible. When I write in a dynamically typed language that's not Python, I usually assert well-formedness immediately after reading the data from outside my program. At that point, dynamic typing is a loss in safety to me. (When I write Python, I never explicitly check types and let mistyped operations fail at runtime, because that's the convention.)
Anyway, that was a fun article.