SitePoint Sponsor

User Tag List

Results 1 to 3 of 3
  1. #1
    SitePoint Enthusiast adityamenon90's Avatar
    Join Date
    Apr 2010
    Posts
    36
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

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


  2. #2
    SitePoint Wizard bronze trophy Jeff Mott's Avatar
    Join Date
    Jul 2009
    Posts
    1,312
    Mentioned
    19 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by adityamenon90 View Post
    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.

    Quote Originally Posted by adityamenon90 View Post
    • 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.

    Quote Originally Posted by adityamenon90 View Post
    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.

    Quote Originally Posted by adityamenon90 View Post
    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):

    PHP Code:
    $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.

    Quote Originally Posted by adityamenon90 View Post
    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.

    Quote Originally Posted by adityamenon90 View Post
    • 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.

    Quote Originally Posted by adityamenon90 View Post
    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/
    "First make it work. Then make it better."

  3. #3
    SitePoint Enthusiast adityamenon90's Avatar
    Join Date
    Apr 2010
    Posts
    36
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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
    Circle me on google plus. And check out these superb premium domains that are up for sale.


Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •