Explanation of these comments against PHP in a popular article?
Jeff Atwood recently linked to a blog post named "PHP: a fractal of bad design".
I'm writing a summary of the stance of the author, in his own words. Then, I write my questions about each point. Most of the time, my question is, "am I thinking right?" - and in other times, "what is the problem?".
Please note that I'm not trying to support/defend PHP here, I'm trying to understand the problems better, rather than simply repeat them if/when I get asked.
- PHP is full of surprises: mysql_real_escape_string, E_ALL
- What surprises is the author referring to?
- mysql_real_escape_string() needs a DB connection before escaping is done. Yeah, I felt that's kind of stupid too, but I may be worried about the wrong thing...
- E_ALL is a subset of E_STRICT, but one would expect it to be a super-set from the name. Is it that?
- PHP is inconsistent: strpos, str_rot13
- Underscore in one function and no underscore in the other..?
- PHP requires boilerplate: error-checking around C API calls, ===
- I didn't get the point about error-checking and C API Calls - is that the whole new Exception() routine is cumbersome? How do other languages make it easier?
- What is it about === and conciseness? Need of too many keystrokes?
- PHP is flaky: ==, foreach ($foo as &$bar)
- == : I think the objection is that devs think == does what === also (check type along with value), but I thought this differentiation was more flexible? Isn't this an advantage in a dynamically typed language?
- Prepending an ampersand makes the value change inside target array but not prepending it leaves the target array unchanged by the logic inside a foreach() - is this 'gotcha' the problem?
- PHP is opaque: no stack traces by default or for fatals, complex error reporting