Slashdot Mirror


Book Review: Programming PHP 3rd Edition

Michael Ross writes "As a hugely popular scripting language with an 18-year history, PHP has been the topic of countless computer language books. One of the most comprehensive offerings has been Programming PHP, published by O'Reilly Media. The first edition appeared in March 2002, and was written by Rasmus Lerdorf (the original developer of PHP) and Kevin Tatroe. A second edition was released in May 2006, and saw the addition of another co-author, Peter MacIntyre. With the many changes to the language during the past seven years, the book has again been updated, to cover all of the major new features made available in version 5 of PHP." Keep reading for the rest of Michael's review. Programming PHP, 3rd Edition author Kevin Tatroe, Peter MacIntyre and Rasmus Lerdorf pages 540 publisher O'Reilly Media rating 8/10 reviewer Michael Ross ISBN 978-1449392772 summary An extensive tutorial of the PHP web programming language. This third edition was published on 22 February 2013, under the ISBN 978-1449392772, with the same three authors at the helm. At a substantial 540 pages, the information is organized into 17 chapters, each focusing on a particular area of the language and its usage. This material precedes an appendix of almost 130 pages, which serves as a reference for all of the language's built-in functions. In fact, not only could this book suffice as a reference guide, it could also serve as a tutorial, because it is accessible to programmers of all levels, including beginners who have never before worked with PHP. The preface notes that the material assumes only "a working knowledge of HTML." However, the example code seems to also assume that the reader is comfortable with fundamental programming concepts, such as conditionals and loops.

To learn more about the book, prospective readers and buyers may wish to visit the publisher's website, where they will find a description of the book, its table of contents, a free copy of its first chapter, and the example code for ten of the chapters. Speaking of formats, the book is available in print and electronic media. (This review is based upon a copy of the print version kindly provided by the publisher.)

The first three chapters explain the bedrock fundamentals of the language, including its lexical structure, data types, variables, expressions, operators, flow-control statements, code inclusion methods, and functions. All of the information appears to be valid, aside from several technical blemishes: In Example 1-1, most of the lines of code are duplicated. Example 1-5, which supposedly creates a PNG file, does not seem to work. The section on constants (page 21) should have mentioned the core predefined constants and also distinguished those from magic ones. The binary literal 0b01100000 is 96, not 1 (page 23). It is claimed that an object is evaluated as false if it contains no values or functions (page 25), and yet: "class C{} assert( new C );." The closure example code (page 29) fails because it includes a function name and no terminating semicolon. The example code in the middle of page 66 contradicts the claim that an inner function "cannot be called from code parsed after the outer function." The example code starting at the end of that page fails because $a in foo() is undefined. Nonetheless, even experienced PHP programmers could pick up knowledge not encountered before, or at least refresh what was learned years ago and since forgotten due to disuse.

The next two chapters explore in detail further essential components of PHP: strings, regular expressions, and arrays. As with the earlier chapters, readers will encounter example code that does not appear to have been tested. For instance, the print_r() output of an object is missing the class name (page 84). On the same page, print_r() and var_dump() of $GLOBALS do indicate "*RECURSION*," but do not loop infinitely or three times, respectively, as claimed. The $record on page 86 is missing its trailing tab character. For these errors and others, it is not clear whether the authors or the technical reviewers are ultimately responsible. Regardless, readers should find useful the tables summarizing regular expression character classes, anchors, quantifiers, and options. On the other hand, the treatment of conditional expressions is sorely in need of examples. Also, readers will be baffled when told that "The preg_match() function takes the same arguments and gives the same return value as the preg_match() function []" (page 112). Lastly, the callback example code is faulty (pages 131, 133, and 141). The sixth chapter, covering object-oriented programming is well-written, aside from the confusing phrase "including it to a different name" (page 160) and the anti-Nietzschean "this will fatal" (page 161).

