Slashdot Mirror


Facebook's HipHop Also a PHP Webserver

darthcamaro writes "As expected, Facebook today announced a new runtime for PHP, called HipHop. What wasn't expected were a few key revelations disclosed today by Facebook developer David Recordan. As it turns out, Facebook has been running HipHop for months and it now powers 90 percent of their servers — it's not a skunkworks project; it's a Live production technology. It's also not just a runtime, it's also a new webserver. 'In general, Apache is a great Web server, but when we were looking at how we get the next half percent or percent of performance, we didn't need all the features that Apache offers," Recordon said. He added, however, that he hopes an open source project will one day emerge around making HipHop work with Apache Web servers.'"

304 comments

  1. GUI applications by sopssa · · Score: 5, Interesting

    While theres already several libraries intended for creating windows and interfaces with PHP, and to put them together into an executable file, this might greatly improve that area in PHP too. While being faster as well, being machine code it protects your code too.

    Along with making it work with Apache Web servers I hope someone works on this aspect too. PHP is really nice and fast to write. *ducks from the c/c++ coders*

    Definitely interesting project.

    1. Re:GUI applications by Anonymous Coward · · Score: 0, Troll

      Seriously, why would anyone use PHP to develop non-web apps, when there are so many significantly better alternatives?

      Python, Perl and Ruby are the big three alternatives that run on more platforms than PHP, offer much better and more mature languages, and have far better standard libraries. Haskell and Erlang are much better functional equivalents.

      Even then, we still have Tcl, C, C++, Java, C#, and many other languages available to use.

      PHP isn't really that useful for web development any more. The only reason it still hangs on is because so many companies and individuals screwed up and chose to use it in the first place.

    2. Re:GUI applications by FooAtWFU · · Score: 2, Interesting

      Fast to write, sure, but "nice"? The language is a mess, its metaprogramming is weak, and its packaging system is almost as bad as C. If you want a "nice" language go for Ruby or even Python something. (I do Perl myself, which has its share of cruft and hacks, but at least I have a decent package/namespace system.)

      --
      The World Wide Web is dying. Soon, we shall have only the Internet.
    3. Re:GUI applications by toastar · · Score: 1

      Seriously, why would anyone use PHP to develop non-web apps, when there are so many significantly better alternatives?

      Python, Perl and Ruby are the big three alternatives that run on more platforms than PHP, offer much better and more mature languages, and have far better standard libraries. Haskell and Erlang are much better functional equivalents.

      Even then, we still have Tcl, C, C++, Java, C#, and many other languages available to use.

      PHP isn't really that useful for web development any more. The only reason it still hangs on is because so many companies and individuals screwed up and chose to use it in the first place.

      Meh,

      I prefer php because it's a nice compromise between being easy to read, and being easy to find code to copy.

    4. Re:GUI applications by shutdown+-p+now · · Score: 4, Funny

      PHP is really nice and fast to write. *ducks from the c/c++ coders*

      You should duck from Python and Ruby coders. The C++ guys are too busy beating up Java schmucks. ~

    5. Re:GUI applications by FooAtWFU · · Score: 2, Funny

      I prefer php because it's a nice compromise between being easy to read, and being easy to find code to copy.

      Congratulations. You have just explained half the code snippets on The Daily WTF.

      Do you use the for-case paradigm too?

      --
      The World Wide Web is dying. Soon, we shall have only the Internet.
    6. Re:GUI applications by dgatwood · · Score: 4, Insightful

      What makes PHP nice is that it is so close to C. For people who are comfortable working in C, PHP is just a few dollar signs away.

      --

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

    7. Re:GUI applications by MightyMartian · · Score: 1

      Um, how about bash? It may not have all the tricks of the big boy scripting languages, but goddamnit, I can run a script I wrote twenty years ago and the odds are very favorable that the damned thing will work. Compared to any php or any you list, it's light weight, has decades worth of samples and resources (if you consider its forbearer; sh and ksh), and runs on pretty much any modern platform out there (even Windows).

      --
      The world's burning. Moped Jesus spotted on I50. Details at 11.
    8. Re:GUI applications by MightyMartian · · Score: 5, Funny

      What makes PHP nice is that it is so close to C. For people who are comfortable working in C, PHP is just a few dollar signs away.

      Which is like saying an anus is almost like a vagina...

      Feel free to take that analogy the distance.

      --
      The world's burning. Moped Jesus spotted on I50. Details at 11.
    9. Re:GUI applications by shutdown+-p+now · · Score: 2, Insightful

      What makes PHP nice is that it is so close to C. For people who are comfortable working in C, PHP is just a few dollar signs away.

      Well, JavaScript is even closer, then - not even dollar signs needed.

      In truth, however, it may be a curse rather than a blessing. The syntax looks deceptingly familiar, but semantics are anything but. C is a language where things are generally unambiguous and straightforward, even when syntax is cryptic. PHP is the opposite - seemingly simple syntax can have a lot of subtle ambiguities. See my other comment to this story for an example.

    10. Re:GUI applications by dgatwood · · Score: 1

      Yeah, and you can write some pretty powerful^H^H^H^H^H^H^H^Hinsane stuff with shell scripts.

      *points to sig*

      --

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

    11. Re:GUI applications by ls671 · · Score: 2, Interesting

      > and being easy to find code to copy.

      Some use Joomla for the same reasons...

      I set up only 1 site with Joomla in order to try it. I guess it is OK if your site doesn't have sensitive data and that you do not mind having your site defaced once in a while ;-))

      I had the admin password changed by a remote attacker on the Joomla site. The attacker couldn't deface the site although because I filtered admin access at the reverse-proxy level, thanks god ;-))

      Anyway, I wouldn't use Joomla for any sensitive site and I am tempted to say the same about PHP. I figure that it should be possible to write PHP in a secure way but I haven't seen it yet. Default session handling is a joke in PHP with files in the /tmp directory (session hijacking). There is also many other aspects that are handled in a way that often makes me smile ;-))

       

      --
      Everything I write is lies, read between the lines.
    12. Re:GUI applications by rockNme2349 · · Score: 1

      Sorry, get ready for a beatin!

      I tried to post a reply but I segfaulted, bad string handling. I had to wade through fields of ampersands and asterisks to get here.

      -C guy.

      --
      Sewage Treatment Facilities - "Our duty is clear."
    13. Re:GUI applications by Anonymous Coward · · Score: 0

      Feel free to take that analogy the distance.

      <duffman>OOOOOOoooooooohhhhh yeah!</duffman>

    14. Re:GUI applications by ls671 · · Score: 1

      > or any you list, it's light weight,

      I use bash scripts everywhere for "run once in a while" tasks but...

      1) Bash scripts are usually heavy weight with regards to resources needed (creating many processes on the system. etc...).

      > and the odds are very favorable that the damned thing will work.

      2) Java is backward compatible since the very first version. For me, this tells something about the qualification of the people creating/maintaining ANY language or OS, etc.

      --
      Everything I write is lies, read between the lines.
    15. Re:GUI applications by mabinogi · · Score: 0, Troll

      The number of people who chose PHP because it has a superficial syntactic resemblance to C (actually it looks more like Perl than C) must be vanishingly small.
      No one(*) develops in C any more, being C-like is no longer a benefit.

      (*) Ok, I know that _some people_ do - I do myself, for a job even, but it's very rare to find new developers that know real C, compared with Java, C# or C++. And the number of people who profess some level of PHP proficiency dwarf all of them.

      --
      Advanced users are users too!
    16. Re:GUI applications by dgatwood · · Score: 1

      A significant percentage of JavaScript stuff is done with dot notation and classes. So I'd say its closer to a subset of C++, really. It's also a pretty awful language, mainly because of the debugging environment. (Don't get me wrong, the new debuggers make it a heck of a lot better than it used to be, but that's like saying death by a million paper cuts is better than death by a million razor blades.)

      Regarding the issue of array indices in PHP, it is a little ugly, but you can generally cast such a string to an integer (assuming that's what you want) just by saying $foo = $bararray[(int)$indexvalue];. And thankfully, IIRC, you can't access the non-numeric keys using numeric indices like you can in JavaScript. Now *that* is one unholy, ugly mess of an associative array design....

      --

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

    17. Re:GUI applications by ls671 · · Score: 1

      This happens sometimes when I screw up doing pointer arithmetics or when I do not check array bounds.

      To cure this, I started designing a system were I will abstract pointers with my own custom library. It will also automatically free the memory from unused objects. I will call it "memory recollection".

      I am also designing my own custom third party library to automatically check array bounds ;-))

      --
      Everything I write is lies, read between the lines.
    18. Re:GUI applications by Korin43 · · Score: 1

      Why don't you just use Java? It's more like C++, and has the advantage of having a standard library that isn't a huge mess (it's also much faster).

    19. Re:GUI applications by toastar · · Score: 1

      Do you use the for-case paradigm too?

      That should take about 20 lines not 60... Is that what you were trying to say?

    20. Re:GUI applications by linumax · · Score: 1

      Which is like saying an anus is almost like a vagina...

      Feel free to take that analogy the distance

      Distance or depth? You decide.

    21. Re:GUI applications by Anonymous Coward · · Score: 0

      Because its java.

    22. Re:GUI applications by jfim · · Score: 2, Informative

      This happens sometimes when I screw up doing pointer arithmetics or when I do not check array bounds.

      To cure this, I started designing a system were I will abstract pointers with my own custom library. It will also automatically free the memory from unused objects. I will call it "memory recollection".

      I am also designing my own custom third party library to automatically check array bounds ;-))

      You mean like boost::shared_ptr and std::vector::at() ?

    23. Re:GUI applications by Snarf+You · · Score: 1

      Hopefully he has upgraded to the "once in a while" switch replacement technique.

    24. Re:GUI applications by MightyMartian · · Score: 1

      You bitch about bash spawning processes as being too heavy, and then recommend Java?

      --
      The world's burning. Moped Jesus spotted on I50. Details at 11.
    25. Re:GUI applications by dgatwood · · Score: 2, Insightful

      Mainly because I have a fundamental difference of opinion when it comes to return values versus exceptions. The Java folks seem to prefer the latter quite frequently. I tend to think that exceptions are for things that are truly exceptional---the equivalent to a kernel panic---something that should almost always cause the program to crash or at most, clean up and die. Thus, exceptions should never be thrown by any standard library because no library can reasonably determine what is or is not fatal to the application that calls it.

      And even within application code itself, exceptions are really just a crutch so that programmers can be lazy and skip error checking throughout large blocks of their code. The result, at least in my experience, tends to be pretty much what you would expect---buggy code that crashes or misbehaves with regularity. That's not saying you can't write good code in Java, just that in my experience, that's the exception rather than the rule. No pun intended. Exceptions save a little bit of time during the coding phase, but they make it much harder to debug certain classes of problems. They're basically the Java equivalent of setjmp or GOTO---well, not quite that bad, but close.

      I know, $10 answer to a fifty cent question, but....

      --

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

    26. Re:GUI applications by shutdown+-p+now · · Score: 1

      A significant percentage of JavaScript stuff is done with dot notation and classes. So I'd say its closer to a subset of C++, really.

      Most well-written PHP code (at least, code that proponents of the language tout as well-written) is also done using dot (er, arrow) notation and classes. This doesn't make it a subset of C++ in any way, since classes are neither invented by C++, nor exemplified by it.

      If anything, PHP is actually closer to C++ than JavaScript is, because both PHP and C++ have class-based OOP, while JavaScript offers prototype-based OOP.

      It's also a pretty awful language, mainly because of the debugging environment. (Don't get me wrong, the new debuggers make it a heck of a lot better than it used to be, but that's like saying death by a million paper cuts is better than death by a million razor blades.)

      Are we talking about JS-in-a-browser here, or JS as a free-standing general-purpose language?

      Regarding the issue of array indices in PHP, it is a little ugly, but you can generally cast such a string to an integer (assuming that's what you want)

      You misunderstand. The issue isn't that "08" is not treated as integer, the issue is that "8" is. Strings aren't integers, why make an implicit conversion there, especially when it's so inconsistent?

      And thankfully, IIRC, you can't access the non-numeric keys using numeric indices like you can in JavaScript

      JavaScript is more consistent there in that it doesn't even have numeric keys - they're strings only. So it just converts any other type to string, and calls it done. This matches the observable behavior of PHP w.r.t. to 8/"8"/"08", but PHP clearly differentiates numbers and strings otherwise, as shown by the fact that it will round floating-point numbers.

      I agree, however, that JS design is also messy. The cleanest design that successfully unifies indexed and associative arrays is present in Lua, where Lua "tables" can have keys of any type, and only numeric keys are treated somewhat specially for the purpose of determining the "length" of the table. But otherwise "8" and 8 are two distinct keys - and it is as it should be.

    27. Re:GUI applications by Anonymous Coward · · Score: 0

      "While being faster as well, being machine code it protects your code too."

      It doesn't protect your code, it hides it.

    28. Re:GUI applications by geniusj · · Score: 1

      I know you said C, but you were responding to a post regarding C++. I'll just clarify that the issues you're alluding to, while they exist in C++, are exceedingly rare (when using references, STL, Boost) compared to C.

    29. Re:GUI applications by Yold · · Score: 2, Informative

      No, its closer to Lisp/Scheme; it has been called "Lisp in in C's clothing". The keywords and syntax is somewhat C-like, but once you get beyond the basics you'll understand what I'm talking about... but here is a simple example (styled for brevity):

      function func(){
        var foo = "bar";
        return (function(){alert(foo);}); }

      function bazz(arg){
        alert(foo); //error
        arg();} //alerts foo

      bazz(func());

      Javascript doesn't allow you to access Objects (aka Associative Arrays) via numeric indexes, if you have found a way to do this you are doing in wrong... And have you tried Firebug?

    30. Re:GUI applications by Korin43 · · Score: 1

      You don't really have to use exceptions though. They seem like they could be useful, but if you don't want them you can just ignore them. Any Java classes that use them will warn you and you can just surround them with a try/catch.

    31. Re:GUI applications by siride · · Score: 1

      Java's still a thousand times faster than bash. I love shell scripting, but I'm not going to pretend that bash is performant in any way.

    32. Re:GUI applications by ls671 · · Score: 4, Insightful

      Application servers based on Java are heavy only on start up, the allocated memory is then reused which makes it light on system load once started.

      Java uses some of its memory to cache machine code in order to re-execute it the next time it is needed and this also makes it light on system load.

      Simply by using top, you could understand what I am talking about. Java uses more memory but it is otherwise very light on system load and guess what ?

      Machines typically have 4 GB of ram nowadays.

      Most people bitching about Java being heavy do not understand what I am trying to explain to you here ;-)

      --
      Everything I write is lies, read between the lines.
    33. Re:GUI applications by pnaro · · Score: 1

      Which is like saying an anus is almost like a vagina...

      Feel free to take that analogy the distance

      Distance or depth? You decide.

      It's all a matter of depth perception.

      --
      If we can't fix it, we'll fix it so nobody else can!
    34. Re:GUI applications by Anonymous Coward · · Score: 0

      What makes PHP nice is that it is so close to C. For people who are comfortable working in C, PHP is just a few dollar signs away.

      Which is like saying an anus is almost like a vagina...

      Feel free to take that analogy the distance.

      two in the pink, one in the stink!

    35. Re:GUI applications by Rufty · · Score: 1

      Cloaca, kinda the goatse of technical terms.

      --
      Red to red, black to black. Switch it on, but stand well back.
    36. Re:GUI applications by wmac · · Score: 1

      Have you ever heard of OOP PHP as in 5.2 and higher?
      What about frameworks like ZendFramework, CakePHP etc...
      Obviously you don't know about PHP's market share, performance, coding tools, etc. The new generation PHP applications have nothing less than other languages. I have been doing J2EE for at least 7 years but I always use PHP+MySQL for high traffic websites. One of my websites has 1 million members and up to 8000 concurrent users. 4 quad servers (2 MySQL + 2 Apache) serve 150 million page views per month.

    37. Re:GUI applications by Gerald · · Score: 2, Interesting

      Why not go all the way and write a web server in sh?

    38. Re:GUI applications by ls671 · · Score: 1

      Nope, just like in Java where it is built-in the language specifications ;-)))

      --
      Everything I write is lies, read between the lines.
    39. Re:GUI applications by MightyMartian · · Score: 1

      I wasn't referring to those sorts of applications. Obviously where you've got a preloaded framework, a language like Java, with JIT compilation, is going to be deliver well on the performance and stability fronts. But since non-web apps don't tend to run on systems where a full-blown Java framework is loaded, well, writing apps in Java seems pretty nuts.

      I wouldn't write a full blown app of any kind in sh or its descendants, but compared to the bloated monsters that PHP interpreters are, I can't imagine why one would ever write anything but web apps in such a language.

      --
      The world's burning. Moped Jesus spotted on I50. Details at 11.
    40. Re:GUI applications by dgatwood · · Score: 1

      My point was that a bunch of the major classes required use of them, last I checked (particularly the TCP/IP stuff).

      --

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

    41. Re:GUI applications by Clover_Kicker · · Score: 1

      LOL, reminds me of this...

      "They're het, man, but they're pirates. They'll take a whack at anything that's warm and concave."

    42. Re:GUI applications by Falconne · · Score: 1

      You're just reinventing smart pointers that have existed for yonks. Read up on how to use Boost smart pointers. In fact, reserve a few days just to get an idea of what you can achieve with Boost, it's a huge library.

    43. Re:GUI applications by eihab · · Score: 5, Insightful

      Hopefully he has upgraded to the "once in a while" switch replacement technique.

      That struck me as weird, because as a programmer you usually start with conditionals and then move on to loops. I had a hard time believing that someone would know of "while(true)" and not "else if".

      So I decided to run some tests over dinner. I'm no C++ programmer but here's how I went with this.

      First I wrote a tests.cpp that looks like this:

      #include
      int main () {
          int subType, mainType = 11;

          Slashdot_Filter_Sucks // Editable section
          while (true) {
              if (mainType == 7) {
                  subType = 4;
                  break;
              }
              if(mainType == 9) {
                  subType = 6;
                  break;
              }
              if(mainType == 11) {
                  subType = 9;
                  break;
              }
              break;
          }
          Slashdot_Filter_Sucks // End of editable

          std :: cout

      I compiled that and it resulted in a 8120 bytes binary that ran in 0.005ms.

      I thought about other obvious and simple ways to write this code and I created four more versions that are identical except for the code between the dividers (I had pretty asterisk lines but Slashdot's junk filter made me take it off). They are:

      testif.cpp (test using an if/else statement):

      if (mainType == 7) subType = 4;
      else if (mainType == 9) subType = 6;
      else if (mainType == 11) subType = 9;

      testifonly.cpp (no else, only ifs):

      if (mainType == 7) subType = 4;
      if (mainType == 9) subType = 6;
      if (mainType == 11) subType = 9;

      testswitch.cpp (using a switch statement):

      switch(mainType) {
          case 7: subType = 4;
          case 9: subType = 6;
          case 11: subType = 9;
      }

      testp.cpp (subtract 3 from mainType since that seemed like a pattern):

      subType = mainType - 3;

      I compiled everything using g++ then I ran time ./output. All the versions ran on average in 0.005ms, however, the binary sizes were different:

      #ls -l (ordered by size)
      8072 testp
      8109 testifonly
      8120 tests
      8121 testif
      8125 testswitch

      Ok, no case here in terms of size. So I tried compiling again with -O3, and the results were:

      #ls -l (ordered by size)
      8024 testp_o3
      8024 tests_o3
      8025 testif_o3
      8029 testifonly_o3
      8029 testswitch_o3

      Here it seems that the subtraction and the weird while/break method have the smallest file size. Without code context, one can imagine that subType was to be left alone if mainType was not 7,9 or 11. Which would mean the subtraction code wouldn't work in that scenario.

      Now, I don't know the intricacies of C++ or Assembly, but I have to wonder if this was the work of a moron or someone who knew exactly what they were doing and did so for a reason.

      Again, without context, none of this matters.

      --
      If you can't mod them join them.
    44. Re:GUI applications by ls671 · · Score: 1

      OK, my OP was a joke intended at illustrating that it seems better to have something built-in the language specification than using one of the many third party libraries available to implement it or even worse, to go your own way...

      I haven't coded any new functionality in C++ for many years, I only maintain C/C++ stuff now...

      So, I am not really developing anything similar to what I mentioned in my OP.... ;-))

      --
      Everything I write is lies, read between the lines.
    45. Re:GUI applications by Anonymous Coward · · Score: 0

      Two in hole, one on the mole!

    46. Re:GUI applications by dgatwood · · Score: 1

      Most well-written PHP code (at least, code that proponents of the language tout as well-written) is also done using dot (er, arrow) notation and classes. This doesn't make it a subset of C++ in any way, since classes are neither invented by C++, nor exemplified by it.

      My point was that you can write basic PHP without any understanding of OOP. The core bits are pretty much procedural. With Javascript, even trivial string manipulation or number rounding requires you to understand OOP and dot syntax. Compare JavaScript's Math.floor(3.4) with PHP's floor(3.4), JavaScript' mystring.substr(1,3) with PHP's substr($mystring, 1, 3), etc.

      As for classes in PHP, IMHO, that really depends on how big the code is. If there are units of functionality that are easily reusable, self-contained, and tend towards data structures, then classes aren't a bad idea. For short programs, though, classes often just make the code larger, harder to read, and more CPU intensive. There's a time and a place, and I use them quite a bit, but I'm also careful not to overuse them, having seen just what painful joys that leads to. :-D

      Are we talking about JS-in-a-browser here, or JS as a free-standing general-purpose language?

      In a browser. I've never seen anyone use JavaScript as a general-purpose language.... I guess you could, but it just seems like an odd choice of language with limited ability to interface to anything else.

      You misunderstand. The issue isn't that "08" is not treated as integer, the issue is that "8" is. Strings aren't integers, why make an implicit conversion there, especially when it's so inconsistent?

      My point about the "8" versus 8 was that there's really not much need to make a distinction between integers and strings containing exactly an integer and nothing else. You're either using an array with numeric keys and iterators or you're using it associatively. Trying to mix the two is guaranteed to be a mess in any language. Even if the language keeps them distinct, you're creating confusion.

      JavaScript is more consistent there in that it doesn't even have numeric keys - they're strings only. So it just converts any other type to string, and calls it done.

      Actually, it sort of does. JavaScript behaves a lot like PHP. If you use numeric indices, it maintains a variable called count that is one higher than the largest numerical index used. Non-numeric indices don't modify this value. However, strings that contain nothing but a number do change this value. For example:

      foo = new Array();
      foo['2'] = "x";
      alert(foo[2]);
      alert(foo.length);

      Notice that not only is the value of 1 promoted to a string for dereferencing purposes, but also the string value '1' is demoted to an integer and affects the length as though you had assigned into the array with numeric keys. This change of foo.count does not occur if you use a non-numeric key (e.g. 'x' instead of '2').

      Whether you promote from numbers to strings (JS) or strings to numbers (PHP) is largely an irrelevant implementation detail as long as there is exactly one string that maps onto any given numeric value (which seems to be true, at least in PHP).

      Now in the more general case, arguing that for comparison purposes and similar, numbers and strings shouldn't be treated the same way... well, I tend to agree with you, but I'm afraid that ship has pretty much sailed, and it's not a very big ship, so I won't lose sleep over it.... :-) The existence of === and !== in PHP, Perl, and the like is generally good enough for when those differences really matter.

      --

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

    47. Re:GUI applications by Anonymous Coward · · Score: 0

      Fascinating! I wish more posts on slashdot could be this interesting. :)

    48. Re:GUI applications by Z34107 · · Score: 1

      Whoosh.

      I think the GP is a smug Java programmer, hinting that his solution to a C++ problem was to rewrite Java.

      --
      DATABASE WOW WOW
    49. Re:GUI applications by shutdown+-p+now · · Score: 1

      My point about the "8" versus 8 was that there's really not much need to make a distinction between integers and strings containing exactly an integer and nothing else. You're either using an array with numeric keys and iterators or you're using it associatively. Trying to mix the two is guaranteed to be a mess in any language. Even if the language keeps them distinct, you're creating confusion.

      Mmmhm, the point is that the language does not try to keep them distinct, but rather messes them up - and even then does it incorrectly!

      Fine, why not go with a consistent rule of "if it can be a number, treat it as one?". So "8" is treated as a numeric index, but so is "08", "8.0" etc. Why go half way and stop there? Especially when the rest of the language does go all the way ("01" + 2 = 3).

      Actually, it sort of does. JavaScript behaves a lot like PHP. If you use numeric indices, it maintains a variable called count that is one higher than the largest numerical index used. Non-numeric indices don't modify this value. However, strings that contain nothing but a number do change this value.

      Yes, I know. However, it does this sort of checking only for updating the array length, and nothing more. The keys themselves are simply always converted to strings, with no conditionals or exceptions. Note that your description is therefore subtly wrong - when you write something like foo['2'] in JS, the key will still be the string '2', not integer 2. The reason why foo['2'] and foo[2] refer to the same element is because 2 gets promoted to string, not because '2' gets demoted to integer (it does get demoted temporarily when assigning to the element, but only for the purpose of updating length).

      Whether you promote from numbers to strings (JS) or strings to numbers (PHP) is largely an irrelevant implementation detail as long as there is exactly one string that maps onto any given numeric value (which seems to be true, at least in PHP).

      I'd still argue that JS approach is more consistent, because in JS case you ultimately end up with strings as keys only, while with PHP you end up with a mix of strings and integers.

      In truth, though, I dislike both, and think that either type should make all the difference (i.e. 8 != "8" != "08"); or, you shouldn't have types at all, just strings all the way, interpreted as different things if you use appropriate operators - the way Tcl does it. But then you need a clear distinction between indexed and associative arrays, so that the context (whether to treat strings and numbers, or not) is clear - actually, that would help even with the PHP's confused type system, as demonstrated by Perl - that one also loves to treat strings as numbers and vice versa, but, because of the distinction between arrays and hashes, it doesn't have the indexing ambiguity problem.

    50. Re:GUI applications by dgatwood · · Score: 1

      Javascript doesn't allow you to access Objects (aka Associative Arrays) via numeric indexes, if you have found a way to do this you are doing in wrong..

      It does, but only for the numeric keys. I was remembering wrong about doing it for non-numeric keys. My bad. :-)

      --

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

    51. Re:GUI applications by eihab · · Score: 1

      HTML ate my code, and the Slashdot filter won't let me re-post without a lot of text. The first and last lines were:

      #include <iostream>

      [... snip ...]

              std :: cout << subType;
              return 0;
      }

      --
      If you can't mod them join them.
    52. Re:GUI applications by sheriff_p · · Score: 1

      No, you're wrong.

      True: it's very fast to deploy a dynamic web-page with PHP, and all the complexity of request handling are hidden. This is PHP's killer feature. This + a large number of pre-written open-source applications is the ONLY benefit PHP has over almost any other dynamic language.

      Don't get me wrong - it's a HUGE benefit. It's a huge enough benefit that people are willing to work with PHP in order to have it. But it's really the only one. Everything else about PHP is bloated, inconsistent, and poorly designed when compared to its cousins (Python, Perl, Ruby, etc).

      -P

      --
      Score:-1, Funny
    53. Re:GUI applications by eihab · · Score: 1

      Grr... Second reply to my post. testp.cpp was flawed since if mainType == 11 subType should be 9 not 8 (11-3 == 8).

      I modified the code to increment subType by 1 if it's 8:

      subType = mainType - 3;
      if (subType == 8) subType++;

      which resulted in:

      8094 testp_fixed
      8120 tests

      And with -O3 optimization:

      8024 tests_o3
      8030 testp_fixed_o3

      tests.cpp seems to be the smallest of all with -O3 optimization.

      --
      If you can't mod them join them.
    54. Re:GUI applications by dgatwood · · Score: 1

      Especially when the rest of the language does go all the way ("01" + 2 = 3).

      The rest of the language is wrong. Being wrong in that way for array indices would be disastrous. :-) (Okay, so you could work around it by prefixing every array index with an underscore or something, but really, why?)

      But seriously, there's not a real discrepancy there. The operation "+" only operates on numbers, therefore the operands are implicitly coerced into numbers if possible. Things that can't be coerced are treated as zero. The only alternative would be to treat a string value as a reason to crash, and I'm not sure that would be a benefit; it would just result in people littering the code with unnecessary (int) casts.. That's the nice thing about PHP using a separate operator for string concatenation---there's no ambiguity like there is in JavaScript....

      The reason why foo['2'] and foo[2] refer to the same element is because 2 gets promoted to string, not because '2' gets demoted to integer (it does get demoted temporarily when assigning to the element, but only for the purpose of updating length).

      Didn't I say that? *shrugs*

      Either way, I'm not sure I see the problem. If you could create an array with explicit indices of both '2' and 2 in it, you're just asking for the next programmer who has to maintain your code to jump through the internet and pummel you with a clue-by-four. :-)

      That said, I do agree that having separate numeric-indexed and associative arrays would be a big win, just for different reasons. From a performance perspective, maintaining a numeric array is a lot easier than maintaining an associative array. I'm sure there are plenty of optimizations that would be possible if numeric arrays never had to be promotable to associative arrays....

      --

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

    55. Re:GUI applications by eihab · · Score: 1

      What makes PHP nice is that it is so close to C

      Which is like saying an anus is almost like a vagina...

      LOL! Bravo Sir! Well done.

      --
      If you can't mod them join them.
    56. Re:GUI applications by jschottm · · Score: 1

      testp.cpp (subtract 3 from mainType since that seemed like a pattern)

      11-3!=9

      but I have to wonder if this was the work of a moron or someone who knew exactly what they were doing and did so for a reason.

      If there were some amazingly useful reason to do it this way, it should have been clearly documented and never made it to The Daily WTF. If you were running the function more than once (especially if you randomized the value of mainType and ran other code in between calls to the function), you'd eventually see a performance difference between the various versions of your code. However, unless you were in *massive* need for performance or space, breaking standard programming conventions in a way that will confuse other programmers (or even yourself a year later) is a very bad idea.

      "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil" -Knuth

      Clearly written, understandable code that programmers spend less time trying to understand and are less likely to introduce bugs into will almost always trump a small, unneeded optimization.

    57. Re:GUI applications by shutdown+-p+now · · Score: 1

      But seriously, there's not a real discrepancy there. The operation "+" only operates on numbers, therefore the operands are implicitly coerced into numbers if possible. Things that can't be coerced are treated as zero. The only alternative would be to treat a string value as a reason to crash, and I'm not sure that would be a benefit; it would just result in people littering the code with unnecessary (int) casts.. That's the nice thing about PHP using a separate operator for string concatenation---there's no ambiguity like there is in JavaScript....

      I agree that arithmetic and concatenation operators in PHP work proper and consistent with respect to automatic type conversion. And I do actually think that there's nothing wrong with "01"+2==3, if we assume that weak typing is a good idea. I mean, + is defined to only operate all numbers, and "01" can clearly be interpreted as number 1 (and in no other way), so it's all fine and dandy there.

      The reason why I'm picking at array indexing specifically is that there is no similar context there from which to derive the more appropriate conversion, and it's not even obvious that such a conversion is desirable in the first place. I mean, the language reference clearly says that "array keys are either strings or integers". So strings are fine (unlike +) - so why silently convert some strings like numbers, just because they look like ones?

      I stand by my assertion that weak typing mixed with combined indexed/associative arrays, and a single operator [] used for both indexing and key lookup, is an inherently ambiguous situation, and no implicit conversion is reasonable. It should be the programmer who decides, and the language should force him into explicitly doing so, rather than providing a rule which is only appropriate half of the time, and gives bewildering results for the other half.

      It really reminds me of such ill-thought C++ rules as "signed op unsigned -> unsigned", which kinda works for trivial cases such as "1u + 2 == 3u", but then you do something like "sum(v) / v.size()" on a vector of signed ints, and it blows up if sum is negative, because v.size() is unsigned, and so result is also unsigned (so if it was smaller than 0, it underflows and wraps around into a very large unsigned number). It's interesting to read the ISO rationale for this - they argued mixed signed/unsigned arithmetic back and forth for a long time, but eventually went with the rule as it stands mostly because there were more existing implementations that did it that way. A better decision would be to not allow such operations altogether, and require the coder to explicitly cast one or other operand as he needs - but they already had the shackles of backwards compatibility on them...

      Either way, I'm not sure I see the problem. If you could create an array with explicit indices of both '2' and 2 in it, you're just asking for the next programmer who has to maintain your code to jump through the internet and pummel you with a clue-by-four. :-)

      Yup. God bless static typing - as it is, I just write Dictionary<string, Foo> or Dictionary<int, Foo> as needed, and the next programmer knows exactly what I meant. :)

      (or, in Haskell or ML/F#, don't write types at all, but they still get inferred and statically checked for correctness)

      But that's another story.

      That said, I do agree that having separate numeric-indexed and associative arrays would be a big win, just for different reasons. From a performance perspective, maintaining a numeric array is a lot easier than maintaining an associative array. I'm sure there are plenty of optimizations that would be possible if numeric arrays never had to be promotable to associative arrays....

      Well, it's actually rather trivial to implement PHP/JS/Lua-style combined associated/indexed arrays more efficiently than just a plain hashtable. You could have a hashtable and a plain array internally side by side, and use one or the other depending on key type, so long as numeric keys are not dispersed too much. I believe that most JS implementations out there actually do it that way, not sure about PHP.

    58. Re:GUI applications by HoppQ · · Score: 1

      Your switch() cases are missing breaks.

      --
      My sig will be released in 2015 third quarter. Rating pending.
    59. Re:GUI applications by eihab · · Score: 1

      Thanks for catching that. Did I mention I had a few drinks with dinner? :)

      Here's the (now bigger) switch with breaks:

      8125 testswitch
      8131 testswitch_fixed

      8029 testswitch_o3
      8035 testswitch_fixed_o3

      --
      If you can't mod them join them.
    60. Re:GUI applications by eihab · · Score: 1

      11-3!=9

      Yup, I replied to myself with corrections over an hour ago.

      If there were some amazingly useful reason to do it this way, it should have been clearly documented and never made it to The Daily WTF.

      True, but we're only seeing a snippet of it that made it on the Daily WTF.

      Clearly written, understandable code that programmers spend less time trying to understand and are less likely to introduce bugs into will almost always trump a small, unneeded optimization.

      Without context, we wouldn't know if this was standard practice in the code-base, was documented elsewhere or if the person who posted it to TDWTF is just new and thought it's a WTF-moment. Context is everything.

      I'm not defending the code, I was merely pointing out that it seems odd that someone who knows about loops would not know about conditionals.

      Regarding clarity, the code was very easy to follow comment-less to someone who doesn't program in C++. Was the code odd? yes, obfuscated? not at all.

      --
      If you can't mod them join them.
    61. Re:GUI applications by ZorbaTHut · · Score: 1

      Your speed benchmark is absolutely meaningless - running that code will take literal nanoseconds, virtually your entire execution time is taken up with program setup, program shutdown, console output, and benchmarking overhead.

      --
      Breaking Into the Industry - A development log about starting a game studio.
    62. Re:GUI applications by eihab · · Score: 1

      Your speed benchmark is absolutely meaningless - running that code will take literal nanoseconds, virtually your entire execution time is taken up with program setup, program shutdown, console output, and benchmarking overhead.

      Yes it is, which is why I didn't use it for anything. I didn't have time to create something that will iterate over this code a million times with different values, nor did I care that much about it.

      I just looked at the binary file sizes produced and shared what I found.

      --
      If you can't mod them join them.
    63. Re:GUI applications by Anonymous Coward · · Score: 0

      switch(mainType) {

          case 7: subType = 4;

          case 9: subType = 6;

          case 11: subType = 9;
      }

      testp.cpp (subtract 3 from mainType since that seemed like a pattern):

      subType = mainType - 3;

      Uh... 11 - 3 = 9?

    64. Re:GUI applications by Anonymous Coward · · Score: 0

      A lot of men do this every day, either hole is a goal.

    65. Re:GUI applications by hey · · Score: 1

      I had a web site that was many pages of php. Then I needed to do one thing via cron nightly. It used some routines I already had for the website so I did it in php.

    66. Re:GUI applications by Anonymous Coward · · Score: 0

      So PHP is possibly tighter than C, and you don't need protection against child processes?
      CAPTCHA: browner --- something in the internet is alive, and wants to mock me

    67. Re:GUI applications by Anonymous Coward · · Score: 0

      Did you stripped the binnaries?

    68. Re:GUI applications by Anonymous Coward · · Score: 0

      testp.cpp is wrong: 11 - 9 = 2.

    69. Re:GUI applications by gmack · · Score: 1

      If java is backward compatible then why do bugfix releases keep breaking java apps? I actually caught the programmers at the last place I worked trying to disable system security updates on the servers. I also have a Cisco firewall whose web interface breaks on the latest java plugin and needed updating to experimental firmware.

      I'd much rather people use python or perl for complex scripts.

    70. Re:GUI applications by Anonymous Coward · · Score: 0

      Did anyone specify the species we are talking about? Another dud spec!

    71. Re:GUI applications by Anonymous Coward · · Score: 0

      Smart pointers you mean?

    72. Re:GUI applications by DuckDodgers · · Score: 1

      I don't get the dislike for PHP. C has warts. Java has warts. PHP has warts. That doesn't change the fact that they're all tremendously popular and frequently used. If someone wants to write a PHP GUI app, what's wrong with that?

      I love religious wars over programming languages as much as anyone, but at the end of the day getting things done is all that matters. I don't like Facebook much, but you can't argue with its success and its developers got the job done with PHP.

    73. Re:GUI applications by Seahawk · · Score: 1

      Only vaginae support inheritance?

    74. Re:GUI applications by RegularFry · · Score: 1

      Machines typically have 4 GB of ram nowadays.

      Just a nitpick, but I really hate this argument. For starters, while physical machines might have more RAM than they need, virtual machines often don't. There's still a very powerful drive to get memory footprint down for VM usage.

      --
      Reality is the ultimate Rorschach.
    75. Re:GUI applications by jon3k · · Score: 1

      popularity != quality

    76. Re:GUI applications by vegiVamp · · Score: 1

      Well, it is. It's just tighter and the insides are dirtier.

      --
      What a depressingly stupid machine.
    77. Re:GUI applications by EvilIdler · · Score: 2, Insightful

      I write in PHP, among lots of other languages. I'm not a hater. I'm also interested in this project for renting out space to PHP-based projects. Higher density per server = less costs :)

      But where's the code? My calendar says "Wednesday", and I was sure this was a Tuesday announcement. Github search turns up nothing. How long does it take to upload 300k lines of code? Getting impatient here ;)

    78. Re:GUI applications by Blakey+Rat · · Score: 1

      Wow. You are a lonely, lonely person. Next time you get the idea in your head to do this, just go to your local pub instead and get wasted.

    79. Re:GUI applications by ls671 · · Score: 1

      > Just a nitpick,

      No problems ;-)

      VM, like the name suggests, use virtual memory, not necessarily RAM.

      Typically a java VM needs 25% of the memory it uses to be resident (mapped to real RAM). When running into a VM (guest OS), that percentage may drop to 5 or 10% because the virtualization brings another layer of virtual memory that the programs think is real RAM.

      On a 4 GB machine, I typically run 10 VM which all think they have 1 GB available to them. On the VM, each runs a java VM that is configured to use 512 MB of java memory, with OS overhead, the java VMs end up using around 800MB of memory (not necessarily real RAM).

      Do the maths ;-) I still do not think saying that "Java needs to much memory" is a valid point. The truth is that it doesn't matter how much memory you have available, an application in its Java version will handle more load than, for example, the same application in its PHP version without regards for the machine it is running on.

      A lot of people freak out when they see how much memory a java VM reserves on startup without digging any deeper. If they did, they would find out that java is more efficient without regards for the hardware available.

      Also, most people that understand what I am trying to explain have given up a long time ago trying to explain this on /. ;-))))

      Cheers,

      --
      Everything I write is lies, read between the lines.
    80. Re:GUI applications by ls671 · · Score: 1

      > If java is backward compatible then why do bugfix releases keep breaking java apps?

      Untrue, as I said, fully 100% pure java code apps are 100% backwards compatible.

      The problems you are referring to are mostly caused by native C libraries used by the JVM that many implemented (Oracle, IBM, etc. to name a few) without regards for the advantages of writing pure Java Code.

      Native C libraries used by the JVM should be viewed as "C extension to the JVM". Of course when you use them, you risk suffering the same problems as one would experience in C, your native C libraries are completely and entirely out of control of the JVM ;-)))

      --
      Everything I write is lies, read between the lines.
    81. Re:GUI applications by RegularFry · · Score: 1

      Sure. I'm not having a go at Java here, I just think that saying "resources aren't a problem - but they're effectively limitless anyway" isn't a decent counterargument.

      In your case, you control the host. I often might not, and have to be able to assume that if my guest says it has 512MB available, then I can commit ~512MB and not suffer, no matter who's running what else on the same host.

      --
      Reality is the ultimate Rorschach.
    82. Re:GUI applications by ls671 · · Score: 1

      No problems,

      On 512MB machines, I set Java to use 256MB or even 128MB....

      A tomcat server with many applications deployed on it will run fine with 128MB reserved to it. It will run a little slower but so would PHP. PHP uses more OS level buffers/cache to run efficiently so it would also run slower on a 128MB machine due to the lack of buffers/cache memory. Java doesn't need as much buffers/cache to run efficiently because it uses its reserved memory to accomplish the same, usually more efficiently. Also, look at the size of a running apache process when compiled with mod_php compared to an apache server without it, 80MB for a single apache process and I use pre_fork so I have many of them ! ;-)

      no php:
      nobody 2485 0.0 0.0 7392 2128 ? S 18:09 0:00 /usr/local/apache/bin/httpd -k start

      mod_php:
      nobody 3610 0.0 0.1 84348 6804 ? S Jan18 0:01 /usr/sbin/httpd

      Before tomcat and application servers were created, I used to run my own custom jsp server on hosts that had 128MB of memory and these hosts were running many other servers (dns, apache, etc...)

      I started to develop in Java on a 12MB 386 machine running Linux. Of course you would have to use vi to write code on a 12MB machine, eclipse wouldn't run on it but neither would Visual Studio I guess...

      Can you please explain the specific problem that you are experiencing with regards to running java on low memory machines ?

      --
      Everything I write is lies, read between the lines.
    83. Re:GUI applications by ls671 · · Score: 1

      Indeed, java's "references" is just a term to abstract pointers and java only uses references, it is not possible to pass a copy as an argument except for primitive types (8 primitive types and String isn't one of them). So, Java almost use pointers only ! ;-)))

      While coding in C, I have always liked pointers. Understanding pointers is a "feature" that many Java developers lack. It sure helps a lot to understand pointers to get better at coding in Java.

      Being a C developer that enjoyed pointers so much, I jumped in the Java band wagon early when I understood what the language was all about.

      As a side note, note that the people who created Java were much more C developers than smalltalk developers for example.

      --
      Everything I write is lies, read between the lines.
    84. Re:GUI applications by ls671 · · Score: 1

      Désolé de t'avoir fait marcher JF, je ne croyais pas que quiconque me prendrait au sérieux ;-))

      http://slashdot.org/comments.pl?sid=1534682&cid=31031434

      --
      Everything I write is lies, read between the lines.
    85. Re:GUI applications by RegularFry · · Score: 1

      On 512MB machines, I set Java to use 256MB or even 128MB....

      Gah. Way to miss the point.

      Can you please explain the specific problem that you are experiencing with regards to running java on low memory machines ?

      I'm not, nor am I picking a my-ecosystem-is-better-than-yours argument. I'm simply pointing out that resources are not unlimited, and that implying that they are, and that resource management therefore is unnecessary, is unhelpful. There's *always* a case where, if system X used *slightly* less resources, outcome Y would be possible.

      --
      Reality is the ultimate Rorschach.
    86. Re:GUI applications by ls671 · · Score: 1

      Yeah you are right, I shouldn't have used that argument in the first place, it led to a misunderstanding that Java was using more resources ;-((

      I first understood your point although but re-thinking about it, I came to the conclusion that Java wasn't really requiring more resources as my statement led to believe. So, my statement was false. After a second thought at it, I tried to demonstrate that with the best examples I could think of. I wouldn't have replied to yourself "hating the argument" if I hadn't come to the conclusion that my argument led to a misunderstanding.

      If it was true that Java needed more memory and that you hated the "get yourself a machine" argument, then there would have been nothing to reply to you.

      So I understand your point and also, I ain't pretending my "ecosystem-is-better-than-yours", I am just sharing experiences I had with java and other solutions. ;-)

      To my defense, I am a victim of reading /. too much so I now realize that myself had started to believe that Java needs more memory than other solutions do ;-)

      Cheers and sorry for the misunderstanding ;-))

      --
      Everything I write is lies, read between the lines.
  2. nginx by Anonymous Coward · · Score: 1, Interesting

    How does this compare to nginx i wonder?

    1. Re:nginx by Lennie · · Score: 1

      That's like comparing apples to oranges. One is a language used to generate HTML, do database queries, talk to memcached, etc. The other is a webserver.

      --
      New things are always on the horizon
    2. Re:nginx by Neil+Hodges · · Score: 1

      I think GP was asking how HipHop, with its built-in PHP webserver, compares to nginx with FastCGI/PHP when it comes to serving up PHP pages.

    3. Re:nginx by sopssa · · Score: 1

      But most likely wasn't serious. Theres lots of these short nginx one-liners in other stories too.

    4. Re:nginx by kmike · · Score: 1

      But Facebook's PHP is also a webserver, as evident even from this story headline. Hence the question is valid.
      I'm too wondering how nginx + PHP/FastCGI compares to HipHop as a webserver.

  3. A stupid question... by __aaclcg7560 · · Score: 3, Insightful

    For all the trouble you're going through to convert PHP into C++ (300,000 lines and 5,000 unit tests), wouldn't programming in C++ in the first place be easier?

    1. Re:A stupid question... by Lennie · · Score: 2, Insightful

      Because it's really easy to create memory leaks and similair bugs in C++.

      --
      New things are always on the horizon
    2. Re:A stupid question... by sopssa · · Score: 1

      PHP is a lot better environment to develop new features quickly and doesn't get you into so many security pitfalls. And they're already using C++ for some parts of the site:

      HipHop allows us to write the logic that does the final page assembly in PHP and iterate it quickly while relying on custom back-end services in C++, Erlang, Java, or Python to service the News Feed, search, Chat, and other core parts of the site.

      The common suggestion is to just rewrite Facebook in another language, but given the complexity and speed of development of the site this would take some time to accomplish.

      As a programming language, PHP is simple. Simple to learn, simple to write, simple to read, and simple to debug. We are able to get new engineers ramped up at Facebook a lot faster with PHP than with other languages, which allows us to innovate faster.

      And I agree with them on those aspects.

    3. Re:A stupid question... by maxume · · Score: 1

      Um, they say that they don't think it would in one of the articles.

      --
      Nerd rage is the funniest rage.
    4. Re:A stupid question... by Anonymous Coward · · Score: 0

      According to Facebook it would not be. I'm bound to agree. They committed one guy for 8 months and then three guys for 10 months to this product. It's doubtful they could have rewritten all of Facebook in that time.

      Additionally, there's the cost of good C++ developers being more expensive than mediocre PHP developers. Their new approach allows them to churn out code hiring the latter while getting close to the the performance benefits they would see if they only hired the former.

    5. Re:A stupid question... by Anonymous Coward · · Score: 0

      No. If the developers find C++ to be more difficult than PHP, or slower to write than PHP, then Facebook should not switch to C++, because it will get less out of their developers than PHP. With Facebook's current system, the developers can continue using their fast, familiar PHP, while getting the performance of C++. The trick is that the computer does the conversion automatically, not the developer, so programming it in C++ in the first place is no longer necessary.

      Which you would have known if you read the article.

    6. Re:A stupid question... by bill_mcgonigle · · Score: 2, Informative

      For all the trouble you're going through to convert PHP into C++ (300,000 lines and 5,000 unit tests), wouldn't programming in C++ in the first place be easier?

      They address this specifically in one of the articles. They want their whole team (many of whom are not C++ developers) to contribute.

      --
      My God, it's Full of Source!
      OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
    7. Re:A stupid question... by Anonymous Coward · · Score: 0

      For all the trouble you're going through to convert PHP into C++ (300,000 lines and 5,000 unit tests), wouldn't programming in C++ in the first place be easier?

      FTA:
      "HipHop programmatically transforms your PHP source code into highly optimized C++ and then uses g++ to compile it."

    8. Re:A stupid question... by shutdown+-p+now · · Score: 4, Insightful

      As a programming language, PHP is simple. Simple to learn, simple to write, simple to read, and simple to debug.

      PHP is not a simple language. A keymark of a simple language is consistency, and PHP is anything but - I won't even touch on the mess that is the standard function library, but just the language itself. For example, this gem, taken directly from the language spec, regarding array indices/keys:

      A key may be either an integer or a string. If a key is the standard representation of an integer, it will be interpreted as such (i.e. "8" will be interpreted as 8, while "08" will be interpreted as "08"). Floats in key are truncated to integer. The indexed and associative array types are the same type in PHP, which can both contain integer and string indices.

      This is awesome on many levels. The obvious fubar is the treatment of "8" vs "08" (and note that, while it is clearly obvious when a string literal is used in the source code, how about a string variable, or other expression computed at runtime?). But the bit about silent float->int truncation is also interesting, especially the "silent" part. Combined with rounding errors and the overall non-obviousness of binary floating-point arithmetic (especially to a typical PHP coder), this design decision is just hilarious.

      I've long held the opinion that C/C++ rules on mixed signed/unsigned arithmetic and comparisons are a good example of awful language design, but PHP beats that by a margin so large it's not even funny.

      Oh, I also don't know of any other language that has what effectively amounts to synactic sugar for try/catch with an empty catch block. Good programming practices FTW!

      I find it curious, by the way, that PHP coders like to compare the language to C++ or Java - where it actually has some subjective advantages, such as dynamic typing - but very rarely to Perl, Python or Ruby, where all such advantages disappear, but design flaws immediately stand out.

    9. Re:A stupid question... by MightyMartian · · Score: 3, Insightful

      PHP is a lot better environment to develop new features quickly and doesn't get you into so many security pitfalls. And they're already using C++ for some parts of the site:

      Except for the problem that, historically, PHP is been one big vast security pitfall.

      --
      The world's burning. Moped Jesus spotted on I50. Details at 11.
    10. Re:A stupid question... by Cyberax · · Score: 4, Informative

      An experienced C++ programmer rarely creates memory leaks, and they are easily detected by a variety of tools.

      Also, for PHP-style programs it might be easier to just restart a child server process each N requests. So memory leaks are of even less concern.

      The main problem is compilation speed. C++ compilers are just plain slow.

    11. Re:A stupid question... by shutdown+-p+now · · Score: 4, Insightful

      Because it's really easy to create memory leaks and similair bugs in C++.

      It's very easy to get rid of memory leaks in C++, as well. A very simple rule: never, ever write a type declarator with a * in it. In other words, no raw pointers - use Boost/TR1 shared_ptr, or roll out your own, it doesn't matter - just use it consistently. At that point, you can still get reference cycles (which are also leaks), but you can do that in PHP 5.3 - which also uses reference counting with no GC for cyclical references - just as well. And the usage of 5.3 so far is minuscule.

      Alternatively, just use any of third-party tracing GCs, such as Boehm.

      By the way, from personal experience, I find that languages with built-in reference counting and no cycle detection (those I know of are VB6 and PHP) are actually more prone to memory leaks when coding that languages with explicit memory management. The reason is that, in, say, C++, coders are actually aware of issues such as memory allocation, and view smart pointers as convenient helpers, not as some kind of magic fairy dust. Because of that, the question of "what happens if two smart pointers reference each other" is a rather obvious one, and the issue is noticed and rectified early on. In contrast, in VB6 and PHP, you don't have to deallocate explicitly, so refcounting is magic - many people don't even understand how the algorithm works! - that is, until you run into a cyclic reference that leaks...

    12. Re:A stupid question... by tomhudson · · Score: 1

      If you read the article, you'd see that they wrote a program to convert the php - they didn't do it by hand.

    13. Re:A stupid question... by larry+bagina · · Score: 1

      Yeah, this gem stood out when I read about this earlier:

      We are able to get new engineers ramped up at Facebook a lot faster with PHP than with other languages, which allows us to innovate faster.

      What kind of experience and intellect do they have -- or not have -- if that's an issue?

      --
      Do you even lift?

      These aren't the 'roids you're looking for.

    14. Re:A stupid question... by maxume · · Score: 1

      Considering that they are compiling/translating PHP code into C++ code and then compiling that code, I don't think the speed of their C++ compiler was a major contributor to the choice.

      --
      Nerd rage is the funniest rage.
    15. Re:A stupid question... by abulafia · · Score: 1

      Oh, I also don't know of any other language that has what effectively amounts to synactic sugar for try/catch with an empty catch block. Good programming practices FTW!

      Oh, good lord. I didn't know about that one. Every time I think I know just how awful PHP is, I learn something like that.

      I find it curious, by the way, that PHP coders like to compare the language to C++ or Java - where it actually has some subjective advantages, such as dynamic typing - but very rarely to Perl, Python or Ruby, where all such advantages disappear, but design flaws immediately stand out.

      I think it is a bit like penis envy. Not all of them, but a lot of PHP monkeys like to think imagine they're much more hard-core than they are, so they compare what they do to what they perceive as a "real" language.

      If they took the time to actually understand what makes Perl, Python or Ruby so superior, well, it is unlikely that they'd still be happy with PHP.

      --
      I forget what 8 was for.
    16. Re:A stupid question... by amicusNYCL · · Score: 1

      and note that, while it is clearly obvious when a string literal is used in the source code, how about a string variable, or other expression computed at runtime?

      It should be clearly obvious that if you want to use a string as an integer, you use intval to convert it first. Programmers who know the difference between strings and integers know that. Don't take that personally, that comment isn't aimed at you, there are many, many PHP "programmers" who really don't know anything about data types (as a question answerer on the w3schools forum, I can readily attest to this; the level of inexperience people have when trying to tackle major projects is staggering).

      It's difficult to fault a language just because it's easy to learn though. PHP is easy to learn, because it does a lot of stuff automatically (casting, error suppression, etc, like you said). So that means a lot of people copy and paste, go through quick tutorials, etc, and try to write code in it. You end up with a lot of crappy code, but that's not the fault of PHP, that's the fault of the people who are trying to write code without learning any theory at all (literally). Any decent programmer would be pretty surprised that a large portion of people asking PHP questions on w3schools are developing on a server with error message display disabled, errors are routed to a log file instead. They don't know that, and don't know how to change it, so they never even see error messages, just a blank page when they get a fatal error. I sometimes wonder how those people ever manage to debug, then remember that's why they're posting on the w3schools forum.

      Oh, I also don't know of any other language that has what effectively amounts to synactic sugar for try/catch with an empty catch block

      C'mon, if you want to cherry pick examples you can claim whatever you want.

      The error suppression operator is for suppressing errors. The die/exit statements are for quitting execution and optionally printing a message. Some functions return false if they fail, so you can do something like this:

      mysql_query($sql) or exit(mysql_error());

      to print a specific error message for a specific situation. It should be obvious that's equivalent to this:

      if (!mysql_query($sql)) exit(mysql_error());

      That's what your example shows, printing an error that a file couldn't be opened if the file wasn't able to be opened. If you want exception handling and try/catch blocks, here you go:

      http://www.php.net/manual/en/language.exceptions.php

      --
      "Our two-party system is like a bowl of shit looking at itself in a mirror." - Lewis Black
    17. Re:A stupid question... by ls671 · · Score: 0, Troll

      > An experienced C++ programmer rarely creates memory leaks,

      An INEXPERIENCED java programmer NEVER creates memory leaks,

      An experienced java programmer could manage to create memory leaks using threads but you almost have to do this on purpose ;-))

      --
      Everything I write is lies, read between the lines.
    18. Re:A stupid question... by dgatwood · · Score: 1

      Actually, it is. Your compiling and translation happens at deployment time (or at staging time, hopefully), not during development. With native C++, you pay that penalty over and over again. With PHP and a translator, you develop the thing using normal PHP/Apache and pay that compilation penalty only near the end of the process.

      --

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

    19. Re:A stupid question... by LordLucless · · Score: 1

      @ predates PHP exception handling, and was used for the old method of error handling.

      That said, PHP's error handling in general is annoying, as the built-in functions generally raise errors instead of throwing exceptions. That's an artifact of the way the language changed over time, rather than that it was poorly designed.

      --
      Just because you're paranoid doesn't mean there isn't an invisible demon about to eat your face
    20. Re:A stupid question... by ls671 · · Score: 1

      > The main problem is compilation speed. C++ compilers are just plain slow.

      Are you saying C++ doesn't have development platforms that compile your code in real time as you modify it ?

      I haven't been coding in C++ for a while but I assumed something similar to eclipse was available for C++ developers. Heck, C++ must be supported by eclipse so doesn't it compile the code in real time as you modify it.

      I am just curious, maybe it is harder to acheive this with C++,

      Thanks for answers everybody. ;-)

      --
      Everything I write is lies, read between the lines.
    21. Re:A stupid question... by dgatwood · · Score: 3, Informative

      The @ syntax is not a try/catch. PHP doesn't stop execution when it encounters errors opening files and stuff. It merely blasts a warning message to the output stream (web client). The @ operator suppresses that output. It's equivalent to sending the perror() after a failed fopen() call to /dev/null. Whether the command succeeds or fails, control still returns to your code after the statement. The @ operator merely suppresses the error message generated by PHP so that you can display a more appropriately formatted and/or more useful error message (or not display a message at all if the failure is expected). In a production environment, most people disable the warning output from PHP anyway, making it basically a no-op except during debugging.

      If you folks want an argument against PHP, you're all going about it wrong. Probably the best argument against PHP is that it makes it easy to design yourself into a corner---putting code into the middle of HTML templates that suddenly needs to be able to set a header field and "whoops, that has already been sent", putting code into the middle of templates that needs to change the content up a level, and "whoops, have to add a hack over here to fix that", etc. The result is that for really simple sites, PHP is awesome, but it has real problems scaling to more complicated designs without dropping the templates (or at best, including them on the back end after you do a lot of compute processing up front to set things up, choose a template programmatically, etc.).

      Or you could simply attack it for being a lot slower than C and leading to design patterns that waste lots of memory. For example, associative arrays are simple and easy to use, but 90% of the time, there are much simpler data structures that can do just as well. If your data structures are small, no problem. If you deal with something big, the difference in memory pressure between a clean, lightweight binary tree (even without balancing) and an associative array can result in an order of magnitude impact in performance (or two or three).

      --

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

    22. Re:A stupid question... by mystikkman · · Score: 1

      Were they born PHP coders and can't learn??? Is a language like a race, encoded in you DNA?

    23. Re:A stupid question... by gnud · · Score: 1

      The weak typing is your main concern with PHP? You can make arguments that strong/explicit typing is better, but weak typing is NOT php's problem. The behaviour of array keys is completely consistent with the type system everywhere else in the language, any scalar value can be an array key. By the way, later in your own post you point at dynamic typing as an advantage. Please make up your mind?

    24. Re:A stupid question... by unformed · · Score: 2, Informative

      An experienced java programmer could manage to create memory leaks using threads but you almost have to do this on purpose ;-))

      Wrong. You an have memory leaks in Java just as well. It's just more difficult.

      I'd even go as far to say that experienced people are more likely to cause a Java memory leak, because they'll be doing unusual things for optimizing/caching and what not.

      Usually, this involves Swing and dialogs that were closed and forgotten about, and not properly dereferenced.

    25. Re:A stupid question... by unformed · · Score: 1

      I quoted the wrong line ......

      should have been:

      An INEXPERIENCED java programmer NEVER creates memory leaks,

    26. Re:A stupid question... by MightyMartian · · Score: 1

      I'd like to know what kind of engineers they hire if they need a godawful language like PHP to get them up to speed. If that's the case, maybe they should code in Logo.

      --
      The world's burning. Moped Jesus spotted on I50. Details at 11.
    27. Re:A stupid question... by geniusj · · Score: 1

      Can you not create circular references in Java? I honestly don't know..

    28. Re:A stupid question... by shutdown+-p+now · · Score: 1

      It should be clearly obvious that if you want to use a string as an integer, you use intval to convert it first.

      That wasn't my point. Indeed, if I want to use a string as an integer, I will explicitly convert it myself. So why does it insist on automatically converting "8" to 8 behind my back?!

      It's difficult to fault a language just because it's easy to learn though. PHP is easy to learn, because it does a lot of stuff automatically (casting, error suppression, etc, like you said).

      At some point, doing too much stuff behind programmer's back is outright dangerous. This includes too much implicit casting. And I've never heard anyone complaining about how, say, Python is hard, just because it requires you to convert string to int whenever you need to use a string in int context.

      "Automatic" (not really, since it needs an explicit @) error suppression is just nasty - there are no scenarios where it is a good idea, yet the mere fact of its existence invites people to use it - otherwise why it's even there?

      You end up with a lot of crappy code, but that's not the fault of PHP

      It's a fault of PHP insofar as PHP promotes bad coding practices, by making it easier to write bad code, and harder to write good code. For a high-level language, streamlining good coding practices is absolutely a major design requirement.

      That's what your example shows, printing an error that a file couldn't be opened if the file wasn't able to be opened.

      If a file couldn't be opened, then code should explicitly check for error and provide some fallback - or otherwise die as loudly as possible. Instead, @ hides errors, which makes troubleshooting a headache. Like I said, its intent is equivalent to someone writing this in Java:

      InputFileStream f;
      try {
        f = new InputFileStream("foo");
      } catch (Exception ex) {}

      This kind of thing would be shot down by pretty much any coding style checker in default configuration on the fly (including those built into most modern Java IDEs), and for a good reason.

      No other language I know, other than PHP, has a similar operator or construct specifically for this purpose. Actually, no, not quite - something similar existed in older BASIC dialects, and VB up to version 6 - it was called "ON ERROR RESUME NEXT". And hated just as much by people who cared about writing maintainable code.

      I know that exception handling exists in PHP5. It's good, and it should be used. But @ has no reason for existence.

       

    29. Re:A stupid question... by bill_mcgonigle · · Score: 1

      Were they born PHP coders and can't learn??? Is a language like a race, encoded in you DNA?

      Can they be retrained? Sure, likely, even if they have to learn some CS to jump from PHP to C++. Is it in Facebook's best interest to have non-productive coders for a couple years (it takes about that long to get really good at C++)? No, otherwise they would have have done that.

      Also, PHP coders probably come cheaper on the market than C+ coders.

      --
      My God, it's Full of Source!
      OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
    30. Re:A stupid question... by shutdown+-p+now · · Score: 1

      The @ syntax is not a try/catch. PHP doesn't stop execution when it encounters errors opening files and stuff. It merely blasts a warning message to the output stream (web client). The @ operator suppresses that output. It's equivalent to sending the perror() after a failed fopen() call to /dev/null. Whether the command succeeds or fails, control still returns to your code after the statement. The @ operator merely suppresses the error message generated by PHP so that you can display a more appropriately formatted and/or more useful error message (or not display a message at all if the failure is expected). In a production environment, most people disable the warning output from PHP anyway, making it basically a no-op except during debugging.

      If @ is something that is effectively a no-op in a sane environment, then why is it still in the language after 5 major revisions?

      Perhaps a better question to ask, then, is why opening a file which doesn't exist won't just noisily terminate the application (since all code that follows might assume that file was opened successfully, and is essentially incorrect from that point on), rather than just printing a message to output? How about approaching this problem like, I dunno, it was done 25 years ago, when exceptions first appeared?

      You can say that fopen is designed to return a value indicating failure or success, but if so, then why print an error message?

      It's just bad design no matter how you look at it. If you want a decent one, fopen() should throw if it can't find the file, and an extra function with a name that clearly indicates intent - say, try_fopen() - shouldn't throw, but should indicate failure by means of return value.

    31. Re:A stupid question... by geniusj · · Score: 1

      Since they only cut their CPU usage by 50%, I'm guessing that the gains they got were a mere taste of what they would get with hand-written/optimized C++ code. But, that's not to say it would've been worth their time to do so..

    32. Re:A stupid question... by shutdown+-p+now · · Score: 1

      That's an artifact of the way the language changed over time, rather than that it was poorly designed.

      PHP5 was already a breaking revision of the language; they could have just as well taken care of that bit.

      In any case, historical reasons or not, today it's a bad design when compared to virtually all modern alternatives, and that's what matters in the end.

      Note, I'm not saying that every single line of PHP code should be rewritten tomorrow. I'm a pragmatist, and if there's an existing, working code base written in PHP - by all means, use it, maintain it, and extend it. But, for God's sake, let's use modern, better-designed languages for new, from-scratch projects. Think of the code maintainers!

    33. Re:A stupid question... by tukang · · Score: 1

      Oh, I also don't know of any other language that has what effectively amounts to synactic sugar for try/catch with an empty catch block [php.net]. Good programming practices FTW!

      What you linked to is nothing more than short circuit evaluation, which nearly every programming language in existence supports. http://en.wikipedia.org/wiki/Short-circuit_evaluation

    34. Re:A stupid question... by abulafia · · Score: 3, Insightful

      No, I think I'll stick with attacking it for being a truly crappy language. I don't care that it is slow or wastes memory. If you're paying$20/month for your dance-school-business-calendar installed and customized by a local teenager, the idea of writing a web app in C is silly for efficiency is silly. Likewise, whatever the intent of @ is for, I most certainly expect people have and will abuse it in exactly the way described to "fix" problems. People endlessly bash, for instance, Perl as being write only, and there's truth to that. But there is truth to that because the language tends to encourage hard to read code. You can say that's not the intent, and you'd be right, but that doesn't matter. (Though I do still love Perl.)

      I do agree that PHP is fine for toy web sites, and that people get themselves in trouble using the executable web page model because the don't know what they're doing. These things are true for the same reason: PHP is full of poorly thought out magic that allows people to get in over their head, and doesn't provide the tools to easily dig back out. I'm all for making programming more accessible, but encouraging people to foot-bullet themselves in predictable ways doesn't strike me as a good approach.

      I dislike it for other reasons, but for instance Ruby on Rails is a much more solid approach, in my opinion - the path of least resistance is generally the right thing to do, once a newbie internalizes the MVC idea and a couple conceptual points the learning curve is pretty gentle, and Ruby is a pretty well constructed language that lets people grow into using more conceptually useful techniques over time without the up-front demands of learning, say, Lisp.

      (While I'm chasing people off my lawn, the whole RoR mindset seems to lead people down a rabbit hole of writing dumb little DSLs -- who on earth thinks a toy language for generating CSS is a good idea? You just push yourself one more indirection layer away from what's going on and end up dinking around with yet another silly new syntax for your effort. Muppet coding at its worst.)

      --
      I forget what 8 was for.
    35. Re:A stupid question... by psycho12345 · · Score: 1

      No, the garbage collector detects that, and frees the memory accordingly. It keeps track whether an object can be reached my the main program or not.

    36. Re:A stupid question... by shutdown+-p+now · · Score: 1

      The weak typing is your main concern with PHP? You can make arguments that strong/explicit typing is better, but weak typing is NOT php's problem. The behaviour of array keys is completely consistent with the type system everywhere else in the language, any scalar value can be an array key. By the way, later in your own post you point at dynamic typing as an advantage. Please make up your mind?

      "Weak typing" and "dynamic typing" are two distinct concepts. For example, Python is dynamically typed, but it is also strongly typed.

      Dynamic typing means that variables don't have types, only values do. The opposite - when variables have types, and can only be bound to values of matching types - is static typing.

      Strong typing means that but you (generally) cannot randomly treat a value of one type as another type - with the exception of subtyping, and a few well-established conversions (such as int/float). I don't mind dynamic typing (well, actually, I do, but in this context it's irrelevant, and in any case it has its place). I do mind weak typing, which is the opposite of this - when a string is suddenly treated as an integer, depending on the context.

      But, really, my beef with PHP isn't even with that. The problem is that this particular case of associative array indices is ambiguous from weak typing perspective: you can either treat all integers as strings, or all strings as integers. In fact, the former option is more rational, because any integer can be treated as as string, but not any string can be treated as an integer (and that's what JS does).

      In general, however, there's no clearly preferable option here, so a sanely designed language, even with weak typing, would complain about ambiguity, and require explicit disambiguation by the programmer.

      Alternatively, associative arrays can just treat values of different types as different, even if they could compare equal after applying some conversions - Lua does it that way, and this is by far the best approach.

      Also, this conversion for array indices is actually not consistent with the rules for the rest of the language, because it differs with respect to conversion rules. Specifically:

      $x = "8" + 1; // "8" is treated as number 8
      $a["8"] = 1; // "8" is treated as number 8
       
      // So far so good, but...
       
      $x = "08" + 1; // "08" is treated as number 8
      $a["08"] = 1; // "08" is NOT treated as number 8
       
      $x = "1.2" + 1; // "1.2" is treated as number 1.2
      $a[1.2] = 1; // 1.2 is rounded to 1
      $a["1.2"] = 1; // "1.2" is NOT treated as 1.2 (and not rounded to 1)

    37. Re:A stupid question... by shutdown+-p+now · · Score: 1

      What you linked to is nothing more than short circuit evaluation

      I linked to the description of PHP operator @, which has nothing to do with short-circuit evaluation. I assume you've seen the example in linked documentation article, which uses the common "... or die()" idiom, but the article itself isn't about that, and it was not what I was referring to.

    38. Re:A stupid question... by abulafia · · Score: 1

      Um, no. The page also illustrates an example of short-circuit evaluation, and it might be looked at as a serving suggestion to go along with '@', but the use of '@' syntax is to suppress error notification.

      --
      I forget what 8 was for.
    39. Re:A stupid question... by ls671 · · Score: 1

      > Usually, this involves Swing and dialogs that were closed and forgotten about, and not properly dereferenced.

      This is very new to me !!!

      In Java, you do not "dereference" (e.g. myobject = null ). Read on how the garbage collector works. People recommending to do "myObject = null" usually do not know what they are talking about although I have seen it many times...

      Here is an example:

      if ( true) {
          Object myObject = new Object();
      } // myObject will be garbage collected here and the memory will be freed...

      code continues...

      --
      Everything I write is lies, read between the lines.
    40. Re:A stupid question... by LordLucless · · Score: 1

      PHP5 was already a breaking revision of the language; they could have just as well taken care of that bit.

      PHP5 didn't break that much of the language, but I agree, it should have been changed then.

      Even so, saying that @ is syntactic sugar for an empty try-catch is misleading.

      --
      Just because you're paranoid doesn't mean there isn't an invisible demon about to eat your face
    41. Re:A stupid question... by oldhack · · Score: 1

      Give them a break. PHP started out as an alternative to server-side ASP.

      C++ has to be the worst example of scope-creep. I mean, there is no such thing as a single "C++" - each shop has its own flavor of C++ that are not mutually intelligible.

      --
      Fuck systemd. Fuck Redhat. Fuck Soylent, too. Wait, scratch the last one.
    42. Re:A stupid question... by dgatwood · · Score: 1

      I disagree. PHP actually does the right thing for a web-based service, IMHO. End-user errors are useful for end users during the deployment phase. The PHP debug output messages are useful info for developers during debugging because most of the failures are caused by a typo you made five minutes earlier. They're basically two sides of the same coin. Sure, you could print your own error message with more or less info depending on whether you're in debug mode or not, but that's a good bit of extra coding effort for no real gain over the way PHP works now.

      --

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

    43. Re:A stupid question... by Rufty · · Score: 1

      PHP, like duct tape. Handy for a quick'n dirty fix, but slightly worrying when used as the main structural element in a skyscraper...

      --
      Red to red, black to black. Switch it on, but stand well back.
    44. Re:A stupid question... by shutdown+-p+now · · Score: 1

      Give them a break. PHP started out as an alternative to server-side ASP.

      Hah, don't even get me started on language design issues of VBScript...

      But, see, there's a difference between those two - namely, ASP is dead, and PHP is still not. All I want is some equality there. ~

      (As a side note, ASP actually permitted usage of some languages more sane than PHP out of the box - notably JScript - and you could also get something really nice like ActiveState PerlScript.)

    45. Re:A stupid question... by styrotech · · Score: 1

      The weak typing is your main concern with PHP? You can make arguments that strong/explicit typing is better, but weak typing is NOT php's problem. The behaviour of array keys is completely consistent with the type system everywhere else in the language, any scalar value can be an array key. By the way, later in your own post you point at dynamic typing as an advantage. Please make up your mind

      Regarding the "make up your mind bit"

      Weak typing doesn't have to mean dynamic typing. The weak <-> strong axis is somewhat orthogonal to the dynamic <-> static axis.

      Dynamically typed languages can still be weakly or strongly typed. eg PHP lets you compare or add different types and (for example) Python doesn't.

      I'm less familiar with statically typed languages but I'm sure there are examples of weak and strong with statically typed languages too.

    46. Re:A stupid question... by larry+bagina · · Score: 1
      About @ ... There's only one reason I've used it.

      let's say you might have a cookie or post variable. Maybe it's there, maybe it's not. With perl or javascript, an undefined variable is undef (or undefined). In PHP, it's an error. x = @$_POST['x']; is a shortcut for x = isset($_POST['x']) ? $_POST['x'] : '';

      It kind of reminds me of references. Most language designers would pass objects and arrays by reference. But the PHP guys thought (?) it would be better to pass by value.And return by value. Even from constructors. Somebody eventually pointed out that was stupid, so they added references (&). But references aren't pointers to data, they're pointers to an entry in the symbol table or something equally bizarre. PHP 5 got slightly more reasonable so objects are always passed (and returned) by reference.

      --
      Do you even lift?

      These aren't the 'roids you're looking for.

    47. Re:A stupid question... by Capt.+Skinny · · Score: 1

      Perhaps a better question to ask, then, is why opening a file which doesn't exist won't just noisily terminate the application (since all code that follows might assume that file was opened successfully, and is essentially incorrect from that point on

      Well, a PHP application doesn't noisily terminate when opening a nonexistent file -- so why would the code that follows assume the file was opened successfully? Properly written, the code wouldn't assume anything that wasn't guaranteed by the language.

    48. Re:A stupid question... by LingNoi · · Score: 0

      PHP has try {} catch (){} blocks so I don't know why you, the GP and the GGP think that @ (used to suppress error messages) is the PHP equivalent.

      Also PHP isn't a language for "toy websites". Facebook with its daily 152 million users isn't a toy website. Also MVC isn't restricted to Ruby on Rails, there are plenty of PHP apps that use it too.

    49. Re:A stupid question... by ls671 · · Score: 2, Informative

      > It keeps track whether an object can be reached my the main program or not.

      Not really the main program but more precisely a running Thread.

      A running Thread might be unreachable from the main program which could potentially cause memory leaks as I have mentioned in another post.

      To cause memory leaks in Java: Fork some Threads which use a bunch of objects and do not keep any reference to the Threads in the main program.

      The correct way to do this is to keep references to the running Threads in the main program and to cause them to terminate when the main program wishes them to.

       

      --
      Everything I write is lies, read between the lines.
    50. Re:A stupid question... by MightyMartian · · Score: 1

      PHP is a just plain awful language. Its success is the same as BASIC's was, it allows novices to get on the bus fairly quickly, but at that point, if they don't have some grounding in sound coding practices, and are unaware of the language's pitfalls, the whole thing radically devolves into a disaster area. To be honest, I think VB6 was a better thought out language.

      Then, apart from the language's peculiar oddities (as you point out), there is that library. I'm having a hard time figuring out whether the developers are malicious Satan worshipers out to control the world, or they are mental retards, but I've seen two year olds put more effort into making sure like-colored Lego blocks go together than in what the PHP library developers did into a rational and consistent library.

      I spend half my time whenever I'm forced to code in PHP just trying to figure out whether I've done function parameters correctly. With a well thought out library, like your average C library is, after a bit of practice, you can get the feel for things, and you're not constantly have to shift gears (some string functions are like this, except those ones!!!) It makes coding so bloody inefficient and bug prone, but because they have billions of lines of legacy code to support, they can't fix it, or if they do, it's through the php.ini file, which grows on a logarithmic scale with each new release as you try to pick and choose the options that hopefully will make an application move to a newer version.

      I'm currently forced to support two web apps written in PHP. One, while cnostructed pretty bizarrely, I can make some sense of, and is reasonably well coded. The other is an abomination. When we moved it to new servers, we spent about four hours just trying to get the bloody thing running. In either case, I have made it a long-term recommendation that we need to rewrite, and hopefully in a language that can be maintained in the long term without a loss of sanity.

      --
      The world's burning. Moped Jesus spotted on I50. Details at 11.
    51. Re:A stupid question... by Anonymous Coward · · Score: 0

      Not all of them, but a lot of PHP monkeys like to think imagine they're much more hard-core than they are, so they compare what they do to what they perceive as a "real" language.

      Yeah and the rest of the PHP monkeys know that "real" languages, not matter how well they get the job done, will never compare to the enormous E-Penis size of Perl, Python or Ruby.

    52. Re:A stupid question... by Snover · · Score: 1

      Or you could simply attack it for being a lot slower than C and leading to design patterns that waste lots of memory. For example, associative arrays are simple and easy to use, but 90% of the time, there are much simpler data structures that can do just as well. If your data structures are small, no problem. If you deal with something big, the difference in memory pressure between a clean, lightweight binary tree (even without balancing) and an associative array can result in an order of magnitude impact in performance (or two or three).

      The SPL in PHP 5.2 and 5.3 adds a few new datastructures to help improve that (benchmark).

      --

      [insert witty comment here]
    53. Re:A stupid question... by shutdown+-p+now · · Score: 1

      If the intent of fopen() is to report success/failure of opening the file in its return value, then it shouldn't print an error message by the same logic. If it prints an error message but doesn't terminate, it seems like the worst of both worlds to me - it's either an error or not, make up your mind...

    54. Re:A stupid question... by shutdown+-p+now · · Score: 1

      To be honest, I think VB6 was a better thought out language.

      Not really, no. It's hard to beat such VB6 gems as the distinction between "Let" and "Set" assignment operators, for example. Or implicit conversion via default properties. Or "On Error Goto ... / Resume Next" (and no other ways to do error handling). Or the entirely inconsistent syntax, where half of the standard library were proper functions, and other half had special syntax (such as "Open .. For .. As" or "Rename .. As ..").

      But VB6 is long dead and buried, and VB.NET fixed pretty much all design defects in the language (except perhaps for excessive wordiness, but whether that is a defect is subjective).

      because they have billions of lines of legacy code to support, they can't fix it, or if they do, it's through the php.ini file, which grows on a logarithmic scale with each new release as you try to pick and choose the options that hopefully will make an application move to a newer version.

      The monstrosity that is php.ini, and specifically those parts of it that actually change the language semantics, effectively producing a different dialect, deserve its own separate treatment that would probably be twice as large as my original post in this thread. But I'll leave it to someone more experienced in it to expose the innocent minds to that horror story.

    55. Re:A stupid question... by Unequivocal · · Score: 2, Insightful

      I've run across quite a few ignorant Ruby libraries that leak memory like sieves. Most Ruby on Rails applications have to reboot once a day if they are well written and way more often than that if they aren't. High level languages can leak like crazy, same like low level languages - this whole topic is wack.

      Low level languages like C and ASM are vulnerable to executing data instead of code -- cf. Microsoft windows from day 1.

      I can't figure out why people are comparing memory leaks from one language to another. Everything leaks as soon as you put it in the hands of an average joe programmer. Move along, nothing to see here.

    56. Re:A stupid question... by Unequivocal · · Score: 1

      This reminds of @echo off from DOS. Hmm.

    57. Re:A stupid question... by abulafia · · Score: 1

      Ladies and gentleman,

      A Way To Miss The Point, illustrated.

      Next up, LingNoi will point out that they included no pictures in their brilliant takedown, so it wasn't illustrated.

      --
      I forget what 8 was for.
    58. Re:A stupid question... by dgatwood · · Score: 1

      It's an error that you should be checking for. It's also a warning message that provides useful details when debugging but provides filesystem layout info that should not be exposed when deploying. By gating the decision off the server configuration, you have an extra measure of security, albeit mostly through obscurity.

      Case in point, when I'm processing an image file, I also look to see if there's a file in the same folder called foo.jpg.rot and if so, I parse it for rotation information. If that open fails, I use the default values. I certainly could avoid it by wrapping the whole block in an explicit "if (file_exists){" block, but that adds an extra nesting level, and I still need to check to see if the open succeeded just in case there's a permission problem on the server. Adding the "@" means that I can just let the fopen call fail, skip reading from it, and move on even when debugging, confident that the warning messages from PHP on that particular call are more likely to be bogus than real.

      Because it is only disabled on a one-off basis, though, I still get the advantage of PHP spewing a warning message that contains the full path to the file for other failed calls to fopen. So when the subsequent write of that file (with filled-in default data) fails because the enclosing directory doesn't exist due to some path translation error, I know about it, and I can quickly take action without having to add additional debug statements to obtain the full path info.

      In deployment, those warning messages go away entirely, and if the subsequent open for writing fails, the function cleans up and returns a simplified error message that indicates that changes to the rotation could not be saved, but does not provide a complete filesystem path that the user doesn't care about (and really shouldn't know anyway).

      That's just one example, but the pattern holds for pretty much anything in programming. There's a lot of debug info when certain calls fail that can be useful while debugging but that is not so useful in the deployment stage. Think of it as the equivalent of setting the logging level to LOG_DEBUG in syslogd.conf and it should make a lot more sense.

      --

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

    59. Re:A stupid question... by shutdown+-p+now · · Score: 1

      Case in point, when I'm processing an image file, I also look to see if there's a file in the same folder called foo.jpg.rot and if so, I parse it for rotation information. If that open fails, I use the default values. I certainly could avoid it by wrapping the whole block in an explicit "if (file_exists){" block, but that adds an extra nesting level, and I still need to check to see if the open succeeded just in case there's a permission problem on the server. Adding the "@" means that I can just let the fopen call fail, skip reading from it, and move on even when debugging, confident that the warning messages from PHP on that particular call are more likely to be bogus than real.

      Because it is only disabled on a one-off basis, though, I still get the advantage of PHP spewing a warning message that contains the full path to the file for other failed calls to fopen. So when the subsequent write of that file (with filled-in default data) fails because the enclosing directory doesn't exist due to some path translation error, I know about it, and I can quickly take action without having to add additional debug statements to obtain the full path info.

      It's a valid use case, but as you describe it, it means that every time you actually want to check the return value of fopen(), you use @ anyway. So whenever you use fopen() without @, you're effectively asserting that the file exists, and the following code will not have any checks (otherwise you'd use @ to avoid the warning message). If so, why isn't the use of fopen() without @ not a critical error that will prevent the following code from running, terminating the application - for example, by throwing an exception (as it happens in e.g. Java, C#, Python...)?

      That's just one example, but the pattern holds for pretty much anything in programming. There's a lot of debug info when certain calls fail that can be useful while debugging but that is not so useful in the deployment stage.

      I agree that there are definitely some functions that could meaningfully "succeed with a warning", but I don't think that fopen() can reasonably be one of them by default.

    60. Re:A stupid question... by LingNoi · · Score: 0

      I have no idea what your response is going on about however so far you haven't pointed out anything interesting. I'm not saying PHP is great but the example you gave "@" is not a major language switching issue.

      Either way it matters not. You are in the minority. People who are using PHP aren't going to switch because of your weak arguments. This article just proves that.

      I suggest to look at newer versions of PHP because your information is outdated.

    61. Re:A stupid question... by keithpreston · · Score: 1

      An experienced C++ programmer rarely creates memory leaks, and they are easily detected by a variety of tools.

      The REAL problem is that for every good experienced C++ program that doesn't leak memory, that same company has 10 who will. Tools and testing are really the only way.

    62. Re:A stupid question... by 0100010001010011 · · Score: 1

      The main problem is compilation speed. C++ compilers are just plain slow.

      Best reason in the world to slack off at work

    63. Re:A stupid question... by dgatwood · · Score: 1

      It's a valid use case, but as you describe it, it means that every time you actually want to check the return value of fopen(), you use @ anyway. So whenever you use fopen() without @, you're effectively asserting that the file exists, and the following code will not have any checks (otherwise you'd use @ to avoid the warning message). If so, why isn't the use of fopen() without @ not a critical error that will prevent the following code from running, terminating the application - for example, by throwing an exception (as it happens in e.g. Java, C#, Python...)?

      No, no, no. I check the return value every time, whether I use "@" or not. The return value check is for displaying a sensible message to the end user. In deployment, the PHP-generated message is *always* suppressed, "@" or no "@", so the return value check must always be there for every call.

      I use "@" to suppress the PHP-generated debug message during development for specific calls where the failure is expected/harmless so that my HTML layout isn't hopelessly broken by those bogus warnings. They're suppressed because of the high false positive rate on that particular call. I omit the "@" on most calls because they should not fail even during development. That way, I get the detailed debug info during testing.

      Either way, in the deployment phase, the "@" effectively occurs for every call, and the only error output comes as a result of checking the return value and generating a user-centric message.

      If so, why isn't the use of fopen() without @ not a critical error that will prevent the following code from running, terminating the application - for example, by throwing an exception (as it happens in e.g. Java, C#, Python...)?

      Because in deployment, that's the last thing you'd want. You want to trap the bad return value and display a user-friendly "Your changes could not be saved" formatted to match the site rather than "Java.lang exception blah blah blah" in black text on white or whatever.

      Also, I generally need to identify that something went wrong as close as possible to the call because that's the only part of the code that knows precisely what was happening at the time, and thus that's the only place where a precise error message can be generated. It is also often necessary to roll back earlier operations when one part of a complex operation fails. That's not possible except right at that point in the code. If I can't just let the exception bubble up very far in my call stack, then there is no real advantage to using an exception over a return value.

      Finally, I usually don't care why a call failed outside of the debug environment. I only care that it failed. With return values, I can typically handle every possible failed exit status with a single if statement. With exceptions, depending on how the particular function was designed, it can require multiply-nested try/catch blocks, one for each class of exceptions, all of which then have to set some flag so that later in the function you can treat each of them as being the same fundamental failure (or add an unnecessary function call whose sole purpose is to call the exception-throwing function, catch the exception, and return an exit status).

      Also, exceptions are, in my opinion, simply a bad programming practice that leads to sloppy, buggy, insecure programming.

      http://www.joelonsoftware.com/items/2003/10/13.html
      http://silkandspinach.net/2005/06/14/exceptions-considered-harmful/
      http://blogs.msdn.com/larryosterman/archive/2004/09/10/228068.aspx

      --

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

    64. Re:A stupid question... by SirSlud · · Score: 1

      Shooting one's self in the foot is an allegory borne of a device with one button. If enough people fuck that up that it becomes an allegory, then I don't know what language doesn't let you do that.

      Let's be realistic here. Perl is great, but also for every unqualified PHP programmer, there is a much smarter Perl programmer who's made more unmaintainable code. I think too many programmers approach their languages of choice as if the clarity of the syntax isn't really an issue.

      Yes, PHP is a saturday night special language. But it's easy to follow/teardown/refactor. My experience with Python and Perl contains a lot more situations where it's nearly impossible to spot the dependencies of code.

      There's no perfect language. I work in C++ on game consoles, and everyone is capable of shooting themselves in the foot no matter if you're down deep in VMX assembly or up there with Visual Basic. PHP is fine for what is designed for, and I personally think it's rather capable, despite its 'amateur' language design, for large scale web applications. In other words, if you're capable of learning how to use Ruby properly, the same can be done with PHP.

      It's rather telling that you finish off your post with a mini-rant of people abusing Ruby. Don't hate the game, hate the player.

      --
      "Old man yells at systemd"
    65. Re:A stupid question... by twostix · · Score: 1

      In the 90's people used to make exactly the same types of comments about Perl. Perl and Perl Devs were the whipping boy of the language snobs.

      Now PHP has stomped Perl into the dirt, for very good reasons IMO having written many CGI apps and maintenance / glue scripts with Perl for many years. Now that PHP is the new king of the useful / accessible language world somehow Perl has become something "great". Apparently being sidelined and teetering on obsolescence now makes it something wonderful. So great that nobody uses it anymore in any real sense except purely due to a small amount of inertia and a fraction of server side maintenance scripts that are now quickly being eaten by Python and ... PHP/CLI.

      Perl is just as much of a mess as PHP, though in different ways and most who whinge about PHP are just used to Perls BS and don't even notice it anymore.

      The fact of the matter is PHP *is* one of the most productive languages around otherwise it wouldn't have absolutely blown Perl away in less than 4 years from when it was introduced. For years hosting companies used to have Perl and only Perl available, now it's not even on the radar. Yes PHP is simple, it's easy to program in, easy to maintain (even the worst PHP is better than most average Perl code I've ever had to delve into over the years) and of course inherently easy for noobs to write dodgy broken applications in.

      Python and Ruby will always be niche as they are developed by ideology, not by practicality.

      The @ symbol suppresses warnings, just like programming in Perl without -w. And in 11 years I've never seen it used as a "try catch block" and I've seen a hell of a lot of code, which makes me understand that you've never actually programmed in PHP and are just regurgitating off old troll lists. Also PHP has had exceptions for over half a decade now...

      Finally PHP doesn't need to be compared to Perl or Python or Ruby, it's now at a place and running some of the biggest sites in the world along side Java a place where Perl once was and Python and Ruby will *never* be. (How's that performance going Ruby?).

      Such is the state of reality at this point from a Java first / PHP second / Occassional-Python (the more I use it the less I like it) Assembly for microcontrollers, very Ex-Perl programmers point of view.

      Flame on!

    66. Re:A stupid question... by dgatwood · · Score: 1

      PHP 5 got slightly more reasonable so objects are always passed (and returned) by reference.

      PHP 5 is pretty neat. Too bad there weren't any prequels.

      --

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

    67. Re:A stupid question... by dgatwood · · Score: 1

      Neat. When I was dealing with that, PHP was still in 5.0, or maybe 5.1. Still, good to know.

      --

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

    68. Re:A stupid question... by abulafia · · Score: 1

      No, it is rather telling that you're attacking ruby after spending a lot of time promoting Microsoft. I don't actually care. I want more, and faster, web apps. That is not only good for me, but I think it is good for the world.

      I think you are, bluntly, wrong. I can tell you how I traced a function though the generally accepted method of inserting a link to the navigation bar for a client. It involved modifying code. Now, you can tell me that I'm wrong about how it happened. But people keep telling me I'm silly for being concerned with actual outcomes. Tell me: which is it? I'm a software guy. You folks, fight it out. Not my business. But how do I not notice that certain companies seem to pay more attention to particular outcomes than others?

      --
      I forget what 8 was for.
    69. Re:A stupid question... by abulafia · · Score: 1

      No, it is rather telling that you're attacking ruby after spending a lot of time promoting Microsoft. I don't actually care. I want more, and faster, web apps. That is not only good for me, but I think it is good for the world. I think you are, bluntly, wrong. I can tell you how I traced a function though the generally accepted method of inserting a link to the navigation bar for a client. It involved modifying code. Now, you can tell me that I'm wrong about how it happened. But people keep telling me I'm silly for being concerned with actual outcomes. Tell me: which is it? I'm a software guy. You folks, fight it out. Not my business. But how do I not notice that certain companies seem to pay more attention to particular outcomes than others?

      --
      I forget what 8 was for.
    70. Re:A stupid question... by shutdown+-p+now · · Score: 1

      Because in deployment, that's the last thing you'd want. You want to trap the bad return value and display a user-friendly "Your changes could not be saved" formatted to match the site rather than "Java.lang exception blah blah blah" in black text on white or whatever.

      Yes, of course. But if I forget to check for error, I want the thing to blow up immediately (and then I have the standard error page for uncaught exceptions), rather than it continue to execute when system is in invalid state, and all bets are off.

      Also, exceptions are, in my opinion, simply a bad programming practice that leads to sloppy, buggy, insecure programming.

      Nonetheless, they're mainstream - have you considered the reason as to why? Of course, I could easily google up links that argue to the contrary (especially that article by Joel, which was thoroughly debunked)...

      In any case, that's not the point here. I'm not arguing about exceptions vs return codes. I'm arguing about printing a "debug message" on error, and blowing up.

    71. Re:A stupid question... by inKubus · · Score: 1

      Most of what PHP does is written in C and C++. As a scripting language, PHP relies on extensions. In general these are C libraries. Yes, you have some glue that is JIT and slow but for heavy lifting like database queries or graphics or whatever you're already in C. Like I do some graphics stuff using PHP to render the page, but all the gd_xxx() functions are calling directly to the gd extension which implements calls to the GD library which is either statically compiled or in shared memory. Yes, the for loop code is compiled into opcodes and run but I also use APC which caches the opcodes so it just gets run. I'm not going to run around and claim that PHP is the best or fastest but it's good at what it does, which is be a glue around C libraries. And the new version is pretty good with object orientation. Also check out Zend Framework which is really the only professional framework for PHP. MVC, lots of other stuff. It's quite good now (it wasn't a year ago). There's even a debugger extension for the apache module so you can run a firefox extension like firebug or their debugger toolbar and debug right on the production server (uses SSH to talk to the runtime)

      --
      Cool! Amazing Toys.
    72. Re:A stupid question... by shutdown+-p+now · · Score: 1

      In the 90's people used to make exactly the same types of comments about Perl. Perl and Perl Devs were the whipping boy of the language snobs.

      Perl was rightly whipped, but it was whipped for different things. There was some intersection (as in, dubious design decisions promoting unmaintainable code), but in general, Perl got the flak because it had too many ways to do the same thing. As far as consistency goes, though, I don't think it's an issue there. It's complex (and consequently powerful), but it's consistent. PHP is not complex, but it's not consistent either.

      The fact of the matter is PHP *is* one of the most productive languages around otherwise it wouldn't have absolutely blown Perl away in less than 4 years from when it was introduced.

      PHP didn't blow Perl away - by the time PHP was strong, Perl was long blown away by ASP and (raw) JSP - and PHP killed those two, because they were too primitive, yet at the same time too heavyweight, specifically with respect to web development, in comparison.

      Python and Ruby will always be niche as they are developed by ideology, not by practicality.

      The ideology of Python is practicality, that's practically what the entire language is about. Practicality, however, includes such not quite obvious bits as writing maintainable code by default - it's utterly practical, but unfortunately often ignored. PHP became popular among that crowd in particular because it made it easy to ignore such matters, and focus on cranking out KLoCs.

      Then also, Python - a niche language, really? Why don't you go tell Google? or, say, RedHat?

      Finally PHP doesn't need to be compared to Perl or Python or Ruby, it's now at a place and running some of the biggest sites in the world along side Java a place where Perl once was and Python and Ruby will *never* be.

      There used to be that insanely popular language for developing in-house desktop applications - went by the name of Visual Basic. Version 6 was especially huge.

      Then 2002 came, and that little thing called ".NET Framework" was released. And where are those coders who thought VB is so good (well, it must be good because it's so popular, surely?) it'll never end? Well, the smart ones moved on. Those even smarter saw the writing on the wall with Java, and already had all knowledge necessary to jump ships as soon as C# arrived. The rest? Signing petitions to bring back their days of glory.

      Let that be a warning to all of us.

      Such is the state of reality at this point from a Java first / PHP second / Occassional-Python (the more I use it the less I like it) Assembly for microcontrollers, very Ex-Perl programmers point of view.

      In my 8 years of experience, I've seen huge code bases of C++. They aren't going away any time soon. New stuff? So long as it's on Windows, it's mostly .NET - and you'd be surprised as to how many of that is out there, even if you go by the stats.

      PHP is huge, no doubt, but it's not the only big player.

      And, yes - Python and especially Ruby are catching on fast, specifically on the web. Elsewhere it wasn't even a contest, as there wasn't anything as sucky as ASP for PHP to come and kill with a slow poke there; and on its merits, it can't really win against the alternatives.

      I mean, how many GUI apps written in PHP have you seen? how many of them didn't suck?

      Now ask the same about Python.

    73. Re:A stupid question... by dgatwood · · Score: 1

      have you considered the reason as to why?

      I have some ideas, and none of them inspire confidence. :-D

      --

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

    74. Re:A stupid question... by Firehed · · Score: 1

      True, but it's one line of code to convert all of the traditional errors into instead throwing ErrorExceptions (set_error_handler(create_function('$a, $b, $c, $d', 'throw new ErrorException($b, 0, $a, $c, $d);'), E_ALL); - incidentally, this breaks use of @ error suppression).

      If you're using @ in a couple of select places, it's quite handy - especially when dealing with stuff that's outside of your control (talking to external APIs which may be offline, for example). But I'm sure there's no shortage of crappy code out there as a hack to get around actual bugs in the code.

      --
      How are sites slashdotted when nobody reads TFAs?
    75. Re:A stupid question... by Firehed · · Score: 1

      Languages aren't insecure, bad code is. It's not PHP's fault that people use it to write bad code.

      Ok, it is, but some language has to be one of the easiest to learn. And the language that has a lot of newbies in it will tend to have the most bad code written in it. Any language will allow you to (for example) use unfiltered GET/POST values in a SQL query; it's the programmer's fault for being dumb enough to do so.

      --
      How are sites slashdotted when nobody reads TFAs?
    76. Re:A stupid question... by ensignyu · · Score: 1

      Just to nitpick your example, the object doesn't get garbage collected immediately in Java. Once it's no longer referenced, it just becomes eligible for collection, and the garbage collection happens later when the virtual machine needs to clear up some heap space.

      That's particularly important if your object is holding on to external resources, like forgetting to close file i/o streams before unreferencing the object. If the garbage collector isn't smart enough, you could run out of file descriptors before it runs a garbage collection.

      On the other hand, some reference-counted languages do free objects at the exact moment that you set the variable to null. And smart pointers in C++ may free the object as soon as it goes out of scope, as in your example. As opposed to Java, where it's difficult to predict when exactly the memory is going to get freed.

      Finally, the idea of setting a variable to null has some merit in certain circumstances (although it's not necessary most of the time, as you pointed out). If you have code like this:

      int [] bigObject = new int[1000000];

      while ( somethingReallySlow() ) {
              doStuff();
      }

      Then bigObject may not get freed for a long time.

    77. Re:A stupid question... by MightyMartian · · Score: 1

      Do a search through php.ini. I'll freely admit that the PHP developers have cleaned up their act, but the history of just how moronic those developers were is written there.

      --
      The world's burning. Moped Jesus spotted on I50. Details at 11.
    78. Re:A stupid question... by Anonymous Coward · · Score: 0

      There is a cyclic reference GC in PHP 5.3, but apparently not enabled by default
      http://php.net/gc_enable

    79. Re:A stupid question... by LordLucless · · Score: 1

      Yeah, and I use that (or similar) in all my PHP stuff. It's still a bit of a hack. Not as bad as most, but something that really should be just in the language.

      --
      Just because you're paranoid doesn't mean there isn't an invisible demon about to eat your face
    80. Re:A stupid question... by ls671 · · Score: 1

      All what you say is correct with one subtle nuance;

      Java coding guidelines states to specifically close() things like files and sockets as soon as you are done with them so there is no risk of running out of file descriptors like you are suggesting when coding in Java if you follow the guideline. The "close()" call is mapped to the underlying OS call so the file descriptors are freed before garbage collection.

      It's a well known fact that you should not rely on garbage collection to free resources like files or sockets although garbage collection usually takes care of closing the sockets.

      Plain JDBC apps that rely on garbage collection to close a SQL connection only in one spot in the whole program can typically open 100 or 200 connections to the database before garbage collection runs and close them ;-)))

      By the way, files and sockets getting closed by garbage collection have a lot less to do with "how smart the garbage collector is" than it has to do with the programmer overwriting the finalize() method of its object in order to free resources used by the said object.

      Again, one should never rely on garbage collection to close resources that maps to a OS resource like a file or a socket, but close() it explicitly when done with it but here is the finalize() method in java.io.FileInputStream() anyway ;-)

      protected void finalize() throws IOException {
          387 if ((fd != null) && (fd != fd.in)) {
          388
          389 /*
          390 * Finalizer should not release the FileDescriptor if another
          391 * stream is still using it. If the user directly invokes
          392 * close() then the FileDescriptor is also released.
          393 */
          394 runningFinalize.set(Boolean.TRUE);
          395 try {
          396 close();
          397 } finally {
          398 runningFinalize.set(Boolean.FALSE);
          399 }
          400 }
          401 }

      --
      Everything I write is lies, read between the lines.
    81. Re:A stupid question... by shutdown+-p+now · · Score: 1

      Yup, Slashdot swallowed a single character in my post, inversing its meaning. It was supposed to read:

      At that point, you can still get reference cycles (which are also leaks), but you can do that in PHP <5.3

    82. Re:A stupid question... by shutdown+-p+now · · Score: 1

      Also, PHP coders probably come cheaper on the market than C++ coders.

      Give this gentleman a gold star, someone. This right here is the sole reason why PHP is as popular as it is (it got popular for different reasons initially, but that's what is sustaining its popularity now).

      You can, of course, substitute C++ with Java/C#/Ruby/... as needed.

    83. Re:A stupid question... by duncanFrance · · Score: 1

      You're joking right? From the php docs:

      >> Return Values

      >> The integer value of var on success, or 0 on failure. Empty arrays and objects return 0, non-empty arrays and objects return 1.

      I certainly do not use intval ever in inline code - I use my own class method that will throw an exception if I'm trying to take the intval of something which is not the string representation of an integer.

      Good God, they could at least have made intval() return FALSE on failure but not 0!!!

    84. Re:A stupid question... by 1110110001 · · Score: 1

      In the integer case the type doesn't matter. '7' == 7 == ('7' + 0) == (7 . ''). If you look at how arrays are stored use an int as key isn't such a bad idea.

      If you have '07' you would lose the leading zero.

      BTW: I used 07 instead of 08 as numbers written as literal are treated as octal if they start with a zero.

    85. Re:A stupid question... by Anonymous Coward · · Score: 0

      The main problem is compilation speed. C++ compilers are just plain slow.

      They should use Google Go.

    86. Re:A stupid question... by Anonymous Coward · · Score: 0

      The main problem is compilation speed. C++ compilers are just plain slow.

      They can be, yes. But using this argument needs to stop. When you're whacking together a system that has a high hits-per-unit-time requirement (or even a small one) and it comes time to decide between C++ and OtherDevelopmentLanguage, if you're basing the decision on "how long it will take to compile" you need to stop, push away the keyboard, and go out for a beer and a long think.

      Statements like this seem to (willingly or not) ignore the distinction between developing a web server and developing the web application served by the web server.

      If you're writing the web server your compile time is a factor once per millions of hits. It will get overwhelmed by the actual execution time of the code itself over the lifetime of the product and you're better off paying attention to factors like development and run times. ("But you compile during development!" Uh-huh. How often do you compile your work in progress from scratch?)

      If you're writing the web application your interpreting time (analogous to your compile time, surprise!) is a factor more frequently and you do have to consider it. In the worst case scenario you have to reinterpret/recompile for every hit. Interpreted languages are optimized to deal with this and the compile time for a nontrivial C++ program will eat you alive.

      In the more realistic high-volume scenarios it's less black and white. If you use C++ and your architecture requires you to recompile and re-execute it a thousand times a second, you're doing it wrong. You compile once and invoke the resulting binary to serve requests. With interpreted languages you play tricks like bytecode caching to eliminate a lot of the otherwise mandatory interpretation steps and it starts looking more like the 'one compile per million hits' pattern too.

      tl:dr: By the time your application is popular enough for compile times to matter, they won't matter. Base your decisions on more relevant criteria.

    87. Re:A stupid question... by Ant+P. · · Score: 1

      I agree with you on Perl being as full of crap as PHP (especially the $%@-ing variables). The problem is that you have to consciously work around PHP's piles of crap constantly to do even simple things.

      I'll give you an example:

      my @array = list_returning_function() or qw(default values);
       
      sub crash_and_burn {
          @_ or throw 'up';
          say $_ foreach @_;
      }
       
      exec {
          crash_and_burn(@array, 'some other value');
      };
      if ($@) {
          error_handler($@);
      }

      And then in the other corner...

      <?php
      $array = array_returning_function();
      if ( !$array ) {
      /* if you're lucky enough to have php 5.3, you could use "?:" in place of perl's "or" */
          $array = array('default', 'values');
      }
       
      function die_in_a_fire(array $array = null) {
          if ( is_null($array) ) {
              throw new Exception('wuh');
          }
       
          $stuff = $array;
          if ( func_num_args() > 1 ) {
      /* If you try to use the output of func_get_args directly, you get a fatal error. Seriously. */
              $tmp = func_get_args();
              array_shift($tmp);
              $stuff = array_combine($stuff, $tmp);
          }
          foreach ( $stuff as $i )
              echo $i, "\n";
      }
       
      try {
          die_in_a_fire($array, 'something else');
      }
      catch (Exception $e) {
          error_stuff($e->getMessage());
      }
      ?>

      And that's just a basic syntax example.

      Also I should point out PHP's @ can be used in a useful way like Perl's exec/$@ (I don't think the similarity between them is a coincidence), but 99% of the time that's not what happens.

    88. Re:A stupid question... by Blakey+Rat · · Score: 1

      Except for the problem that, historically, PHP is been one big vast security pitfall.

      And historically, cars only go 15 MPH and belch black smoke! We should undoubtedly go back to horses.

      I actually kind of agree with you, but your analogy sucks. Historically, MySQL was a piece of shit, now it's pretty good. Same with Linux GUIs, Windows, ... most everything!

      The fact is:
      1) PHP has cleaned up their act a *lot* in version 5.
      2) You can't blame a language for ignorant programmers.

      If you're willing to give PHP a fair trial, that's one thing. But if you're just refusing to use it because how bad it was "historically", well... what *do* you use? An abacus?

    89. Re:A stupid question... by amicusNYCL · · Score: 1

      It's a fault of PHP insofar as PHP promotes bad coding practices, by making it easier to write bad code, and harder to write good code.

      It's not hard for a good programmer to write good code, PHP just doesn't require it.

      If a file couldn't be opened, then code should explicitly check for error and provide some fallback - or otherwise die as loudly as possible.

      You don't always want your application dying as loudly as possible. You don't necessarily want a user to see filesystem or database details in error messages. In most production systems you would route all errors to a log anyway instead of the browser. I'm not trying to defend the @ operator because I never use it. You hold it up as an example of why PHP is bad, when in reality it's an artifact that doesn't really get used. The example you pointed to shows one example of hiding the error message from the user, but in reality most systems use an error log instead. The @ operator doesn't come into play.

      No other language I know, other than PHP, has a similar operator or construct specifically for this purpose.

      Error suppression is not an uncommon thing, but I'm not going to represent that I know a significant amount about a significant number of languages, my programming knowledge is limited to a relatively small set of languages.

      --
      "Our two-party system is like a bowl of shit looking at itself in a mirror." - Lewis Black
    90. Re:A stupid question... by amicusNYCL · · Score: 1

      I think that in most cases that 0 is not a valid value for most uses. Database IDs, for example, will never be 0. If you use intval and then the value is 0, the ID wasn't set. You can also use is_numeric to check if you have a numeric string (vs. non-numeric string), and you can also use strict comparison if the return of intval is 0 to check if the original string was neither "" nor "0", if not then again it's a non-numeric string.

      --
      "Our two-party system is like a bowl of shit looking at itself in a mirror." - Lewis Black
    91. Re:A stupid question... by shutdown+-p+now · · Score: 1

      It's not hard for a good programmer to write good code, PHP just doesn't require it.

      It's true of virtually any language out there. You can write good code in Perl, or even in VB6. The difference is that some languages make it easier to write good code, and some languages make it easier to write bad code.

      Also, any language comparison is necessarily relative. I'm not arguing that PHP is "simply bad" - only that it's clearly worse than obvious alternatives, such as Python and Ruby. So far I haven't heard a single technical argument as to why one would prefer PHP over either one of those two. I know of business reasons - for example, PHP hosting is dirt cheap and widely available, and so are PHP coders. But can it stand on its own merits?

      I'm not trying to defend the @ operator because I never use it. You hold it up as an example of why PHP is bad, when in reality it's an artifact that doesn't really get used.

      Any unused feature of the language is not a good sign, and particularly when said feature is inviting to write bad code. At minimum, it could be officially deprecated.

      Error suppression is not an uncommon thing

      Only when error is properly handled. Hence why e.g. in exception model, you can "suppress" an error with a catch block, but syntactically, it's also a block of code designed to handle said error. You can leave it empty, of course, but the syntax itself is suggestive of handling it somehow - in contrast to @, which just suppresses.

    92. Re:A stupid question... by Cyberax · · Score: 1

      "Are you saying C++ doesn't have development platforms that compile your code in real time as you modify it ?"

      No. The closest thing is VisualStudio 2010 - it has online error checker (though not compiler) and working edit&continue. Free tools are miles behind in functionality, unfortunately.

    93. Re:A stupid question... by ls671 · · Score: 1

      Hey, thanks a lot for enlightening me on the topic, I was kind of surprised nobody replied to me sooner after I posted ;-(

      Thanks again ! ;-))

      --
      Everything I write is lies, read between the lines.
  4. Well, I Guess "HipHop" Is the New Champ! by RobotRunAmok · · Score: 5, Funny

    And here I never thought that anything could ever take the award for "Most Stupidly Named Software" away from the Ubuntu distros.

    Congrats again, HipHop! Can I get a Fist-Bump?!

    1. Re:Well, I Guess "HipHop" Is the New Champ! by Anonymous Coward · · Score: 2, Funny

      I made the mistake of installing HipHop. I should have known something was wrong when the server started wearing pants hanging down so low that its anus was sticking out. Then eventually the thing ran away and now spends its time at the local Popeye's and makes money stealing people's hubcaps.

    2. Re:Well, I Guess "HipHop" Is the New Champ! by Anonymous Coward · · Score: 2, Funny

      My friend, if someone's anus is sticking out, they have far more problems than oversized pants!

    3. Re:Well, I Guess "HipHop" Is the New Champ! by NevDull · · Score: 4, Insightful

      My guess is that it was probably a progression from "Haiping's PHP" to HPHP to HipHop.
      Two syllables vs four or more... looks like they're not just computing more efficiently, but also speaking more efficiently!

    4. Re:Well, I Guess "HipHop" Is the New Champ! by Garble+Snarky · · Score: 1

      Not that it makes the name any better, but I think its a sort of "expanded acronym", from Hyper-PHP.

    5. Re:Well, I Guess "HipHop" Is the New Champ! by aldld · · Score: 1

      Most stupidly named software? What about Scrotwm?

    6. Re:Well, I Guess "HipHop" Is the New Champ! by Anonymous Coward · · Score: 0

      HPHP

    7. Re:Well, I Guess "HipHop" Is the New Champ! by Anonymous Coward · · Score: 0

      Well, many of those who use PHP for non-trivial web development end up getting fisted, but that's not really the same thing...

      - T

    8. Re:Well, I Guess "HipHop" Is the New Champ! by Nerdfest · · Score: 2, Funny

      It sucks. To compile, it makes you hold you mouse sideways ... gangsta style.

    9. Re:Well, I Guess "HipHop" Is the New Champ! by oldhack · · Score: 1

      "Joomla!" beats it, but that's me - I haven't done web app since the dot bomb days.

      --
      Fuck systemd. Fuck Redhat. Fuck Soylent, too. Wait, scratch the last one.
    10. Re:Well, I Guess "HipHop" Is the New Champ! by Anonymous Coward · · Score: 0

      Hyper-PHP

      (From this article, also /.'d: http://therumpus.net/2010/01/conversations-about-the-internet-5-anonymous-facebook-employee/?full=yes )

    11. Re:Well, I Guess "HipHop" Is the New Champ! by sorak · · Score: 1

      My guess is that it was probably a progression from "Haiping's PHP" to HPHP to HipHop.

      Two syllables vs four or more... looks like they're not just computing more efficiently, but also speaking more efficiently!

      But sometimes it's worth the extra effort. If I were heading a project called the "New Analytical Mathematics Binarie & Library Architecture", I wouldn't call it NAMBLA. I'd called it "the New A.M.B Library"...

    12. Re:Well, I Guess "HipHop" Is the New Champ! by NevDull · · Score: 1

      I'd just release a version for online gaming sites called the Gambling Analytical Binary and Library Architecture - GAMBLA.

  5. Ambitious by meza · · Score: 1

    They wrote their own webserver/php-interpretor to increase the performance with "half or [one] percent"? Wow, that's quite daring I'd say. Note I did not RTFA so probably they saw more performance increase or some other use, otherwise it seems like a likely miss-directed investment.

    1. Re:Ambitious by bill_mcgonigle · · Score: 1

      Yeah, the article would help you there.

      Even if it were only half of one percent, that's still 150 machines to Facebook. I understand they put a patch up for memcache that "only" reduced their need for 60 machines (some synchronous lock got made async IIRC).

      --
      My God, it's Full of Source!
      OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
    2. Re:Ambitious by sopssa · · Score: 3, Insightful

      He said they were struggling just to get half a percent more performance with Apache. That had nothing to do with "HipHop".

      In reality their CPU usage dropped average 50%

      With HipHop we've reduced the CPU usage on our Web servers on average by about fifty percent, depending on the page.

    3. Re:Ambitious by PhiberOptix · · Score: 3, Informative

      sure, hardwares cheap, but when you have over 30k* servers, a 1% saving on them might be worth their coders time.

      * http://www.datacenterknowledge.com/archives/2009/10/13/facebook-now-has-30000-servers/

    4. Re:Ambitious by meza · · Score: 1

      Ah thanks, that explains it. Either I'm just tired or the summary makes the quote easy to miss understand.

    5. Re:Ambitious by shutdown+-p+now · · Score: 3, Interesting

      They wrote their own webserver/php-interpretor

      They didn't write a PHP interpreter. They wrote a PHP-to-C++ translator.

      Also, I presume that "one-to-half percent" refers to further optimization opportunities after they've done that.

    6. Re:Ambitious by Anonymous Coward · · Score: 0

      Plus, this probably explains why FacePlant has been so damn slow lately. They must have some kinks to work out yet in the software.

    7. Re:Ambitious by Xest · · Score: 1

      So they've taken a language that encourages sloppy programming, and translated it into one that demands perfection.

      Is it me or does that not sound like the most backwards step in advancement of web security and stability in history? It would explain at least why Facebook has for the last few weeks been noticably slower, and more noticably unstable as random things just fail to work, such as nagivating to certain pages, and clicking go offline on the chat bar only to be told it can't do that.

    8. Re:Ambitious by tolan-b · · Score: 1

      No it's been running FB for six months, so the recent problems are either unrelated or due to some recent change.

  6. i can hear it now by Anonymous Coward · · Score: 0

    i can hear both sides now:

    the php lovers: "look how awesome php is, you can use it for really large scale deployments!"

    the php haters: "look how awful php is, you need to convert everything into c++ before you can use it in really large scale deployments!"

    1. Re:i can hear it now by bill_mcgonigle · · Score: 4, Insightful

      the php haters: "look how awful php is, you need to convert everything into c++ before you can use it in really large scale deployments!"

      "Look how awful C++ is, you have write bits in assembly to get it to really run."

      "Look how awful assembly is, you really optimize when you can write machine opcodes."

      And the microcode guys just glare out from their caves with their glowy little eyes in incredulity.

      Elsewhere is heard, "You guys still use CPU's? It's the GPU decade, dude."

      And somebody down the hall builds an ASIC to solve a specific problem and thinks he's so smart.

      But, the analog EE understands his elegant circuit doesn't enable a team of 200 developers to build the top social networking site.

      --
      My God, it's Full of Source!
      OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
    2. Re:i can hear it now by pdusen · · Score: 1

      You've killed me with wisdom, sir.

    3. Re:i can hear it now by ancientt · · Score: 4, Interesting

      I'm both sides.

      I love PHP when I need to throw something together fast (like today) but don't expect a lot of heavy use. I love PHP when I want to get some handy tools that I can easily hack into doing what I really want. Still, when I have a significant project, and server load starts to matter, I loathe trying to use PHP and would usually rather write it as Perl, sometimes even compiling (gasp) Perl into something about as efficient and a whole lot more reliable than if I tried to write it in C. If I were really serious, I'd write it in C, but a day's work in C is 30 minutes in Perl or 10 in PHP.

      Choice of language for me is about return on investment. I'm not a grand programmer, I don't have the luxury of getting comfortable programming, if I'm programming it means that I'm not spending time on the dozens of other issues confronting our IT department. Most of the time if we're doing any sort of serious project, we're buying service from somebody who does it better than I have time to, probably better than I could.

      If this HH thing (no, can't stand to type the real name) gets momentum then it could be really good for shops like ours. We could turn the tools we don't have time to do well into things that don't suck so much and the tools that we wouldn't think were worth the hardware into things we can afford to run.

      --
      B) Eliminate all the stupid users. This is frowned upon by society.
    4. Re:i can hear it now by ducomputergeek · · Score: 1

      We developed a solution in PHP because that is what the servers we had two years ago supported, I knew it fairly well, and things had to be done quickly to get a product out to market. As we went back and started to rebuild the product we ended up choosing Perl because Perl wasn't changing much, already had a module that supported almost anything we wanted to do, and we could compile it and increase the load our servers could take by a good 20%.

      --
      "The problem with socialism is eventually you run out of other people's money" - Thatcher.
    5. Re:i can hear it now by moosesocks · · Score: 1

      Facebook seems to be a poster child for PHP -- it started as a teeny-tiny site, and grew into one of the largest on the Internet without any major architectural changes or significant downtime. (In fact, I can't think of a single major outage in the 5 years that I've been using the site. Can't say the same for GMail or Slashdot.)

      They might need 30,000 servers, but they're also supporting 250,000,000 users on some rather processor-hungry services. I imagine that the Photo application accounts for the bulk of the server farm.

      --
      -- If you try to fail and succeed, which have you done? - Uli's moose
    6. Re:i can hear it now by turbidostato · · Score: 1

      "i can hear both sides"

      I can hear *the* side (the bosses one):

      look now: I can have cheap and fast development (PHP) than runs really fast too (C++).

    7. Re:i can hear it now by Anonymous Coward · · Score: 0

      No outage? Facebook fails to respond well every single day.

    8. Re:i can hear it now by Anonymous Coward · · Score: 0

      Respectfully, sir or madam: fuck you with a pointed stick.

      Some of us fucking code for a living. It is _precisely_ attitudes like your own which spawn additional zombies in my daily waking nightmare. Please for fuck's sake leave the coding to the coders.

      captcha 'anathema' seems so apropos.

    9. Re:i can hear it now by Unequivocal · · Score: 1

      They have minor outages daily - their UI is one of the most unreliable of the big sites I've ever used. I was just trying to upload a picture - major ajax wait followed by timeout. Finally got it to work. Then tried to look up a friend via friend search - down. They're second only to twitter in terms of the minute by minute unreliability of a major website, imo.

    10. Re:i can hear it now by Anonymous Coward · · Score: 0

      one of the best comments about Holy Wars on slashdot.

      Bow to thee, O wise Master!

    11. Re:i can hear it now by cavebison · · Score: 1

      I love PHP when I need to throw something together fast (like today) but don't expect a lot of heavy use. I love PHP when I want to get some handy tools that I can easily hack into doing what I really want. Still, when I have a significant project, and server load starts to matter, I loathe trying to use PHP and would usually rather write it as ...

      Why is classic ASP / ASP(VB).NET never mentioned in this context? Surely, like PHP, VB(script or .NET) is just as quick and easy (or more so) and, like PHP, not suitable for time-critical processes.

      Yet not a squeak about ASP/VB, as if good old BASIC doesn't exist!

  7. Ah ha! by bernywork · · Score: 3, Funny

    This explains a lot, a couple - few months ago, I started getting complaints about "potentially virus infected" / "unscanable" zip files when being served content from facebook.com and fbcdn.net etc.

    They probably changed at this point how they were sending data out of the web server with zip compression and it all started falling over at this point....

    I was wondering what the change was....

    --
    Curiosity was framed; ignorance killed the cat. -- Author unknown
    1. Re:Ah ha! by Slashcrap · · Score: 1

      This explains a lot, a couple - few months ago, I started getting complaints about "potentially virus infected" / "unscanable" zip files when being served content from facebook.com and fbcdn.net etc.

      They probably changed at this point how they were sending data out of the web server with zip compression and it all started falling over at this point....

      I was wondering what the change was....

      This is the sort of hilarious braindead bullshit a "power" user would come up with to explain something. You're not a user are you? This place is not for you.

    2. Re:Ah ha! by bernywork · · Score: 1

      Huh? Anti-virus / content filtering proxy servers, these ones don't handle zip very well, change around the way the web server works and they add in zip compression to the web server. They could have added zip to the returned data at any point, but doing at at this point, seems very plausible.

      --
      Curiosity was framed; ignorance killed the cat. -- Author unknown
  8. Facebook Still Runs Terribly Slow by ztransform · · Score: 3, Funny

    Chat routinely freezes up the browser, and people appear offline when they are online.

    I frequently get error messages from pages that won't dynamically load (there is something wrong with the server, or such message).

    Facebook doesn't need a half percent increase in performance, they need a lot more!

    1. Re:Facebook Still Runs Terribly Slow by kyoorius · · Score: 1

      I have found the chat to only freeze up when there are multiple FB windows open.

    2. Re:Facebook Still Runs Terribly Slow by inKubus · · Score: 1

      Facebook is garbage and I give them 2 years from today before someone else has come along and taken half their business because the code is so poor. It's stories like these that really ram home the point that the company is run by 20 year olds. If it wasn't for myspace making them look good, they wouldn't be anywhere. Yahoo has had groupware and social networking for a lot longer and it frankly works better. Facebook just had the whole "private club for college students" thing going. I don't see the point. They have critical mass right now, it's the fad, but I don't see this lasting.

      --
      Cool! Amazing Toys.
    3. Re:Facebook Still Runs Terribly Slow by Anonymous Coward · · Score: 0

      Chat routinely freezes up the browser
      Blame Quicktime, or the lack of it

      (there is something wrong with the server, or such message)
      Blame the app's server(s).

    4. Re:Facebook Still Runs Terribly Slow by tolan-b · · Score: 1

      Chat is powered by Erlang not PHP/

    5. Re:Facebook Still Runs Terribly Slow by Anonymous Coward · · Score: 0

      Disable chat, third-party solutions are much better than is the piece of crap 'chat' facebook includes. Not to mention that facebook quite probably 'archives' your chats, which may or may not matter to you personally, but I get nervous about how much of 'my' information is out there.

    6. Re:Facebook Still Runs Terribly Slow by ztransform · · Score: 1

      Chat is powered by Erlang not PHP

      That would explain things. College kids that use esoteric languages have no interest in real-world useability.

    7. Re:Facebook Still Runs Terribly Slow by RegularFry · · Score: 1

      I think you missed a sarcasm tag somewhere there...

      --
      Reality is the ultimate Rorschach.
  9. More speed ... thttpd by Anonymous Coward · · Score: 0

    If you need more speed than apache, you run thttpd. I'm assuming they didn't test it.

    1. Re:More speed ... thttpd by madddddddddd · · Score: 0

      what about lighttpd?

    2. Re:More speed ... thttpd by mike3k · · Score: 1

      I switched my virtual private server from Apache to Nginx and I found the memory usage dropped by nearly half and it runs a lot faster. I have two wordpress sites and one Drupal site on that server. The default Apache configuration uses a separate process for each connection, so the memory usage balloons with a lot of activity. Nginx defaults to use a single process, and the memory usage remains constant no matter how busy it gets.

  10. From TFA... by BitHive · · Score: 3, Funny

    As a programming language, PHP is simple. Simple to learn, simple to write, simple to read, and simple to debug. We are able to get new engineers ramped up at Facebook a lot faster with PHP than with other languages, which allows us to innovate faster.

    hahahahahhahahahhahahahahhahahahahhahahah

    1. Re:From TFA... by oldhack · · Score: 1

      Us in the software ghetto completely destroyed the word "innovate". Sorry.

      --
      Fuck systemd. Fuck Redhat. Fuck Soylent, too. Wait, scratch the last one.
    2. Re:From TFA... by twostix · · Score: 1

      Which bit of that quote from a multi billion dollar companies senior programmer's personal experience is funny?

      But then, deep within your comments I found this: "I am a web developer and I know lots of PHP"

      Me thinks you're just trying to be cool, kinda like the kid who laughs at the losers when he's around the cool kids but then goes to sleep overs at the losers house on the weekend because he hasn't really got any friends.

      Nice try you PHP *web developer* but you're busted.

    3. Re:From TFA... by Terrasque · · Score: 1

      Fact is, the language is a mess and you have to go out of your way to make secure code.

      There's a lot of things I could drag out (like some functions altering data directly, but others returning a modified copy, with no apparent logic in which does which. And lack of namespaces), but my personal favorite PHP mess is mysql_escape_string vs mysql_real_escape_string :)

      "oh, you've escaped input, thats good. But it's still insecure, because you didn't use the REAL escape string function" - A star example of both the mess that is PHP, and the security problems with it. Sure, you can write airtight code in PHP, but you *really* need to know what you're doing, more than just about any other scripting language I've seen.

      You might disagree, but that's my view and you need a lot of persuation and good explanations to sway me away. I'm not interested in a flamewar or pointless argument, which is why I didn't post in the main "lets all bash php" thread further up.

      --
      It's The Golden Rule: "He who has the gold makes the rules."
  11. hahahahahhaha by BitHive · · Score: 0, Troll

    *learns PHP as a new hire at Facebook*

    "Look, ma, I'm an engineer!"

    *writes shitty php code*

    "Look, ma, I'm innovating!"

  12. Yup, those PHP organizations sure are dumb by SlappyBastard · · Score: 2, Insightful

    What with their stupid success and their stock options growing in value. Man, what a bunch of fucking retards.

    --
    I scream. You scream. I assume that means we're both acquainted with the problem. We proceed.
    1. Re:Yup, those PHP organizations sure are dumb by FooAtWFU · · Score: 2, Interesting

      That just goes to show that with enough resources, you can brute-force anything.
      The question for you and me is: do you want to be the brute?

      --
      The World Wide Web is dying. Soon, we shall have only the Internet.
    2. Re:Yup, those PHP organizations sure are dumb by CannonballHead · · Score: 1

      I'm not sure the originator of Facebook had "enough resources."

    3. Re:Yup, those PHP organizations sure are dumb by enoz · · Score: 1

      That just goes to show that with enough resources, you can brute-force anything.

      Pretty sure Google proved this long ago.

    4. Re:Yup, those PHP organizations sure are dumb by Dunbal · · Score: 1

      What with their stupid success and their stock options growing in value. Man, what a bunch of fucking retards.

            If they ever do go IPO, I will certainly be there to short their stock... WHAT was their business model again?

      --
      Seven puppies were harmed during the making of this post.
    5. Re:Yup, those PHP organizations sure are dumb by jjohnson · · Score: 1

      Wouldn't you?

      --
      Anyone who loves or hates any language, platform, or manufacturer, doesn't know what they're talking about.
    6. Re:Yup, those PHP organizations sure are dumb by gmhowell · · Score: 1

      The question for you and me is: do you want to be the brute?

      If the check doesn't bounce, hell yeah!

      --
      Jesus was all right but his disciples were thick and ordinary. -John Lennon
    7. Re:Yup, those PHP organizations sure are dumb by iggymanz · · Score: 1

      The question for you and me is: do you want to be the brute?

      silly question, if it involves much resource$ going into my pocket, fuck yeah

    8. Re:Yup, those PHP organizations sure are dumb by Unequivocal · · Score: 1

      Some folks said that about Amazon too way back when. "WTF? They sell books? I'd rather buy a company that sells pet food with sock puppets - much more solid model!"

      Just b/c a business model isn't obvious doesn't mean there isn't one. They could be smoke and mirrors, but I wouldn't bet on a short being profitable within any reasonable time frame.

    9. Re:Yup, those PHP organizations sure are dumb by Anonymous Coward · · Score: 0

      From a stock perspective, Facebook is a drop in the bucket compared to Microsoft. Therefore, .NET is the best technology platform.

      Using your logic, that is.

    10. Re:Yup, those PHP organizations sure are dumb by Dhalka226 · · Score: 1

      That just goes to show that with enough resources, you can brute-force anything.

      Fair enough I suppose. On the other hand, maybe it also goes to show that people without enough resources start with things that are easier, faster and cheaper and only come to care whether or not they are brute-forcing a problem while they're rolling around in their piles of money?

  13. Great story by BitHive · · Score: 2, Insightful

    Yeah I think I'm going to go buy stock in companies because they use PHP. Take that! hurrrr

    1. Re:Great story by LordLucless · · Score: 1

      Yeah, I think I'm gonna make investment choices based on their choice of development language rather than, you know, the product they make with it. Hurrrr.

      --
      Just because you're paranoid doesn't mean there isn't an invisible demon about to eat your face
    2. Re:Great story by SlappyBastard · · Score: 1

      A lot of publicly traded companies use PHP. You've clearly put me in my place.

      --
      I scream. You scream. I assume that means we're both acquainted with the problem. We proceed.
    3. Re:Great story by twostix · · Score: 1

      Their entire business is built on PHP.

    4. Re:Great story by BitHive · · Score: 1

      You see, people are rich because they are smart, otherwise they wouldn't be rich. Discuss.

  14. I guess I got it reversed by ClosedSource · · Score: 1

    "The main problem is compilation speed. C++ compilers are just plain slow."

    You do go to the bathroom or have some coffee or tea once in a while don't you?

    1. Re:I guess I got it reversed by Anonymous Coward · · Score: 0

      Yes, but I don't go to the bathroom/have coffee every *2 seconds*, which is sometimes how quickly i go from editing my PHP code to testing it, to editing it again.

      I do write some C++ code from time to time, and I hate the compilation step, even though it's usually ~20 seconds.

  15. ===E by Anonymous Coward · · Score: 0

    ===E

    You've been forked.

  16. Meh Filter by Gary+W.+Longsine · · Score: 2, Insightful

    Please, Slashdot Gods, give me a preference filter to hide all comments which begin with "Meh".

    --
    If you mod me down, I shall become more powerful than you could possibly imagine.
    1. Re:Meh Filter by Fallingcow · · Score: 1

      A few minutes worth of Javascript and the Greasemonkey extension to Firefox ought to be able to handle that for you.

    2. Re:Meh Filter by AmberBlackCat · · Score: 0, Offtopic

      While you're at it, filter any comment whose only content is "whoosh".

    3. Re:Meh Filter by Deigote · · Score: 1

      Yours included ;)

  17. duration of leak by pikine · · Score: 4, Interesting

    We're talking about C++ as a CGI script. Who cares about memory leaks that only last for the duration of an HTTP request, which is a fraction of a second? The real problem with memory leaks is when you have a long-running process like single-process web browsers.

    --
    I once had a signature.
    1. Re:duration of leak by micheas · · Score: 1

      We're talking about C++ as a CGI script. Who cares about memory leaks that only last for the duration of an HTTP request, which is a fraction of a second? The real problem with memory leaks is when you have a long-running process like single-process web browsers.

      But nobody that cares about performance runs cgi they run fast-cgi which has reduced load times, but comes with a penalty of potential memory leaks as a single process handles many requests.

    2. Re:duration of leak by pikine · · Score: 1

      You make your fast-cgi process run for 100 requests and then exit. This way, you reap 99% of the performance benefit of fast-cgi, sacrificing only 1% of performance penalty in order to counter memory leak.

      --
      I once had a signature.
  18. CPU usage... by Trieuvan · · Score: 1

    Webservers are mostly IO bound, why do they need to improve cpu usage ?

    1. Re:CPU usage... by sopssa · · Score: 1, Interesting

      Because they have already optimized most of the IO and DB related things. Since Facebook is one of the largest sites in the world, even small changes make huge changes with what infrastructure and server amounts they need. And in this case the improvement is 50%.

    2. Re:CPU usage... by Dog-Cow · · Score: 1

      Where have you been for the last 10 years? Stuck in 1987?

  19. What about Flooz? by rudy_wayne · · Score: 1

    I heard that PHP is good for Flooz.

    1. Re:What about Flooz? by revlayle · · Score: 1

      And Flooz is good for JimbaJamber and JimberJamber is good for Thwakdondling

  20. There's a difference? by michaelmalak · · Score: 1

    There's a difference between beta and production code when it comes to the code that runs Facebook?

    1. Re:There's a difference? by Unequivocal · · Score: 1

      Hear hear. That site stands on the backs of its forgiving user base (can you say lock-in any louder without using an iphone?). Only twitter is worse for reliability. Well said!

  21. here we go... by Tumbleweed · · Score: 2, Interesting

    It's arguments like these that make me wish for a LLVM/JIT version of D that I could use instead of PHP. And then just compile the thing if I needed soopa-doopa performance.

    OR that REBOL had developed into a big open source platform.

    *sigh*

    The fights between C++/C#/Java/JavaScript fanatics are fights about the different implementations/targets of the same obsolete programming syntax structures, and don't do anyone any good.

    1. Re:here we go... by sydneyfong · · Score: 1

      Javascript is really different from C++/C#/Java. Take some time to learn it.

      In fact, from what I understand about D, it's just a "C++ done right", but still it's in the same class as the C++/C#/Java that you hate so much.

      --
      Don't quote me on this.
    2. Re:here we go... by shutdown+-p+now · · Score: 1

      Why not just embrace Common Lisp, then?

      You can carve any other language out of it with reader macros, if you hate parentheses, or love curlies...

    3. Re:here we go... by shutdown+-p+now · · Score: 1

      In fact, from what I understand about D, it's just a "C++ done right", but still it's in the same class as the C++/C#/Java that you hate so much.

      Of all the language he listed, D is the only one that has sane templates which are both typesafe, and powerful enough to permit full-fledged metaprogramming (it has other metaprogramming facilities as well).

      As for JS - the core idea of prototype OOP is neat (though it doesn't play well with static typing), but the particular JS implementation of that idea is kinda meh, because of all the design flaws in the language - starting with local variable scope.

    4. Re:here we go... by Tumbleweed · · Score: 1

      Why not just embrace Common Lisp, then?

      You can carve any other language out of it with reader macros, if you hate parentheses, or love curlies...

      I was hoping for interrobangs...

    5. Re:here we go... by Anonymous Coward · · Score: 0

      Or write it in Objective-C like Bombaxtic?

    6. Re:here we go... by Haeleth · · Score: 1

      How exactly do you implement a static type system with reader macros?

    7. Re:here we go... by shutdown+-p+now · · Score: 1

      Reader macros are for custom syntax. Normal macros are for custom semantics. Type system is semantics.

  22. Analogy of the year by oldhack · · Score: 3, Interesting

    "Which is like saying an anus is almost like a vagina..."

    I bow down in respect. Somebody mark this post for posterity. It's only Feb 2, but this has to be the Analogy of the Year.

    --
    Fuck systemd. Fuck Redhat. Fuck Soylent, too. Wait, scratch the last one.
    1. Re:Analogy of the year by KingAdrock · · Score: 1

      In complete agreement here.

    2. Re:Analogy of the year by wisty · · Score: 1

      It's not even a car analogy!

    3. Re:Analogy of the year by truthsearch · · Score: 1

      Somebody mark this post for posterity

      OK.

  23. Fish in a barrel by abulafia · · Score: 1

    I know people will use PHP. I use PHP. Your inability to pay attention does not, however, say anything about how PHP is perceived. And it is true that listening to non-hacks, like people who tend to congregate here, has an influence. So go figure.If you want to play about how how dumb code-monkeys misuse a PHP feature, that's entirely your business. I'm simply pointing out that there are better ways to go about things, and that while it may make sense to still use a legacy platform, things have actually moved on. I'm not begrudging whatever business you have - have fun!

    --
    I forget what 8 was for.
  24. No download yet by Anonymous Coward · · Score: 0

    For you trying to find a download link; there is nothing available yet. No beta no nothing.

  25. Pattern -3? by nem75 · · Score: 1

    if(mainType == 11) { subType = 9; break; }

    [...]

    testp.cpp (subtract 3 from mainType since that seemed like a pattern):

    Umm... no.

  26. Better analogy: by GameboyRMH · · Score: 1

    C/C++ coders are like tank commanders. They're not quite in the trenches like the assembly/embedded guys, but they're close enough to the gritty hellish parts of the job, and they've got a lot of firepower at their disposal.

    PHP coders are like UCAV pilots. They pack almost as much firepower as the tank commanders but they're sitting in a big comfy chair in an air conditioned room, sometimes drinking a Starbucks with one hand. Sure they're getting the job done but there's nothing hardcore about it.

    A Python coder is like an F22 pilot. Mostly removed from the hellishness of the front lines but still in the action, and wielding unholy levels of firepower.

    --
    "When information is power, privacy is freedom" - Jah-Wren Ryel
  27. daily wtf by jDeepbeep · · Score: 1

    You have just explained half the code snippets on The Daily WTF

    As a regular visitor to the site in question, let us both agree you are exaggerating a fair amount.

    --
    Reply to That ||
  28. Commercial bashing of PHP by Max_W · · Score: 1

    I hear a lot of bashing of PHP recently. It seems someone wants to clear up the market for a commercial product.

    Something like - if you need basic functionality buy "Light Edition", if you need uploading files on server buy "Professional Edition", if you want to use FTP functions or RegExp expressions buy "Business Architect Edition" for 3000.

    But PHP does it all and more for free. Will they be able to get the genie back into the bottle? We will see.

    At least, we know that it all may work in one product by now. I do not trust paid bloggers and podcasters who bash PHP because I've been programming in an environment with the artificial commercial walls and limitations. Thank you. Better to handle some difficult syntax and limitations of open source software like PHP and MySQL than run into artificial barriers of commercial analogs.

    I guess that there is an element of the US chauvinism in it (or desire to commercialize this environment), because practically the whole Internet runs on the non-US software, PHP&MySQL. PHP is the Eurasia's baby http://en.wikipedia.org/wiki/PHP . I guess it somehow does not fit the US mythology and legends.

    1. Re:Commercial bashing of PHP by Max_W · · Score: 1

      Actually, that part the PHP & MySQL is "Eurasia's baby" is not true. Yes, it started in Eurasia, but a lot of development of this open soft was done by the US "chest-haired" programmers, who are definitely are very strong and generous.

    2. Re:Commercial bashing of PHP by Terrasque · · Score: 1

      You know, its funny that you never seem to wonder "maybe so many are bashing PHP becasue they are right", but just assume it must be an evil plot by some overlord corporation.

      I've programmed in php, but have moved away from it in favor of other languages (my favorite ATM is python (plus django for web development)), and although I still program in PHP now and then (when I must), it is something I really dislike doing.

      --
      It's The Golden Rule: "He who has the gold makes the rules."
  29. ugh .. by freaker_TuC · · Score: 1
    My friend, if someone's anus is sticking out, they have far more problems than oversized pants!

    You don't want to know! ...

    ...Not even for scientific purposes

    --
    --- I am known for the ones who want to find me on the net. Is that a privacy risk or a privilege? One might wonder..
  30. PHP is pretty close to Perl ... by freaker_TuC · · Score: 1

    To my opinion, know Perl and you'll also know PHP; by watching the small differences. I've had a lesser feel for Javascript after doing extensive Perl works.

    I'm coming from a Pascal and ASM background; barely touched C or C++ the last 10 years.

    --
    --- I am known for the ones who want to find me on the net. Is that a privacy risk or a privilege? One might wonder..
  31. shelltris by jDeepbeep · · Score: 1

    *points to sig*

    Shelltris is my favorite.

    --
    Reply to That ||
  32. php-eaccelerator by hey · · Score: 2, Informative

    Since php lives in Apache which is always running it makes sense to cache the compiled byte codes.

    I like the approach of this:

    https://admin.fedoraproject.org/pkgdb/packages/name/php-eaccelerator?_csrf_token=7bb450c274970e7f6d6ece15a4194c5feb114809

    1. Re:php-eaccelerator by Blakey+Rat · · Score: 1

      You might try reading the article.

      They're not using bytecode at all; they're "compiling" the PHP files into C++ files, then compiling those into a CGI-BIN-like solution, which they they run using their own web server (not Apache.) They've also written a program that can recompile changed PHP files on-demand (I'm not sure if that's part of the web server, or separate), so PHP programmers don't have to change their work habits at all.

      The only downside to this approach is that you can't use PHP features with no equivalent in C++, for example, "eval();"-- but arguably that's a good thing. :)

    2. Re:php-eaccelerator by hey · · Score: 1

      I read the article but I see how you might think I didn't. I was pointing out an existing alternative to compiling into C++.

      Do you have a link for your compiler - er - accelerator?

  33. Is it faster than Lighttpd and xCache? by rica24 · · Score: 1

    HipHop seems really interesting, we have had to switch to lighttpd and xcache to achieve huge performance benefits for our objectCMS framework which is now faster that wordpress, joomla and drupal. I am wondering how hiphop compares to lighttpd and xCache, does anyone know when hiphop is going to be released to the public.

  34. Facebook gets with the program by destiney · · Score: 1

    This isn't news. Lots of highly-loaded websites ALSO do not use Apache. This article should have been titled "Facebook gets with the program and ditches Apache like everyone else with a benchmark tool"

  35. Documentation by MikeFM · · Score: 1

    IMO the strongest point PHP has going for it is that the language and libraries are documented in one place and in a reasonably human readable way. I'd say Python has the second most readable docs. Certain parts of Java are pretty well documented but to a newbie the docs alone are overwhelming. Other languages frequently are hard to grasp without taking classes or buying books, libraries are diverse and not documented in the same place/way, and in general are just overwhelming. Point in case. I recently taught myself Objective-C for iPhone programming. It wasn't an especially difficult language being familiar already with C, C++, Java, etc and the libraries are reasonably well documented but it's a whole different world from picking up PHP. The level of effort involved is just a bit more here, a bit more there, until it adds up to being a lot more work. I'd like to see someone try to document C and all the common libraries you would want to be as easy to grok as the PHP docs.

    --
    At what price learning? At what cost wisdom? The price is a man's peace of mind, and the cost is his life.