Explanation of these comments against PHP in a popular article?

[adityamenon90]

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.
Predictability

• 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?

Consistency

• PHP is inconsistent: strpos, str_rot13
  
  • Underscore in one function and no underscore in the other..?

Conciseness

• 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?

Reliability

• 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?

Debuggability

• PHP is opaque: no stack traces by default or for fatals, complex error reporting
  
  • I've never experienced debugging another language (well, JavaScript in the browser, but JS is even worse, especially without the help of something like Firebug). So I don't know what I'm missing. But I agree that it's a spectacular pain to find errors in PHP - but I'll gladly read any other explanations posted on this topic.

[Jeff Mott]

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.
Predictability

• 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...

I don't think the author clarified this point well enough, but your guess sounds about right.

• E_ALL is a subset of E_STRICT, but one would expect it to be a super-set from the name. Is it that?

Mostly that's right. You would expect E_ALL to include E_STRICT. Isn't that what "all" means? In a rebuttal, another user agreed that this was confusing, but noted that it was done to keep backward compatibility with PHP 4.

Consistency

• PHP is inconsistent: strpos, str_rot13
  
  • Underscore in one function and no underscore in the other..?

Correct. The author also cites "to" versus 2, object+verb versus verb+object, and inconsistent argument orders, prefixes, case insensitive naming, and inverses.

Conciseness

• 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?

I believe the author is referring to the old-school way of checking for errors (which was your only option in C):

$link = mysql_connect('localhost', 'mysql_user', 'mysql_password');
if (!$link) {
    die('Not connected : ' . mysql_error());
} 

Checking the return value of every function that might fail is cumbersome. Exceptions are better.

Reliability

• 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?

I think the reason the author considers == flaky is due to PHP's oftentimes strange type coercion. For example, 'foo' == 0 is true. Also, if $a == $b and $a == $c, then you'd expect $b == $c, but in PHP that may not be the case. The author gives several other examples that fall under the category of strange type coercion.

• 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?

I'm not sure what the author is referring to with this one, and he didn't seem to clarify later in the article.

Debuggability

• PHP is opaque: no stack traces by default or for fatals, complex error reporting
  
  • I've never experienced debugging another language (well, JavaScript in the browser, but JS is even worse, especially without the help of something like Firebug). So I don't know what I'm missing. But I agree that it's a spectacular pain to find errors in PHP - but I'll gladly read any other explanations posted on this topic.

A stack trace shows not just the error, but all the function calls that led to that error. For example, http://www.flickr.com/photos/pioupio...n/photostream/

[adityamenon90]

Thank you so much Jeff Mott! You cleared all my doubts in one epic swoop Thanks again! Very useful explanations.

Stack trace looks nice... so it looks like Symfony is able to transcend this limitation of PHP by adding this feature in... I do plan to explore the framework one day