Meh, I've written a lot of PHP code. I also work in Ruby and Python. All three have problems, but I like all three.
With PHP, you have to develop a coding style that naturally avoids PHP's weird areas. It's not really that hard to avoid the mines, but you do have to be aware of them.
In exchange, you get a scalable web server and a language that requires minimal babysitting. Instead of automatically throwing a 500 on a random, unimportant, uncaught exception, PHP makes a best effort, and most of the time the result is fine. 99% of the time, this is better behavior from a user's perspective as long as functioning perfectly isn't mission critical. It may feel offensive to your OCD programmer nature, but from a pragmatic engineer's standpoint, it's oftentimes a better choice, especially when dealing with the dirty data that's so common in webapps. Do not use PHP in a banking setting.
Compared to running a rails app, administering and scaling mod_php is pleasantly hassle-free. A single webserver with a modest amount of memory can handle an large number of concurrent PHP processes and requests without needing to resort to reverse proxies or anything more exotic than a simple apache install. That's nice not only for the ease of setup, but also because it means fewer moving parts, and less maintenance. That's a very real plus, and I'd say that the shared-nothing architecture of PHP was great engineering choice.
Yes, the language is weirdly architected and oftentimes inconsistent. It can also be extremely productive, and many of its weird choices are extremely pragmatic. The security holes are pretty horrifying, though - the defaults should be much more locked down, and I've always been a bit mystified that they're not.
Instead of automatically throwing a 500 on a random, unimportant, uncaught exception, PHP makes a best effort, and most of the time the result is fine.
And how precisely does PHP "know" which exceptions are important and which are not? In my experience of 6 years as a web developer, the faster and the more explicitly something fails the better. If the user gets a 500, that's a pretty clear sign of a problem, I get an email notification about it, including user id, session data etc. Then, in most cases, I can easily see what the problem was, decide what the correct behaviour is and create a fix immediately and even notify the user after releasing it if I wish to do it. If there is no exception there is a case in the code I was not aware of when writing it and it will still not be brought to my attention. In the best case, the user will report some problem with the functionality and I will have to spends hours trying to find the logs for this user and reproduce the problem, which will now be much harder, quite some time could have passed since the error, the database entries for the user could have change meanwhile (including corruption caused by the system continuing to operate despite an error) and so on. In the worst case, the bug will continue to affect users (which might not even know what the intended behaviour was) and I will learn about it a year from now, accidentally.
Reproducing bugs is hard enough in web applications due to their distributed nature, some of the applications I worked on had serious business-affecting bugs that went unnoticed for months and failure to clearly signal errors is one of the common cases. It doesn't matter whether you are in banking or just building another social CMS/CRM "kind of thing", if you have bugs you loose users and with them money.
Catching exceptions and returning a 200 OK blank page is about the worst thing that PHP is doing. A simple error can trash your google index (Oh, page replaced by blank content, fine!) or mess up API communication when the receiver does not explicitly check for the response content (POST to endpoint, 200 OK, ok, nice). And while you can catch and handle some of those errors with your own error handlers, there are error classes that you can not handle and which will always be handled internally. It's a pure mess.
I understand fail fast, and errors do still get logged and made visible (New Relic is great like that). I would rather fail a bit slower, silently, though. It's much less jarring to users, and therefore you lose fewer.
It's less jarring for the users that you have to tell them weeks after they entered some important data that all this data has been lost? Is it less jarring if they order something and the order confirmation does not arrive and they don't know whether to try again or not?
If there's an issue that affects business logic I'd like my app to display "Sorry, something blew up. Please leave a message and we'll get back to you." instead of chugging along quietly. If the error is not critical (some external feed gone, whatever) _I_ as a developer can decide to catch the error and handle, log or even ignore it. But it's not PHP that can decide to do so.
Lets say for someone who is new to PHP, how long does it normally takes to learn where the minefields are? Is there anyway to start on this? I know in JS there is Javascript The Good Part. Is there anything equivalent in PHP?
Hm, not that I know of. The biggest thing is to read about PHP's security issues (especially how to avoid SQL injection attacks). After that, it's mostly writing code in it. If you start by writing PHP like you'd write C and then branch out, you can figure it out. Stay away from running anything shell related from your PHP code or anything that manipulates the file system unless you know what you're doing. If you're doing anything that's very critical to your users, I'd probably do it in a different language.
With PHP, you have to develop a coding style that naturally avoids PHP's weird areas. It's not really that hard to avoid the mines, but you do have to be aware of them.
In exchange, you get a scalable web server and a language that requires minimal babysitting. Instead of automatically throwing a 500 on a random, unimportant, uncaught exception, PHP makes a best effort, and most of the time the result is fine. 99% of the time, this is better behavior from a user's perspective as long as functioning perfectly isn't mission critical. It may feel offensive to your OCD programmer nature, but from a pragmatic engineer's standpoint, it's oftentimes a better choice, especially when dealing with the dirty data that's so common in webapps. Do not use PHP in a banking setting.
Compared to running a rails app, administering and scaling mod_php is pleasantly hassle-free. A single webserver with a modest amount of memory can handle an large number of concurrent PHP processes and requests without needing to resort to reverse proxies or anything more exotic than a simple apache install. That's nice not only for the ease of setup, but also because it means fewer moving parts, and less maintenance. That's a very real plus, and I'd say that the shared-nothing architecture of PHP was great engineering choice.
Yes, the language is weirdly architected and oftentimes inconsistent. It can also be extremely productive, and many of its weird choices are extremely pragmatic. The security holes are pretty horrifying, though - the defaults should be much more locked down, and I've always been a bit mystified that they're not.