With Chapter 7, the book shifts gears from the basic underpinnings of PHP to more applied topics, in this case, web techniques — specifically HTTP, global variables, server information, web form processing, sessions, and more. The narrative is quite clear, except when the reader is told that periods in field names are converted to underscores because periods are illegal in PHP variable names (page 178); the connection is not explained. The next chapter looks at server-side data storage, including the topics of PDO, MySQLi, SQLite, and MongoDB. Confusingly, readers are told that the sample SQL database code is available in a file, but they are not told where to find it (http://examples.oreilly.com/0636920012443/).

Chapters 9 through 11 address PHP's support for three specialized file types: graphics, PDF, and XML. The explanations are excellent, and the authors provide numerous examples. The only obvious flaws are in Example 11-1 (page 269), where the echo statement is missing the "<?" and two of the lines have mismatched single and double quotes.

The remaining half dozen chapters cover critical aspects of PHP development. The chapter on security does not attempt to be exhaustive, but instead explains the most common attack vectors and how to block them. The chapter on application techniques discusses code libraries, templating, output buffering and compression, error handling, and performance tuning. Any programmer intrigued by the idea of replacing clunky VBA code with PHP, should be interested in Chapter 14, which explores the differences in running PHP on Windows vs. other platforms, with a brief look at manipulating the contents of Microsoft Word and Excel files using PHP. RESTful web services and XML-RPC are the topics of the next chapter, whose only apparent blemish is that json_encode() does not add spaces between the array values (page 339). The penultimate chapter addresses multiple environments, manual debugging, and the use of an IDE. The last chapter briefly covers PHP support for dates and times, and thus should have been located much earlier in the book, with the other material on fundamental concepts.

Overall, this book is quite approachable. Throughout, one will find programming style recommendations, However, as with any technical work of this size, there are passages that could be made more complete or clear. Occasionally the authors will mention something explained only later — e.g., "short echo tag" (page 60) — which can be frustrating to anyone new to a language.

The concepts of PHP being taught are extensively illustrated with example code. Some of it is concise enough so as not to distract from the narrative flow, but far too many examples involve much more code than necessary. This at first glance might seem to be an advantage, but it actually makes it more difficult for the reader to see the parts of the code relevant to the topic at hand. Also, the authors underutilize whitespace in the code, instead jamming tokens and parentheses together.

In a book of this size, we should not be astonished to find some errata: "Wordpress" (page xv), "try and" (same page; should read "try to"), "tick function registered when register_tick_function()" (55; should read "with" not "when"), "eXtensible" (59), "super-global" (67; should read "superglobal"), "display_classes() function" (vs. "function displayClasses()"; 164), "$var" (294 and 295; should read "$value"), "functions of blocks" (323; should read "functions or blocks"), "retried" (337; should read "retrieved"), and "a.k.a." (350; should read "e.g.").

In terms of the production of the book, like most other O'Reilly titles, this one is nicely put together, with readable font. But sometimes words are jammed together so much that lines appear to be a single word, e.g., "codeitselfbutplentifulenoughthatyoucanusethecommentstotellwhat'shappening" (page 17). Also, the publisher should avoid splitting the function names as if they were English words, e.g., "addc" and "slashes()" on separate lines (page 91). The index is missing some obvious entries, e.g., "closures." Many code snippets are missing the "Example" numbers and captions. This may be fine if the authors do not reference those snippets, but makes it problematic for anyone else to reference them.

Even though this is arguably one of the most comprehensive PHP books on the market, it does not cover all aspects of the language. On page 1, readers learn that PHP can be utilized in three major ways — server-side scripting, command-line scripting, and client-side GUI applications; but only the first is covered in the book. The appendix consumes over 120 pages, and comprises information easily available online in the PHP manual's function reference. Those pages could instead have been devoted to at least introducing command-line scripting and GUI applications. In fact, there are two major changes the authors could take in bringing this book much closer to perfection: Firstly, retest all of the code and root out any technical snafus. Secondly, replace the lengthy appendix with full coverage of the topics of command-line scripting and client-side GUI applications.

Regardless, Programming PHP is both a tutorial and a reference resource packed with information and example code. Benefiting from the author's deep expertise in the language and its usage, the book is the most promising single source for anyone who wishes to learn this ubiquitous web scripting language.

Michael Ross is a freelance web developer and writer.

You can purchase Programming PHP, 3rd Edition from amazon.com. Slashdot welcomes readers' book reviews (sci-fi included) -- to see your own review here, read the book review guidelines, then visit the submission page.

155 comments

  1. But... by stewsters · · Score: 2, Funny

    I stopped after i read about GOTO. Do you want raptors?

    1. Re:But... by KalvinB · · Score: 2, Insightful

      Even the manual acknowledges it is bad practice and includes the XKCD comic

      There are so many languages that try to hide bad programmers. Give me a PHP programmer and his code and I can tell you if he's worth anything, The language lets you code like an idiot. Which is great, because then I can either not hire you or pay you accordingly if I think you have potential.

      GOTO is not a part of PHP so you can use it. It's part of PHP so that if you use it, you are immediately fired and blackballed from the industry. It's a trap.

    2. Re:But... by Anonymous Coward · · Score: 1

      The goto seems very arbitrary.
      And since PHP supports exceptions (as far as I understand) what exactly is the point of the goto?
      Literally the only valid use of goto is for error handling, and that is covered by exceptions.
      Every single example they have given could be rewritten using standard control flow.

    3. Re:But... by Anonymous Coward · · Score: 0

      Literally the only valid use of goto is for error handling, and that is covered by exceptions.

      I use goto in C all the time to break out of loops and jump to a cleanup function at the end of the code. Of course C doesn't have exceptions and nobody compiles PHP to the metal AFAIK, so I think you're right.

    4. Re:But... by ackthpt · · Score: 1

      Even the manual acknowledges it is bad practice and includes the XKCD comic

      There are so many languages that try to hide bad programmers. Give me a PHP programmer and his code and I can tell you if he's worth anything, The language lets you code like an idiot. Which is great, because then I can either not hire you or pay you accordingly if I think you have potential.

      GOTO is not a part of PHP so you can use it. It's part of PHP so that if you use it, you are immediately fired and blackballed from the industry. It's a trap.

      I did encounter a piece of code, ages ago, where in a GOTO was the only possible way to accomplish something. They're pretty rare, but in the instance you need the option it is nice knowing it is there.

      --

      A feeling of having made the same mistake before: Deja Foobar
    5. Re:But... by OhSoLaMeow · · Score: 2

      The goto seems very arbitrary. And since PHP supports exceptions (as far as I understand) what exactly is the point of the goto? Literally the only valid use of goto is for error handling, and that is covered by exceptions. Every single example they have given could be rewritten using standard control flow.

      It used to be worse. Much worse. Cobol used to have this notion of "ALTER X TO PROCEED TO Y" whereby X was a paragraph containing a GOTO statement. After the ALTER statement is executed, the paragraph X code was modified to now transfer control to paragraph Y. So you had no idea where the logic flow was going because it depended upon whether or not the ALTER was executed.

      Life was hell.

      --
      They can take my LifeAlert pendant when they pry it from my cold dead fingers.
    6. Re:But... by Anonymous Coward · · Score: 1

      I would actually like to see that code. I don't think it is the only way, but if it was that would be cool. If you ever see it again, post it here.

    7. Re: But... by cripkd · · Score: 1

      I don't think "the only possible way" means what you think it does.

      --
      Curiously yours, crip.
    8. Re:But... by narcc · · Score: 4, Insightful

      Indeed. GOTO is not inherently evil. You'll find it used appropriately in some surprising places -- including the Linux Kernel.

      When describing a process, the oft-maligned GOTO certainly comes in handy. The over 30 crowd might remember seeing GOTO's in any number of guide books from auto repair to taxes. (The word wasn't always used, sometimes "skip to ..." or "continue with ..." etc.)

      That's right: GOTO can actually make things easier to read and understand.

      Even in software today, I'm willing to bet even the most ardent anti-GOT zealot has used a GOTO -- and recently at that -- cleverly disguised as a break or return statement.

    9. Re:But... by vilanye · · Score: 5, Informative
      The linux kernel has many examples. A common usage is using goto to deal with exceptions so you don't fill up the critical path with branches and blow your cache.

      Some newbie actually went on the kernel's mailing list a long time ago, shocked that GOTO's existed and proposed all sorts of lamebrained approaches just to avoid a clean usage of GOTO like this(shamelessly stolen from one of Robert Love's responses):

      do A
      if (error)
      goto out_a;
      do B
      if (error)
      goto out_b;
      do C
      if (error)
      goto out_c;
      goto out;
      out_c:
      undo C
      out_b:
      undo B:
      out_a:
      undo A
      out:
      return ret;

      Easy to read, provides clean stack unwinding, avoids blowing out your cache and only branches on error conditions.

      Linus was actually nice to this kid, which surprised me because he deserved all the vitriol he got and more.

      One the other hand, that a newbie was actually reading Linux source code was pretty amazing to me. But going on the mailing list and chastising experienced kernel programmers was pretty funny.

      Djikstra never gave his paper the title "GOTO's considered harmful", I think it was Wirth acting as editor and who is someone you can ignore safely.

      His paper was talking about GOTO's that can bounce all over the place, something essentially impossible in C where GOTO's are local in the function(ignoring longjmp). The paper was published several years before C was developed making his paper irrelevant to C style GOTO's.

      I think I used GOTO once, in a virtual machine project that ran bytecode for a educational language that teaches parallel programming concepts.

    10. Re:But... by vilanye · · Score: 5, Informative

      Here is the mailing list thread: https://lkml.org/lkml/2003/1/12/126 Good reading

    11. Re:But... by jon3k · · Score: 1

      There's absolutely no way it was "the only possible way of accomplishing something"

    12. Re:But... by Anonymous Coward · · Score: 0

      Intercal has "comefrom"!

    13. Re:But... by fisted · · Score: 0

      > Give me a PHP programmer and I can tell you he isn't worth anything
      FTFY

    14. Re: But... by flimflammer · · Score: 1

      Then, "the only way to accomplish something without avoiding goto with lamebrained alternatives just for the sake of avoiding goto"

    15. Re:But... by Anonymous Coward · · Score: 0

      Use monads and flatMap that shit.

    16. Re:But... by Mister+Mudge · · Score: 1

      > Give me a PHP programmer and I can tell you he isn't worth anything

      FTFY

      Show me a programmer as snottily critical of a language as this and I'll show you a programmer who hasn't been one for very long.

      --
      Mudge

      In theory, theory and practice are the same.
      In practice, they're not.

    17. Re:But... by Mister+Mudge · · Score: 1

      Literally the only valid use of goto is for error handling, and that is covered by exceptions.

      I use goto in C all the time to break out of loops and jump to a cleanup function at the end of the code. Of course C doesn't have exceptions and nobody compiles PHP to the metal AFAIK, so I think you're right.

      Look up setjmp()/longjmp() and tell us again if you still think C needs GOTO in place of exception handling.

      OTOH, using GOTO so that a procedure has limited nesting and only a single exit point is far preferable to having one with super-deep/complicated nesting and/or lots of different exit points (something a lot of PHP programmers seem prone to).

      --
      Mudge

      In theory, theory and practice are the same.
      In practice, they're not.

    18. Re:But... by Spy+Handler · · Score: 0

      Give me a PHP programmer and I can tell you he isn't worth anything

      Zuckerberg is worth billions. PHP was mentioned by name several times in the Facebook movie.

      When was the last time you heard Python/Perl/Ruby/C++ mentioned in a movie?

    19. Re:But... by Anonymous Coward · · Score: 0

      Give me a PHP programmer and I can tell you he isn't worth anything

      Zuckerberg is worth billions. PHP was mentioned by name several times in the Facebook movie.

      Sorry, but odds are in GP favor.

    20. Re:But... by sg_oneill · · Score: 1

      There is no circumstance where a Goto is the "only possible way". I've been coding for 20+ years, and the last time I used a goto was when as a teenager I graduated from BASIC to Pascal.

      Literally, computer science style, *all* possible uses with one exception can be replaced.

      And that one exception will never occur in PHP code, as its related to system level assembly programming where the CPUs jump-with-return instructions are not appropriate to the task at hand.

      --
      Excuse the Unicode crap in my posts. That's an apostrophe, and slashdot is busted.
    21. Re: But... by sg_oneill · · Score: 1

      By "lamebrained" read "actually knows how to code".

      Name JUST ONE circumstance where using a Goto in a higher level language isn't the wrong choice.

      Just one.

      --
      Excuse the Unicode crap in my posts. That's an apostrophe, and slashdot is busted.
    22. Re: But... by smellotron · · Score: 1

      the only way to accomplish something without avoiding goto with lamebrained alternatives just for the sake of avoiding goto

      You may as well omit that long-ass conditional and just say "the simplest way to accomplish something."

    23. Re: But... by Anonymous Coward · · Score: 0

      This thread has already discussed one.

    24. Re:But... by Anonymous Coward · · Score: 0

      Personally I'd love to see better than 99% of you fat fucks right in front of the person against whom you're leveling the criticism. I'd kick your fucking teeth out.

      Now that's a classy, mature, and tactful comeback!

    25. Re:But... by lxs · · Score: 1

      Zuck may own billions, but that doesn't really say anything about his worth as a person.

    26. Re:But... by Anonymous Coward · · Score: 0

      What about a GUI interface using Visual Basic to track the IP address?

      http://youtu.be/hkDD03yeLnU

    27. Re:But... by dolmen.fr · · Score: 1

      AFAIK the Linux kernel is not written in PHP...

    28. Re:But... by Anonymous Coward · · Score: 0

      20+ years and you still have learned so little. I feel bad for you.

    29. Re:But... by Anonymous Coward · · Score: 0

      Given that Linus isn't exactly known for being polite when faced with stupidity he was surprisingly kind.

    30. Re:But... by tibman · · Score: 1

      PHP derived from C, the language the linux kernel is written in.

      --
      http://soylentnews.org/~tibman
    31. Re:But... by tibman · · Score: 1

      lol, because you can't know more than one language, right?

      --
      http://soylentnews.org/~tibman
    32. Re:But... by Anonymous Coward · · Score: 0

      AFAIK the OP was asking for legitimate uses for GOTO and since there is no legitimate usage for PHP, the examples had to be in a different language

    33. Re:But... by Anonymous Coward · · Score: 0

      OP meant what is he worth as a programmer, and Zuckerberg is a fairly accomplished programmer. Like Bill Gates, though, he's more famous for his business prowess than technical ability.

    34. Re:But... by Anonymous Coward · · Score: 0

      yeah, monads are an ugly hack only used by the anal-retentive types.

    35. Re:But... by Anonymous Coward · · Score: 0

      Using PHP is grounds for firing and not being allowed to touch a computer ever again.

    36. Re: But... by Anonymous Coward · · Score: 0

      These are all gotos:

      function/method calls
      switch
      if/else
      break
      continue
      for
      while

    37. Re:But... by Anonymous Coward · · Score: 0

      This is error-handling isn't it? OO-languages consider using EXCEPTIONS in such cases. C is not an OO-lanuage and PHP. OS Kernal is no surprising and web-site is. PHP can't provide such throughput that C can. And it's not required from web-site but from OS Kernal it is.

    38. Re:But... by Anonymous Coward · · Score: 0

      Even in software today, I'm willing to bet even the most ardent anti-GOT zealot has used a GOTO -- and recently at that -- cleverly disguised as a break or return statement.

      break and return are not goto.

    39. Re:But... by Anonymous Coward · · Score: 0

      Zuckerberg is worth billions.

      No, Zuckerberg is a worthless turd.

    40. Re:But... by Anonymous Coward · · Score: 0

      There is no circumstance where a Goto is the "only possible way".

      Durrrrr But there are cases where it is the best way.

    41. Re:But... by Anonymous Coward · · Score: 0

      Since when is not using languages that are neither consistent, correct, orthogonal or regular "snottily critical"?

      Why is it that it is PHP "programmers" that dismiss a proper foundation as being snooty or elite?

      Could it be that they are uneducated and resent educated people?

      PHP: By amateurs, for amateurs. Your feelings of inadequacy that translate into anger against professionals may make you not believe that, but it is fact. Deal with it.

  2. Facebook? by Anonymous Coward · · Score: 0, Insightful

    People still use PHP outside of Facebook? And, honestly, they're not even really using it with their cross compilers.

    1. Re:Facebook? by Literaphile · · Score: 5, Interesting

      This just in, people still use the most popular programming language on the web, the size of which makes all other web programming languages niche choices by comparison.

    2. Re:Facebook? by Grishnakh · · Score: 5, Insightful

      Honestly, I don't understand what all the complaining is about. It just seems like a lot of language snobbery to me. I used PHP on my small website because every cheap web host out there supports it, there's tons of example code, and it's easy to learn if you have a C/C++ background. It seems to work just fine. Is it suitable for a gigantic website like Facebook? I have no idea really, and I don't care, just like I don't care that bash shell scripts probably aren't suitable for writing, for instance, a full-featured application like a spreadsheet or a video editor, as shell scripts work quite well for the things I do use them for.

    3. Re:Facebook? by Anonymous Coward · · Score: 0

      Yes, on Wikipedia.

    4. Re:Facebook? by SJHillman · · Score: 2, Informative

      Similar questions:
      People still use automobiles outside of Detroit?
      People still eat food outside of McDonalds?
      People still have sex outside of brothels?
      People still say stupid shit outside of anonymous Slashdot comments?

    5. Re:Facebook? by dkleinsc · · Score: 5, Insightful

      Honestly, I don't understand what all the complaining is about. It just seems like a lot of language snobbery to me.

      As someone who works with PHP every working day: It's a language that wasn't designed, it was congealed. Its lack of design is very evident as soon as you start trying to build anything interesting with it. It was something that was created to solve a short-term problem for one guy, and more-or-less accidentally grew into what it is today. What structures it does have are poor attempts at imitating other languages.

      Some examples of what went wrong:
      - Arrays and hashes are the same data structure, for no readily apparent reason. Also, the simplest way of using that data structure is "array(a,b,c,...)", not "[a,b,c, ...]" like everyone else.
      - All variables start with $, in imitation of Perl, but don't use the @ or % prefixes the way Perl does, instead just pretending everything's a scalar even though it's not.
      - For a long time, OOP was an afterthought.
      - Unlike other scripting languages like Python, Ruby, and Perl, PHP can't figure out which files to include for you when you reference something outside of the current file. Instead, it offers a global facility called an "autoloader" that allows you to write your own code to tell it how to find it, which completely breaks when multiple libraries have competing autoloaders trying to pick up two different classes with the same name.
      - Library functions display no consistency whatsoever. Some are camelCase, some are under_scored. Some search functions put the needle before the haystack, some the other way around.
      - Some operators are funky: Values can be equal without being the same thing, for example.
      - A significant number of errors, instead of generating exceptions that can be caught and handled, generate fatal errors, which crash your application no matter what. By comparison, Perl, Python, Ruby, and Java allow you to handle almost any error.

      I could go on, but the point is there's real reasons for hating PHP.

      --
      I am officially gone from /. Long live http://www.soylentnews.com/
    6. Re:Facebook? by TopSpin · · Score: 1

      Is it suitable for a gigantic website like Facebook?

      Yes. Facebook is actually implemented in PHP. At one point they used a compiler to compile PHP directly to machine code. Today they have an alternative to Zend called the HipHop Virtual Machine (HHVM.)

      --
      Lurking at the bottom of the gravity well, getting old
    7. Re:Facebook? by Anonymous Coward · · Score: 1

      It's also harder to learn how to do things WELL in PHP. PHP is full of gotchas that complicate programs and catch even veteran programmers, ending up as bugs.

      It is a bad language as far as languages go. It's ONLY upside, in today's world, is it's ubiquity, which is not really much of a bragging point.

      Node, or Python/ruby with a good framework (which unsurprisingly, the php frameworks are now emulating), is a better choice for someone starting a new project, hands down.

    8. Re:Facebook? by dgatwood · · Score: 2

      ... I don't care that bash shell scripts probably aren't suitable for writing, for instance, a full-featured application like a spreadsheet ...

      I so know what my next shell script should be.

      --

      Check out my sci-fi/humor trilogy at PatriotsBooks.

    9. Re:Facebook? by johnkoer · · Score: 4, Interesting

      Someone did go on, and on, and on, on this topic. Interesting read that makes never want to go near PHP again:

      http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/

    10. Re:Facebook? by Grishnakh · · Score: 1

      How many of these are still problems now, as opposed to in earlier versions of the language/interpreter? Perl is another language that wasn't all that well designed at first, but was added onto later as it grew into popularity and was used in roles that were unthinkable in its early days.

      It is pretty obvious that PHP started out small and grew into its present form, which can be seen with the inconsistency with library function names; obviously they didn't want to break compatibility arbitrarily so they stuck with the old names, but there's several functions that have been deprecated, such as the old MySQL interface library.

      I'm not saying PHP is the greatest language ever (or even a great language), but it seems to get the job done for smaller sites, and there don't seem to be many really good alternatives that are well-supported, or so easy to embed into HTML like PHP does. It'd be nice if they'd fix some of these issues that seem to mostly stem from legacy issues, but I guess that conflicts with the goal of backwards compatibility so that's probably why that isn't done so quickly.

    11. Re:Facebook? by Crudely_Indecent · · Score: 1

      PHP Array Short Syntax

      There are answers to most of your gripes....except search function needle/haystack ordering. That one bugs me too, as I can never remember which function uses which order.

      --


      "Lame" - Galaxar
    12. Re:Facebook? by Anonymous Coward · · Score: 0

      The choice to use PHP is made with a bias of picking the most popular language. If a task is suited to PHP, it's equally suited to a number of other languages.

      I hate PHP. I've been forced to use it (it's probably my primary language) and it's burned me time and again. I wouldn't call that snobbery.

      I also wouldn't say the OP is a snob. I, too, am surprised that people are still picking that language solely because it's the most popular.

    13. Re:Facebook? by Literaphile · · Score: 1
      As someone who also works with PHP every working day, I'd just like to respond to your examples of "what went wrong":

      - Arrays and hashes are the same data structure, for no readily apparent reason. Also, the simplest way of using that data structure is "array(a,b,c,...)", not "[a,b,c, ...]" like everyone else.

      So? Does this gripe have any practical implications? Or is it just a whine for a whine's sake? Also, as of PHP 5.4 (which has been March 2012 BTW), you CAN use the [a,b,c] syntax to create arrays.

      - All variables start with $, in imitation of Perl, but don't use the @ or % prefixes the way Perl does, instead just pretending everything's a scalar even though it's not.

      Again - so what? You presumably learned how PHP variables work, so you're doing OK. Don't worry about Perl when you're using PHP.

      - For a long time, OOP was an afterthought.

      But it's not an afterthought now. Or are you still using PHP 4?

      - Unlike other scripting languages like Python, Ruby, and Perl, PHP can't figure out which files to include for you when you reference something outside of the current file. Instead, it offers a global facility called an "autoloader" that allows you to write your own code to tell it how to find it, which completely breaks when multiple libraries have competing autoloaders trying to pick up two different classes with the same name.

      Again, don't worry about other languages. You're using PHP. And, more importantly, why are you using libraries with their own autoloaders?

      - Library functions display no consistency whatsoever. Some are camelCase, some are under_scored. Some search functions put the needle before the haystack, some the other way around.

      I agree that this is annoying. But is it a show-stopper?

      - Some operators are funky: Values can be equal without being the same thing, for example.

      Once again: so what? It's not random behavior. Learn how this stuff works and then move on with your life.

      - A significant number of errors, instead of generating exceptions that can be caught and handled, generate fatal errors, which crash your application no matter what. By comparison, Perl, Python, Ruby, and Java allow you to handle almost any error.

      What do you mean by "handle"? If you mean catch and log, then PHP allows you to catch all errors, including fatal ones (see register_shutdown_function for example). If you mean "recover from", I would suggest that attempting to "recover" from a fatal error is a very bad idea. A fatal error means that something is seriously wrong with your application - the "recovery" should be fixing it, not pushing it under the rug.

      Your points just touch on the same old, tired "but it's not like $randomLanguageName and therefore it's bad!" If you constantly compare PHP - or any language - to other languages than I'm afraid you'll have a long road to hoe. If PHP is your chosen tool - as it is for me - learn it inside and out and stop comparing it to other languages.

    14. Re:Facebook? by Anonymous Coward · · Score: 0

      I think Facebook deeply regrets using this shitty language. That one decision has cost them 10's of millions of dollars and lots of time.

    15. Re:Facebook? by HornWumpus · · Score: 1

      Better then 'Moose knuckle' (camelToe's fat ugly sister).

      --
      John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
    16. Re:Facebook? by Anonymous Coward · · Score: 0

      Create your own.

      function my_blah(stuff)
      {
                    call blah(stuff);
      }

    17. Re:Facebook? by Anonymous Coward · · Score: 0

      I feel the same way. Yes, it's easy to find laundry lists of everything people hate about PHP, and yes, it's quirky and not well designed. But I've been building lightweight webapps with it for years and they've worked just fine with minimal maintenance, and none of the problems folks drone on about are showstoppers, not to me anyhow. "Oh gosh, I have to look up the order of the arguments for array_key_exists() again, kill me now ..."

    18. Re:Facebook? by complete+loony · · Score: 2

      Here's a much more useful and accurate review of PHP.

      --
      09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
    19. Re:Facebook? by Anonymous Coward · · Score: 0
    20. Re:Facebook? by Nerdfest · · Score: 1

      The sad part is that both of the two big languages for web development are like this (with JavaScript) being the other one. When you need to write software that's reasonably maintainable, flexible and secure, having a language that's consistent and predictable is pretty much required.

    21. Re:Facebook? by Patman64 · · Score: 2
    22. Re:Facebook? by Anonymous Coward · · Score: 0

      And pragmatists opposite view:

      - PHP is easy to deploy, usable on almost any host.
      - PHP code can, and is clean, when written by a professional. Like any code.
      - PHP code is easy to maintain when written by a professional.
      - PHP is very, very fast. Much faster than Python or Ruby. Not much else fits into web world.
      - PHP is inconsistent only on some parts. Nowadays you can write most of the stuff on top of PHP 5.x's object oriented classes (instead of old_procedural_funcs()), which are all consistently named, take parameters in consistent order, etc. But this usually doesn't matter to PHP flamers, for some reasons. PHP sucks, you know.
      - PHP is also very fast to develop and nowadays offers more than excellent, safe API's to get rid of old-world security problems like SQL injections (PDO and prepared queries, hello).
      - PHP has by far the best XML/XSLT- classes and tools, for those who create use and create real UI's instead of these messy string parsers ;-)

      In the end, what PHP is supposed to do, is to execute a page as fast as possible, and then die off. And it's very good at it.

    23. Re:Facebook? by MortenMW · · Score: 1

      Its pretty interesting reading. However he used a carpenter analogy which renders any argument invalid. If he had used a car analogy I would have believed everything he's written.

    24. Re:Facebook? by Anonymous Coward · · Score: 0

      "- PHP is easy to deploy, usable on almost any host."

      So is everything else, and if it isn't it's trivial to find equally priced equal quality hosts that do make it easy.

      "- PHP code can, and is clean, when written by a professional. Like any code.
      - PHP code is easy to maintain when written by a professional."

      Except PHP is mostly used by amateurs, that's kind of part of the problem. The other part of the problem is that this isn't true when compared to other languages. Python forces proper indentation by default, C# and Java enforce better code architecture by default. The quality of bad code an amateur can write in C#, Java, Ruby, and Python is inherently less bad than in PHP where it's possible to write code in a much worse way and have it still execute.

      "- PHP is very, very fast. Much faster than Python or Ruby. Not much else fits into web world."

      This one is just an outright lie. PHP is brutally slow compared to Java, .NET and C#, and C++, and it isn't any faster than Python. Not sure about Ruby though.

      "- PHP is inconsistent only on some parts."

      Which is much worse than being inconsistent on few to no parts as with other languages.

      "Nowadays you can write most of the stuff on top of PHP 5.x's object oriented classes"

      You can also not, which again, is kind of the problem. Especially when most tutorials including those on PHP's own site don't use them.

      "- PHP is also very fast to develop and nowadays offers more than excellent, safe API's to get rid of old-world security problems like SQL injections (PDO and prepared queries, hello)."

      But still slower to develop with than competing languages and the competing languages have had good APIs for much longer meaning they're much more mature, much more tried and tested, and much more complete. Most PHP documentation and tutorials on the web for database access still use unsafe methods, hence most amateurs are still using those old unsafe methods.

      "- PHP has by far the best XML/XSLT- classes and tools"

      False. They don't even come close to .NET's tools for example, especially if you factor in things like LINQ to XML.

      This is of course all before you factor in PHP's problems - rather glaring ones like no true threading support for example. This is improving slowly, but is still an embarrassment.

      So there you have it, the things you list either aren't true are irrelevant. Given that these seem to be the best defences of PHP anyone can dig up and they're false or irrelevant it kind of highlights the problem. It's not that PHP doesn't work, it's not that you can't do things with it and make them work, it's just that other languages can do everything PHP can and better, which is again, kind of the point.

    25. Re:Facebook? by gfxguy · · Score: 1

      Agree... the snobby sophomoric programmers come out and jump on the bandwagon against what is probably the most widely used language to develop websites with, and claim it's not a good language to develop websites in... it's laughable. It's surely not my favorite language, but it does what it needs to do, it does it relatively simply (that seems to be their problem - if it's easy it can't be good), is well supported. When I switched my website scripting from PERL to PHP it was fantastic; now I use python, and I like python a lot better, but I have no problem maintaining my older code, or helping the other developers here with their PHP projects. My hosting service only supports PHP, too, although I don't do a whole lot on my personal site.

      We're a media company and some of our internal sites are quite complicated, and yet were done quite easily with PHP, despite my preference for other languages. Good programmers, here - better than me; the code is clean and easy to follow.

      --
      Stupid sexy Flanders.
    26. Re:Facebook? by gfxguy · · Score: 1

      Agreed. Are there any languages that nobody complains about, anyway?

      --
      Stupid sexy Flanders.
    27. Re:Facebook? by Anonymous Coward · · Score: 0

      It amazes me how many of you fucking AOL "me toos" post this vapid piece of crap. Just look in the thread at all the links, now stop for a moment and consider what that makes you. You are on par with some sort of lame parrot. Too stupid to handle a simple language, but always ready to feel superior by knocking something that you are not intelligent enough to utilize yourself.

      Even worse, you will no doubt be here along with all of the other lamers the next time the subject comes up. With your little url in your pocket, breathlessly posting it so you too can be one of the cool kids, bashing what you cannot master. Congratulations.

    28. Re:Facebook? by dkleinsc · · Score: 1

      Also, the simplest way of using that data structure is "array(a,b,c,...)", not "[a,b,c, ...]" like everyone else.

      So? Does this gripe have any practical implications?

      Yes there is: without syntax highlighting, I can't tell at a glance whether I'm looking at a data structure or a function call, I have to read it more carefully.

      - All variables start with $, in imitation of Perl, but don't use the @ or % prefixes the way Perl does, instead just pretending everything's a scalar even though it's not.

      Again - so what? You presumably learned how PHP variables work, so you're doing OK. Don't worry about Perl when you're using PHP.

      It's harder for me to tell at a glance whether I'm dealing with a numeric array, an associative array (what the rest of the world calls a hash), an object, or a scalar value (e.g. a string or integer). To make matters even more challenging, the culture of the PHP community tries to make it so you can hand it any of those and it will try to convert it, sometimes correctly and sometimes not. If you're going to use type indication symbols, they actually need to indicate a type.

      Instead, it offers a global facility called an "autoloader" that allows you to write your own code to tell it how to find it, which completely breaks when multiple libraries have competing autoloaders trying to pick up two different classes with the same name.

      And, more importantly, why are you using libraries with their own autoloaders?

      Because most of the major frameworks and libraries have them. For example, SwiftMailer is a popular way of sending out email, and it has its own autoloader so that you can easily reference its classes inside your code.

      A fatal error means that something is seriously wrong with your application - the "recovery" should be fixing it, not pushing it under the rug.

      Or sometimes not: For example, I tracked down a fatal error that was occurring because a default argument (an array) was being manipulated inside of a function. It turned out that what PHP was doing was treating that default argument as a static value the first time, and the second time the function was called it was crashing because it was trying to access the first run's value on the stack. I was able to work around it, but that's not a bug in the program, that's a bug in the PHP interpreter.

      The comparison to other languages is to point out that there are viable alternatives that don't have the problems PHP does. I can compare and contrast Java and Python too (both languages I like), even though they make some very different kinds of choices, and don't have the same reaction of "Java is wrong" or "Python is wrong", because they're both right in different ways: Python creates very compact and powerful code, Java creates very well-defined and explicit code.

      Also, PHP isn't my chosen tool. It's my employer's chosen tool. I can wrangle it to do what I want it to do, but that's different from other languages that I actually enjoy writing in.

      --
      I am officially gone from /. Long live http://www.soylentnews.com/
    29. Re:Facebook? by vilanye · · Score: 1

      Honestly, I don't understand what all the complaining is about. It just seems like a lot of language snobbery to me.

      Ah yes, the mark of an amateur. Dismissing concerns about good language design principles as snobbery or elitism.

      Only in the amateur world of PHP and in the GOP are things like education considered elitism and should be shunned.

      PHP is never the right answer as folks from Facebook learned the hard way. http://www.quora.com/Quora-Infrastructure/Why-did-Quora-choose-Python-for-its-development/answer/Adam-DAngelo

    30. Re:Facebook? by tibman · · Score: 1

      Or sometimes not: For example, I tracked down a fatal error that was occurring because a default argument (an array) was being manipulated inside of a function. It turned out that what PHP was doing was treating that default argument as a static value the first time, and the second time the function was called it was crashing because it was trying to access the first run's value on the stack. I was able to work around it, but that's not a bug in the program, that's a bug in the PHP interpreter.

      Wouldn't the value change of the array not matter because it goes out of scope? Every time the function runs it would be default again.

      --
      http://soylentnews.org/~tibman
    31. Re:Facebook? by jtnix · · Score: 1

      +1 to this.

      --
      She blinded me with science, she tricked me with technology. ~ Thomas Dolby
    32. Re:Facebook? by dkleinsc · · Score: 1

      That's what you might think, but (in at least this version of PHP) this crashed the application (apologies if /. screws up the formatting):

      class Foo {
              public function bar($arg=array()) {
                      $arg[] = 'bar'; ...
              }
      }

      While this worked fine:
      class Foo {
              public function bar($arg=null) {
                      if ($arg === null) {
                                $arg = array();
                      }
                      $arg[] = 'bar'; ...
              }
      }

      I definitely read that as a bug in the interpreter, not a bug in the application.

      --
      I am officially gone from /. Long live http://www.soylentnews.com/
    33. Re:Facebook? by Anonymous Coward · · Score: 0

      . A fatal error means that something is seriously wrong with your application - the "recovery" should be fixing it, not pushing it under the rug.

      Here is are my application response to a failed try block : alert_sysop();wait(delay);delay=delay*2;the_function_that_is_the_try_block();
      This is called exponential back-off. This pattern is use to add resiliency to an application.

    34. Re:Facebook? by Anonymous Coward · · Score: 0

      Arrays and hashes are the same data structure, for no readily apparent reason.

      So? Does this gripe have any practical implications? Or is it just a whine for a whine's sake?

      If you use a string that happens to look like an integer as a hash key, and then later iterate over the keys of the hash, you get an actual integer out rather than the original string, with all the weird comparison behaviour that implies.

      A significant number of errors, instead of generating exceptions that can be caught and handled, generate fatal errors, which crash your application no matter what.

      What do you mean by "handle"? If you mean catch and log, then PHP allows you to catch all errors, including fatal ones (see register_shutdown_function for example).

      But you can't get a backtrace that way.

      If you mean "recover from", I would suggest that attempting to "recover" from a fatal error is a very bad idea.

      Only if the language has a sensible classification of fatal/nonfatal errors in the first place.

    35. Re:Facebook? by Anonymous Coward · · Score: 0

      It's a language that wasn't designed, it was excreted

      FTFY

  3. Re:One page book by jellomizer · · Score: 1

    Ok you hate PHP. But how many other Popular alternatives are out there.
    JSP Oracle is the bad guy right.
    ASP Microsoft is the bad guy right.
    Perl The 1990's called and they want their programming back.
    Ruby on Rails, good alternative however it will be hard to find replacement programmers.
    Python, Python is my favorite language, however it isn't that good for web.

    --
    If something is so important that you feel the need to post it on the internet... It probably isn't that important.
  4. Re:One page book by Anonymous Coward · · Score: 0

    Well.. if not PHP.. then what? And don't tell me C# or Java please.

  5. Re:One page book by kthreadd · · Score: 2

    There is a nice looking framework for Scala called Play. I think that could be a good alternative. http://www.playframework.com/

  6. Re:One page book by schneidafunk · · Score: 5, Insightful

    Get over your bias, and use whatever programming language needed for the job. I'll take a job doing PHP, perl, ruby, python, java, even actionscript. If I'm paid well, I'll learn it. My resume gives me the flexibility to get jobs using different languages, precisely because I'm not biased and have worked professionally in most of them.

    --
    Some people die at 25 and aren't buried until 75. -Benjamin Franklin
  7. Re:One page book by VortexCortex · · Score: 0

    If you're using PHP and you've got something against Perl, you're a fucking idiot.

  8. Haters gonna hate by Bigbutt · · Score: 1

    Honestly. If you can't offer a better solution, stop bitching about it. I and others have asked for something other than PHP for website programming over the past few articles and all I hear is bitching about how bad PHP is.

    I use perl for sysadmin scripting stuff. I like perl. For sysadmin scripting stuff. It's a fricking pain in the ass to set up and maintain for the creation of web pages though.

    [John]

    --
    Shit better not happen!
    1. Re: Haters gonna hate by Anonymous Coward · · Score: 0

      Since when? Have you tried Mojolicious or Dancer? Catalyst?

    2. Re: Haters gonna hate by Bigbutt · · Score: 1

      Never heard of them. Are they better languages than PHP for creating websites?

      (Actually I assume they're perl package managers of some sort but it's hard to parse from your answer.)

      [John]

      --
      Shit better not happen!
    3. Re:Haters gonna hate by Anonymous Coward · · Score: 0

      I'd understand "If you can't offer a better solution, stop bitching about it." if there really weren't any alternatives, but there are *dozens* of web languages out there and *all* of them are better than PHP. It really can't be defended, and there is no reason whatsoever to start new projects in PHP.

    4. Re: Haters gonna hate by Bigbutt · · Score: 1

      Ahhh, Web Application Frameworks. Not a language but a way of getting Perl to work writing websites. I may have to poke around and check it out but I do want to say that I'm more interested in writing my own stuff than using a framework to mask the work. Most of what I do doesn't require the excess of any of the available libraries. Besides I think frameworks hide the stuff you should know in order to write code well.

      Thanks for the pointers though. I will poke around at them.

      [John]

      --
      Shit better not happen!
    5. Re:Haters gonna hate by Anonymous Coward · · Score: 0

      > It really can't be defended, and there is no reason whatsoever to start new projects in PHP.

      Except that it's currently quite easy to find developers who know PHP. That's not a value judgment, I'm just pointing out that's the actual situation "on the ground."

    6. Re:Haters gonna hate by Xest · · Score: 1

      Erm, people have offered better solutions, that's kind of why they bitch.

      I'm very much a best tool for the job type of person but the inherent problem with PHP is that it's really not the best tool for any job any more.

      If you want high quality secure scalable web development then you need something like Java, .NET, or C++ if you actually know what you're doing with it because catching errors at compile time is always better than (possibly not) catching them at runtime. Most issues with type conversion must be explicitly dealt with before you can even run the application which means your application basically has to be more error free before it can be deployed and hence become an attack vector on a server.

      If you really want dynamic language support (and .NET's DLR wont cut it, because for example, you want to host on a non-Windows or non-Mono platform) then there's Python, or node.js if that's your thing.

      For I think every single use case there is now something better than PHP, and that's precisely why so many people slate it - because it's a bad language and there's literally no reason to use it anymore. Even the fact it used to be the only offering on cheap webhosting seems to have largely gone out the window now given that hosts always seem to support alternatives to PHP and if yours doesn't you can just switch hosting provider to one that does without any financial or hosting quality cost resulting from that.

      The only reason people stick with PHP is either because they're lazy, because it's all they know, and they can't be bothered to move to anything else or because they're too incompetent to understand why PHP is bad (despite the reasons being documented aplenty across the web). "I'm lazy" and "I'm incompetent" is not a legitimate defence of any language though.

    7. Re:Haters gonna hate by Xest · · Score: 1

      Most of them don't "know" PHP though, they can hack things together in it, but they're blissfully unaware of the hundreds of pitfalls in it that they fall into time and time again.

      The problem is that the people who genuinely know PHP, and know those pitfalls well enough to avoid them consistently also know it well enough to know that there are better alternative languages to use instead.

    8. Re: Haters gonna hate by Anonymous Coward · · Score: 0

      > Ahhh, Web Application Frameworks. Not a language but a way of getting Perl to work writing websites.

      Yep. So, if you want to avoid PHP, you have to learn dozens of frameworks instead of a single language.

      It's like the Esperanto of web development. Imperfect but practical, lots of people bitch about it and suggest alternatives, none of which ever gain a significant following.

    9. Re:Haters gonna hate by Anonymous Coward · · Score: 0

      Yes, but so many here are saying that programmers who have a clue refuse to use PHP, so by extension the very people who "know" PHP don't use it and can't be hired for those positions. :)

    10. Re: Haters gonna hate by Anonymous Coward · · Score: 0

      The framework hide the stuff that require an high priced consultant. :)

    11. Re: Haters gonna hate by Anonymous Coward · · Score: 0

      I may have to poke around and check it out but I do want to say that I'm more interested in writing my own stuff than using a framework to mask the work.

      If you want to write your own stuff it's just as easy in Perl as it is in PHP.

    12. Re: Haters gonna hate by Anonymous Coward · · Score: 0

      Yep. So, if you want to avoid PHP, you have to learn dozens of frameworks instead of a single language.

      PHP doesn't have some sort of magic that lets you avoid frameworks more easily than other languages. And if you do want to use a framework, either in PHP or some other language, you only have to learn the one you're using, not "dozens".

  9. Re:One page book by lagi · · Score: 1

    Scala and Go would be good alternatives.
    Lua + LuaJIT is can be interesting too.

  10. GOTO can be useful by Anonymous Coward · · Score: 1

    GOTOs can be a useful language feature, improving program speed, size and code clearness, but only when used in a sensible way by a comparably sensible programmer.

    Linus Torvalds: http://kerneltrap.org/node/553 (mirror at the Wayback Machine)
    Steve McConnell: http://www.stevemcconnell.com/ccgoto.htm

  11. Re:One page book by Anonymous Coward · · Score: 0

    Python can be pretty good for the web. If mod_python development had been more active it probably could have approached the market penetration of mod_php, because the reason why PHP got popular in the first place is because shared hosting providers could just build it into apache and forget about it, without having to babysit people's application servers chewing up ram while idle, and falling over and crashing every 30 minutes when not.

  12. Re:But... Spiders on drugs by Aguazul2 · · Score: 1

    So what you're saying is that PHP is better than COBOL -- hmmm. PHP reminds me of those spider webs made by spiders on different drugs. PHP is like COBOL reimplemented under the influence of which drug, I wonder?

  13. Re:One page book by OakDragon · · Score: 3, Informative

    I swear, Slashdot only posts PHP stories to troll for negative comments...

  14. Languages in job postings are misnomers by Anonymous Coward · · Score: 1

    If a job advertises they want PHP in pretty short order you are digging around their Perl code. If a job advertises they want .NET pretty soon you are trying to fix MFC code. I've seen this all throughout my career in programming most times these languages that seem easy or are popular...well usually its just a trap. This separates the men from the boys pretty quickly IMO. Cherry-picking is not for professionals and never has been. In the real world you learn this rather quickly if you intend to survive as a programmer.

    1. Re:Languages in job postings are misnomers by kcmastrpc · · Score: 2

      i was hired primarily as a php/backend dev. what am i doing? a lot of devops, javascript, and mobile app programming. ah well, at least it makes my resume look fatter (and in turn my paycheck).

    2. Re:Languages in job postings are misnomers by Xest · · Score: 1

      I don't think that's a bad thing though. Personally I feel a job where I work with multiple languages (and technology stacks) is far more interesting than just working with the same language and framework day in day out for all eternity.

  15. Re:One page book by Anonymous Coward · · Score: 0

    Also don't tell me about c, c++, go, python, erlang, scala, ruby, groovy, or javascript! LALALALA

  16. Re:One page book by Lunix+Nutcase · · Score: 1

    How many web hosts support it? That is why PHP still lives on.

  17. Re:One page book by narcc · · Score: 2

    Yeah, only idiots use PHP -- that's why it's only used by 80% of the web.

    Language snobbery benefits no one. Unless you're Chuck Moore, it also makes you look like an idiot who can't form their own opinions.

  18. Re:One page book by jon3k · · Score: 2

    Why isn't python "good for the web" ?

  19. Re:One page book by kthreadd · · Score: 1

    I'm not sure but it should run as long as you have Java. Scala compiles down to Java byte code.

  20. Re:One page book by Crudely_Indecent · · Score: 1

    Yup, as stupid as the Facebook bank balance.

    --


    "Lame" - Galaxar
  21. Re:One page book by Anonymous Coward · · Score: 0

    My resume gives me the flexibility to get jobs using different languages, precisely because I'm not biased and have worked professionally in most of them.

    Average HR Drone: "So, according to your resume you have 10 years of experience in C++, PHP, perl, ruby, python, java, and JavaScript. Well, you look wonderful for a man of no less than 93 years."

  22. Re:One page book by Crudely_Indecent · · Score: 1

    Dart might be interesting, when they stop changing everything...all the time.

    --


    "Lame" - Galaxar
  23. The list of absuridities just never ends... by js_sebastian · · Score: 4, Insightful

    Honestly, I don't understand what all the complaining is about. It just seems like a lot of language snobbery to me.

    As someone who works with PHP every working day: It's a language that wasn't designed, it was congealed. Its lack of design is very evident as soon as you start trying to build anything interesting with it. It was something that was created to solve a short-term problem for one guy, and more-or-less accidentally grew into what it is today. What structures it does have are poor attempts at imitating other languages.

    Some examples of what went wrong: - Arrays and hashes are the same data structure, for no readily apparent reason. Also, the simplest way of using that data structure is "array(a,b,c,...)", not "[a,b,c, ...]" like everyone else. - All variables start with $, in imitation of Perl, but don't use the @ or % prefixes the way Perl does, instead just pretending everything's a scalar even though it's not. - For a long time, OOP was an afterthought. - Unlike other scripting languages like Python, Ruby, and Perl, PHP can't figure out which files to include for you when you reference something outside of the current file. Instead, it offers a global facility called an "autoloader" that allows you to write your own code to tell it how to find it, which completely breaks when multiple libraries have competing autoloaders trying to pick up two different classes with the same name. - Library functions display no consistency whatsoever. Some are camelCase, some are under_scored. Some search functions put the needle before the haystack, some the other way around. - Some operators are funky: Values can be equal without being the same thing, for example. - A significant number of errors, instead of generating exceptions that can be caught and handled, generate fatal errors, which crash your application no matter what. By comparison, Perl, Python, Ruby, and Java allow you to handle almost any error.

    I could go on, but the point is there's real reasons for hating PHP.

    You could go on forever. Every day that I work on PHP code, I discover another absuridity in this moronic language. Here is today's: take the php function intval, which is meant to parse a string and return an integer:

    - if you pass it an object, it emits an E_NOTICE and returns 1
    - if you pass it NULL, an array(), and perhaps other things, who knows, it returns 0
    - if you pass it a garbage string that is not a number it returns 0
    - if you pass it a number with garbage appended it returns the number (e.g., "123aaaa" returns 123)
    - if you pass it an overly large number it returns MAXINT

    Apparently it did not occur to the people designing this that using valid return values to indicate error conditions is not a good idea.

    Add to this, the fact that to know what a PHP API function REALLY does, you often have to read the comments under the API documentation page so you can find out of all the weirdnesses and special cases that the documentation does not mention.

    1. Re:The list of absuridities just never ends... by flimflammer · · Score: 1

      Then perhaps you should be using the companion function is_numeric() on the variable before attempting to convert it and then you wouldn't have this problem of vague return values!

    2. Re:The list of absuridities just never ends... by js_sebastian · · Score: 1

      Then perhaps you should be using the companion function is_numeric() on the variable before attempting to convert it and then you wouldn't have this problem of vague return values!

      Sure, there are always ways to get stuff to work despite the language and API's bad design, I myself get stuff done in PHP when I have to and hey, it beats writing machine code by punching holes in punch cards, but that does not mean the design is not bad and harmful to productive development... Unless you can find a rational reason why intval on an object should return 1, while intval on an array returns 0, and for so many other equally absurd decisions in the language, runtime and API. Try giving this a read:

      http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/

    3. Re:The list of absuridities just never ends... by Anonymous Coward · · Score: 0

      The better question is why are you passing an object or an array into intval? It says right in the docs that you shouldn't pass an object into that function.

    4. Re:The list of absuridities just never ends... by js_sebastian · · Score: 1

      The better question is why are you passing an object or an array into intval? It says right in the docs that you shouldn't pass an object into that function.

      If the php API made any sense, intval would either return NULL or raise an exception when you pass it a value that is not a valid number. You cannot use a number (0 or 1 or MAXINT, depending on the input) to indicate an error in a function that has a non-error output domain that includes all integer values.

  24. Re:One page book by Anonymous Coward · · Score: 0

    +1 Insightful

    There is never any good reason to use this broken by default "language".

    However it is a great telephone interview question:

    Interviewer: "Have you ever willingly used PHP or recommended it for any project"

    Brain-dead amatuer pretending to be a professional: "Why yes"

    *click*

    Brain-dead amatuer pretending to be a professional: "hello? hello?"

    Bulletproof way to remove the dregs from the list.

    Of course any mention of PHP in a resume earns its spot in the paper shredder.

    Either way, it helps narrow down your candidate list AND increases the quality of the candidate pool

  25. Python is just fine for the web by js_sebastian · · Score: 1

    Python, Python is my favorite language, however it isn't that good for web.

    The standard for making a python application interact with a web server is wsgi, you can run it inside apache with mod_wsgi or run it in a dedicated server such as uwsgi. Or if you want to go asynchronous you can try tornado.

  26. Re:One page book by vilanye · · Score: 1

    How is it hard to find replacement programmers for Ruby on Rails?

    If you hire actual programmers that have not only domain knowlege but understand computation they will pick up both Ruby and Rails quickly.

    Hire programmers, not programming language/framework end-users.

    When you are writing a web app you can use whatever you like and there are a lot of good options:

    Perl
    Python(with or without the various framworks)
    Ruby(with or without Rails or Sinatra) & JRuby
    Smalltalk
    Haskell
    Lisp & Clojure
    Ocaml
    Scala
    Erlang
    Javascript(node or Rhino, maybe a few others)
    even C++ has web frameworks if you really want C++
    I am sure I missed about a dozen of so viable candidates

    The only reason to use PHP is ignorance of the craft.

  27. Re:One page book by iamgnat · · Score: 2

    it also makes you look like an idiot who can't form their own opinions.

    So does using the "but everyone else is doing it" argument.

    I've used all kinds of languages for different purposes and the only thing I can say nice about PHP is that it is nearly as ubiquitous as Perl. Otherwise it is neither as capable or well thought out as it's competitors. My personal pet peeve is the inconsistent error handling (some functions just return true/false, some use NULL and false interchangeably, some write their error messages to STDERR, some to STDOUT, most give you no way to programmatically capture the error in a reasonable manner, and a few actually use the built exception functionality (though I still saw a handful that just used a generic exception with no details about the failure). The top failure of the language that gets the majority of my venom is their poor use of the __FILE__ macro and the maintainers refusal to recognize that they are the ones doing it wrong (translates links rather than giving you the raw value like every other major language).

    Really the biggest problem with PHP is not the language itself, however, it's all the bad information out there about how to use it. Many of the helpful examples (especially for form processing or database work) are so full of security holes it's not funny. Sadder still is that it's the newbies that don't understand such concepts that read this bad advice as gospel and then continue to promote it by posting it again in their turn. All languages have their holes and flaws, but PHPs are more visible because of it's ubiquity (e.g. anyone can get a cheap hosting account that supports PHP) and because it drives the majority of the UIs on the web.

  28. Re:One page book by vilanye · · Score: 0

    If your field of vision is PHP, C# and Java, you should find employment elsewhere like Walmart.

  29. Re:One page book by wonkey_monkey · · Score: 1

    Yeah, only idiots use PHP -- that's why it's only used by 80% of the web

    While I agree with your point about language snobbery, popularity doesn't imply user intelligence. There was a time when 80% of the web was written in Comic Sans with green text on a yellow background ;)

    Disclaimer: I actually do like PHP, in spite of the inconsistencies that do admittedly plague it.

    --
    systemd is Roko's Basilisk.
  30. Re:One page book by fisted · · Score: 1

    > you're a fucking idiot.

    FTFY

  31. Re:One page book by Anonymous Coward · · Score: 0

    +1 Insightful
    +1 Informative
    +1 Redundant

  32. Re:One page book by vilanye · · Score: 2

    Python and Ruby are strongly typed, unlike PHP which doesn't even rise to the lofty title of weakly typed, stupidly typed is more accurate.

    I am more familar with Ruby, so I will comment based on that, but my recollection of Python isn't much different. An object in Ruby is a specific type and will never be a different type, you can not coerce it(although you can get the object to return its representation in a different object: to_s, to_a, etc) to anything else and has no casting. You can't get much safer than that.

    It also provides a mechinism that it cares more about what an object can do(the real point of OO) than what it is(Kingdom of nouns-profound misunderstanding of OO) unlike Java that requires so much verbosity to achieve the same effect.

    Or are you referring to static and string typing Java style? You might want to know that many Java frameworks go to extreme contortions to get around its verbose and broken type system.

  33. Re:One page book by narcc · · Score: 1

    So does using the "but everyone else is doing it" argument.

    That's not the argument I'm making :)

    PHP is ubiquitous. That's certainly an advantage as far as maintaining it's share of the web. However, that didn't happen overnight. PHP is ubiquitous today because it did the job it was designed to do better than competing languages. This is still true today, as evidenced by several "superior" fad-languages failing to gain any ground. If PHP was garbage that no professional would touch, it couldn't have possibility achieved such an astonishing share!

    You can criticize any language you want. With enough effort, you can make C appear to be the worst language ever improperly designed. (Just poke around the usenet archives and you'll see what I mean.) PHP has it's share of warts, no question, but it's not the worthless pile of garbage that language snobs have made it out to be.

    Really the biggest problem with PHP is not the language itself, however, it's all the bad information out there about how to use it.

    You'll find that's true of all popular programming languages. (You should see the nonsense out there about JavaScript -- written by respected professionals!) Though I'll admit that it might be a bit worse for PHP due to the large number of beginners the language attracts due to it's astonishing ease-of-use.

    Really, I think that ease-of-use is exactly why we see so many "PHP is garbage" comments on forms like this. Developers are (undeservedly) considered by the general public to be brilliant-- a bit like MD's. The difference, of course, is that anyone can become a computer programmer in their spare time -- even children. Hell, I'll bet that the majority of Slashdot users were writing games for their home micro before the age of 12. It's an easy skill to learn -- and everyone developer knows it. Being insecure, the last thing they want is some easy language out there that's easy to learn and use. If their little secret got out, no one would think they were brilliant! They'd just be another nobody -- their worst fear!

    Languages like PHP are a huge threat to those insecure developers. I'm not surprised that they bash it at every opportunity.

  34. Re:One page book by narcc · · Score: 1

    Not quite what I meant -- see my other reply. Apparently I can't communicate ideas today.

  35. Re:One page book by Anonymous Coward · · Score: 0

    Nail, meet head.

  36. Re:One page book by garyebickford · · Score: 0

    Yes, Perl is a paragon of structure and consistency:

    Exactly what the EXPR argument to when does is hard to describe precisely, but in general, it tries to guess what you want done. Sometimes it is interpreted as $_ ~~ EXPR, and sometimes it is not. It also behaves differently when lexically enclosed by a given block than it does when dynamically enclosed by a foreach loop. The rules are far too difficult to understand to be described here. See Experimental Details on given and when later on.

    - Perldoc

    --
    It's easier to be a result of the past, but more fun to be a cause of the future! http://www.spacefinancegroup.com/
  37. Re:One page book by Anonymous Coward · · Score: 0

    Software development will get easier, cheaper, and unprofitable and that's OK because that the nature of technological. The goal should be making tech easier to use and develop for.

  38. Re:One page book by Anonymous Coward · · Score: 0

    The smart-match operator was fairly experimental from its introduction in 5.10 and was already disabled in 5.20, IIRC. Also, the Perl (5) interpreter relies quite a bit on heuristics to parse certain ambiguous syntax elements; you generally don't type them accidentally and when you do, the interpreter often emits a warning. Perl has never tried to be a strict language such as Java that beats you with a stick if you don't put parentheses after a method call.

  39. Re:One page book by Xest · · Score: 1

    "JSP Oracle is the bad guy right.

    Don't have to use JSPs and don't even really have to go near Oracle. There are fully open source Java stacks.

    "ASP Microsoft is the bad guy right."

    Truly skilled high quality professionals don't care about fanboyism, they just use the best tool for the job. If that's ASP.NET then so be it.

    "Perl The 1990's called and they want their programming back."

    I'll let you have that, though I'd argue that Perl is both of a higher quality design in that it's been built with sound academic understanding at it's heart, and more thoroughly tried and tested. It's certainly not worse than PHP that's for sure, though I'd agree there are probably better alternatives now.

    "Ruby on Rails, good alternative however it will be hard to find replacement programmers."

    Not really, I guess it depends in part what level you're hiring at. Any senior developer or upwards worth his salt will be at a point in their career where you can throw a new language and stack at them and they wont care what it is, they'll just get on and work with it being up to speed in no time at all. It may be harder at junior levels or normal developer levels perhaps but I'm not convinced it would be any more an impediment than companies face hiring say, iOS or Android developers for example though admittedly not as easy as finding Java, C# and PHP developers (though purely PHP only developers tend to be low calibre so you should be asking if you really want them working on your software anyway).

    "Python, Python is my favorite language, however it isn't that good for web."

    Neither is PHP but that doesn't seem to be much of an impediment to people choosing to use it. I'd argue Python is better because it's learnt from many of PHP's mistakes in this respect.

  40. Re:One page book by Xest · · Score: 1

    I'm in the same place having worked on large PHP projects.

    It doesn't mean it's a good technology though, it's still shit and if you're starting a project rather than taking one over then there's always a better option to choose than PHP unless the client stubbornly mandates it.

    It really is high time PHP was phased out, there's just too many better alternatives out there, which if you're as experienced in other languages as you say I'm sure you already know.

    I don't think anyone is saying don't use it if it's where the money is, but if you have the option then advise against it or outright opt for something else if the decision is yours.

    Actively choosing it, nowadays, is outright negligent, and that's the problem.

  41. Re:One page book by deanrock0 · · Score: 1

    That's nice. You are comparing lightweight interpreter (PHP) to a Scala which runs on beast called JVM and consumes a lot more memory just to start and print Hello world.

    You can literally run tens or even hundreds of small PHP websites on a 512 MB VPS or even a few larger. You also shouldn't forget about shared hosting, where most of PHP websites are hosted (albeit those are small sites, but they represent majority of all sites written in PHP).

    Nonetheless, PHP language is improving and with the number of powerful web frameworks (Yii, Laravel, CodeIgniter, Symfony, CakePHP, ...) it's hard to not think about building a website in it. You get everything others have (MVC model, great ORM or other database layer, migration framework, etc.) and you can host it practically everywhere. It's cheap for testing and small sites, and reasonably priced for bigger sites.

    Not everyone will create next Facebook, Twitter, YouTube, Google, ... so there is no need to argue scalability, because PHP is scalable and fast enough for majority of web applications. From security aspect, modern PHP isn't any better nor worse compared to alternatives.

    Just let people choose whatever language they are most comfortable with or fits theirs needs.

  42. Re:One page book by Terrasque · · Score: 1

    Python, Python is my favorite language, however it isn't that good for web.

    Go home, comment. You're drunk.

    Django, Pylons, Bottle, Flask, TurboGears, Zope, Web2Py...

    And that's just some of the popular frameworks..

    --
    It's The Golden Rule: "He who has the gold makes the rules."
  43. Barn door closed after horse is gone? by Anonymous Coward · · Score: 0

    This book came out in Feb and is only now being reviewed? Any serious PHP programmer already has it, I would guess. It's the go-to, definitive PHP book. I skipped the second edition, but with all the changes to PHP recently (OO, etc) I got this one. Most PHP programmers probably have had all the editions. (I can't think of another PHP book I'd spend my money on.)

    I think something newer would be a more interesting review. I'd review Stroustrup's new edition, but haven't been doing much C++ recently and haven't had time to read much of it.

    The new Android Tablet Developer's Cookbook is interesting. I wish I had time to read it. It's the first advanced Android book I've seen - all the other books I've seen are the same introductory stuff over and over.

    O'Reilly's JavaScript for PHP Programmers is also interesting. And cheap - it's one of the only O'Reilly books at about $15 I've ever seen. That's more Dover price territory! JS has been something I picked up with bits and pieces as I needed them. O'Reilly's JavaScript: The Definitive Guide is intimidating and TMI. The little JavaScript for PHP Programmers is much more concise. (And cheap!)

  44. Re:One page book by Anonymous Coward · · Score: 0

    When I was in college, we wrote CGI in assembly!
    .
    .
    .
    Seriously, most asinine thing ever (I think that was the point).

  45. Programming PHP? by Anonymous Coward · · Score: 0

    "Programming" is a bit of an overstatement if you're talking about PHP.

    1. Re:Programming PHP? by Anonymous Coward · · Score: 0

      That's why I love using PHP so much... it reminds me of when I used to be a programmer. :)

  46. Re:One page book by gfxguy · · Score: 1

    No - people without a chip on their shoulders understood exactly what you were implying.

    --
    Stupid sexy Flanders.
  47. Re:One page book by gfxguy · · Score: 1

    I like Django... that's my preference for new projects, but I have a lot of older PHP projects, and some of the developers here are still creating and maintaining PHP sites, and I have no problems with them, either. PHP works well for what it was designed for; I love Python, but we've managed to do some pretty complicated and, more importantly, working sites in PHP. I have no problem with it.

    --
    Stupid sexy Flanders.
  48. Unicode by dolmen.fr · · Score: 1

    Please tell us how PHP rocks to handle Unicode...

  49. I always enjoy a good language war by Anonymous Coward · · Score: 0

    (breaks-out popcorn)

  50. Re:One page book by Anonymous Coward · · Score: 0

    Good thing no one uses Scala to write hello world apps.

    Since you are a PHP fan I can safely assume you are uneducated and don't know that trading space for time is a common tradeoff in the CS world.

    Almost every algorithmic optimization is giving up memory to speed up execution. I have had difficult problems that were O(n!)-yes I know you don't know what it means, here read this if you can understand it https://en.wikipedia.org/wiki/Big_O_notation - and took days to run without using branch and bound, which cut it down to a few minutes in the worst case. Of course, it increased the memory usage by about a factor of 3, but it was obviously worth it.

    Long running apps that are properly written are screaming fast on the JVM which is why it is used server side so often.

  51. Re:One page book by Anonymous Coward · · Score: 0

    PHP was never the best option, it was just easily grokable(at least in a very shallow sense) by amateurs which is the reason the web is so unsecure. Hacking any PHP app is trivial, amazingly Windows 7 and 8 are now more difficult to hack than PHP.

    Ask Zuckerberg if he regrets using PHP and listen to him whine and moan about the tens of millions of dollars wasted to get around PHP's flaws.

    Ask Lerdorf technical questions and be amazed at his ignorance. He hates programming by the way.

    PHP by amateurs for amateurs.

  52. Re:One page book by Anonymous Coward · · Score: 0

    LOL

    So you are decrying the bandwagon while jumping on one?

    Cognitive dissonance much?

    At least I can give you valid reasons why I don't use PHP ever, and why I use the languages I do. Using actual arguments founded in computer science.

    You use PHP because "everyone else does". You don't understand why it is a steaming pile of shit and you don't care enough to try to understand. You just hack and slash your way to a shitty solution. You are a typical PHP "programmer".