Please don't use Facebook as an example, the fact they gave in and built HipHop to get it into C++ spoils it. Are they coding in PHP? Sure! Are they actually using it like it's meant to be used? Not quite!
The developer's usual routine is the same as someone using Zend; they write honest-to-goodness PHP and reload the page. There is no compilation involved; you instead are using the JIT (or until recently, an interpreter) that monitors the filesystem for changes and silently integrates them.
Facebook devs use PHP exactly as everybody else does; they just do so with a different toolchain.
You will find any number of C/C++ programmers who think you can't write anything in Java. Many Java programmers think you can't write anything (beyond 100 lines) in Python. Many Python programmers think you can't (or simply shouldn't) write anything in PHP. And so on.
Some people are insecure.
Some people can't separate their language from themselves (and see a criticism of their language as a criticism of them as people).
Some people exemplify the Dunning-Kruger effect [1].
Some, like teenagers, are just asserting their identities.
Some simply have biases that are mental blocks.
[1]: http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
Ppl who have strong opinions when it comes to language design have strong opinions when it comes to language design. Ppl who think languages are just a means to an end think languages are just a means to an end. These are two differenty species and indicative of their particular worldview, attitude and preferences. To use that as any kind of filter is silly.
Lets not look at CS for a second...If you want to know what a Stieltjes integral is, a probabilist will tell you one thing, a functional analyst another, and a measure theorist will give you yet another more pedantic definition. There's no right or wrong definition here...every one is coming at it with the tools they are more well versed in. The probabilist is the end-user, so to speak. He can't do his day to day work without internalizing it, because his bread and butter, the PDFs and CDFs of all the distributions he deals with, comes from Stieltjes. The functional analyst is going to use Stieltjes when he deals with Banach spaces, but otherwise he has other preoccupations. The measure theorist studies Stieltjes in depth because it goes to the very foundantion of measure theory...but he isn't really an end-user.
Now back to CS...a C++ programmer will think of Java as an interesting toy because you don't get union types and pointers & so forth. The Java guy will think of Python as an interesting toy, and the Python guy thinks PHP is an interesting toy. None of this means any of these people are insecure or being a teenager. If the only goal in life is "languages as means to an end" where end = $$$ in the short term, then yeah, lets just cut to the chase and do PHP. But there are other goals, yeah ?
When you have crap like this in your language:
> E.g., $i = 0; $a[$i] = $i++; makes a different array than $i = 0; $a[$i + 0] = $i++;
you have no hope of making a truly large program work. There are just too many sources of itsy bitsy bugs; you'll never find them all.
(I'm not a PHP user; I have no idea why those are different arrays. Don't bother explaining; I don't want to know.)
You get $a[1] = 0 the first way, and $a[0] = 0 the second way. PHP seems to evaluate the array index before the right hand side if there is something more than a $variable to evaluate; otherwise PHP evaluates the array index after the right hand side, after $i has been incremented.
I haven't used hiphop, but I'm curious if it preserves that disparity between arrays when translating to C++, or if it breaks PHP compatibility by making those two arrays equivalent.
Maybe you should be the one to stop being so arrogant as to tell other people what they should feel.
Meanwhile, PHP gets a number of things very right. For instance:
* State: there is none across requests. Oh sure, there's APC, and the filesystem, and databases, etc., but those are all accessed via libraries. There is no PHP-level state that survives a request, which provides natural fault isolation: a request which goes wrong doesn't take the server down with it, or live on to corrupt other requests.
* Concurrency: PHP's concurrency model is the web request. If you want to run some code in parallel, curl to localhost. If you wrap an appropriate library around this, it looks just like Erlang's actors. This is shared-nothing concurrency, which turns out to be a compelling local maximum.
* Interactivity: The development workflow PHP provides is very productive. You save and load the page. You don't save, optionally recompile, restart the server, wait for it to initialize, forget what's different from the last three times you tried this because this has all taken three minutes and you forgot to write it down, etc.
These three things turn out to be among the most important parts of a server-side language, and PHP gets them very, very right. The rightness was accidental, not by design, but this doesn't make it any less right.
Also, the language itself can be improved. In the HipHop toolchain, -v Eval.EnableHipHopSyntax=true turns on a bunch of (backwards-compatible) features we've added to our PHP dialect, the most notable of which are XHP (syntax for using XML literals as PHP expressions) and generators (inspired by Python's, using similar 'yield' syntax). I put up some sample code for a talk just the other day, if you're curious: https://github.com/kmafb/hiphop-samples
So the language does two of these three things by not doing them at all ? State: oh there's no state across requests. Concurrency: No shared resources, no threads, but we'll call it shared-nothing concurrency and then say it looks like Erlang!! Amazing. An Erlang actor holds mutable state and sends immutable messages. A web request in PHP does neither.
> If you want to run some code in parallel, Why do you even bring up parallelism in a post about concurrency ? ( http://news.ycombinator.com/item?id=3837147 )
> PHP gets them very, very right. The rightness was accidental.
Completely agree. Here you have a language that decides to tackle hard problems in CS by not tackling them. Then it becomes uber-pervasive because you can do "hello world" over the web by just doing <?print("hello world");?> Once the traction is a given, we argue about why not tackling hard problems is actually "very, very right".
Getting "hard problems" right by realizing they're intractable and refusing to solve them is a perfectly valid system design choice, even though it drives people up a wall when they first encounter it. For an example that has stood the test of time, check out UNIX's handling of the "PC-losering" problem: http://dreamsongs.com/WIB.html. When modern systems people read about this controversy, it seems kind of insane; of course system calls can be interrupted, and of course you don't want the OS to be magically trying to make them look transactional by backing up and restarting your system call when the world is really in an unknown and unknowable state. Ctl-C on a read() shouldn't restart the read(), unless the application thinks it should, and only the app really knows. EINTR was the non-solution that acknowledged the intractability of solution.
Historically, UNIX is a "worse-is-better" system not unlike PHP. I claim anyone designing a new system from scratch to replace it should learn from it, though, both mistakes and successes. PHP is not free of successes.
About the only thing you're protected against is memory leaks, and that seems to be because you have to, otherwise PHP would fall over in a big heap: https://www.google.com/search?q=php+memory+leak
I haven't had any problems with memory leaks running things like Django or Bottle.
What I mean is that whilst you guys at Facebook are using PHP you're not using it in the sense of 'we write code anywhere and deploy it anywhere'. There's an additional build step in between the developers and the final product, rather than just straight up serving PHP as is which is one of the biggest PHP recommendations. Although HipHop is open source so I guess you could still say it's within reach of all developers.
According to him there's no explicit build step the devs have to perform and they're just writing PHP and using open source packages--meaning they are in fact making use of the "write once run anywhere" ideal at least in some places since the open source packages were made to run on Zend and now they don't. The "write once run anywhere" ideal is kind of a myth anyway since there's always configurations to do, and language-wise was even more of a myth when PHP 5.3 was new. (Some hosts still don't support it, and I'm sure a lot of us remember hosting services who dragged their feet just getting off PHP 4.)
It seems like you think the Zend backend is the One True PHP runtime and anything else isn't PHP. This is like saying PyPy isn't Python. It's just a bad argument.
Now, as far as I understand it the Zend backend takes the PHP code, creates opcodes and executes it in a VM, whereas HipHop takes the code, compiles it down to C++, compiles it again with G++ then runs the resulting C++ binary instead. To me at that stage HipHop is no longer a backend, but an entire build system transforming the language away from PHP.
Like I said, I'm not as intimately familiar with the system, but I thought it was along the lines of they have a dynamic system for local development, and when they serve it up it's run through the HipHop compile process.