Jason Evans is the author of jemalloc (and more). Given all the things he would be capable of applying himself to, it's surprising to see him working on PHP runtime performance (though, the problems are interesting).
Now, if you want to get into the details of syntax, naming conventions, etc.. sure, PHP is not everyone's favorite language to work with, but it is far from "technologically poor".
When people complain about PHP they often mean that in an aesthetic, and in an academic sense, the designers of PHP have, arguably, made a lot of poor choices.
What they usually mean is, due to the low barrier of entry coupled with poor aesthetic design choices the PHP community at large seems to have poor engineering standards.
These all being Turing machines though don't prevent it from having quality engineering being applied to it, as is the case of Facebook.
So, the corollary to "only a poor craftsman blames his tools" is "when you only have a hammer everything starts looking like a nail".
I wonder how many people are paid to directly hack on a Ruby implementation vs Python (yay Google) or PHP (yay Facebook).
Fighting your toolchain is an upfront penalty. Once things start moving smoothly, they tend to continue to work smoothly. And that's a problem that can be solved by further development of the toolchain.
Poor aesthetics/readability? You pay that price every second you work on the code.
This is flat out wrong. If you're on a language all the cool kids are using, you'll find those cool kids have an obsession with perfection. To the point where they deprecate things instantly and break everything that worked before. See NodeJS and Python for examples.
If you have 10K lines of code, not so bad. So you do a rewrite every year. When you have 100K lines of code or more, their obsession with perfection will destroy your business.
A rewrite becomes an immense undertaking. You end up running old versions. Those old versions require dependencies which require you to run old operating systems. Eventually the entire ecosystem implodes.
But guess what? Code that was written in PHP3 over 10 years ago works just as well today under PHP5. You can even mix and match. Does that make the syntax of the language ugly? Sure. It even encourages bad practices. So what? You're running a business, not an art gallery. Code should be beautiful, but not at the expensive of having a successful business and a working product.
Sorry, but having felt the pain of keeping legacy installs of old PHP versions around to run business-critical processes, I have to call bullshit on that one.
Why? Your code should work in the latest version. Can you give an example?
I use Java and C++, and I don't rush update the second new libraries become available. My team has a large regression suite, too, so it's been less painful (can't say painless) to detect breakage when our dependencies need to be updated.
Comparing Java and C++ to PHP is the equivalent of comparing a Ford Mustang to a Mac Truck. Yes, they are both vehicles. However, they are designed to do very different functions. Java and C++ are statically typed, compiled languages. PHP is not.
Yes, if you drive a Mac Truck, you can bully and make fun of the guy driving a regular car, but if you're using your Mac Truck to commute to work, you're a lunatic.
For every problem, a proper tool.
Given that FB's solution to their PHP problem was to discover the static typing, I'd say that PHP is not the proper tool for the current job.
What's an example of the Python community doing this. Usually Python get's criticised for being overly-conservative if anything.
Of course, it's everyone's privilege to decide which penalty they'd prefer to pay, and that doesn't mean there aren't language features that can make put it on a new order of expressiveness.
But are we talking about those features? Or are we talking about "aesthetics/readability"? If it's the later, that's probably a different thing, and I have my doubts that it's anything objective. Particularly if it has much to do with which specific tokens indicate the beginning/ending of blocks or enclosing arguments to a function.
As for who is using it, everyone from Google to Twitter to Apple, as well a huge number of high-transaction business systems. The JVM is something that tends to get used quietly and widely.
It's not that Java is memory hog per se, but rather that the total VM memory allocation must be specified at launch, and the VM will not (rarely?) give that memory back to the OS.
This is largely an artifact of Sun's generational GC design+implementation, and has some interesting performance wins; namely, object allocation and deallocation are incredibly cheap, because in the fast case, all allocation requires is updating a single pointer.
The last time I profiled java object allocation, creating short-live objects turned out to be insanely cheap compared to other allocators/runtimes.
> Makes deploying your web application a pain (restarts anyone?)
This largely depends on how you structure your web application.
> If your Facebook and you're trying to get more bang-for-your-buck from your existing hardware, do you think its a good choice to migrate everything to the JVM (including a full rewrite to Java/JRuby/Scala etc.)?
That depends largely on how much they're spending on hardware and JIT/language engineers, versus how much a rewrite would cost, amortized over the reasonable lifetime of their code base.
You have to factor in the fact that they've built an entire organization around PHP, and it's not just a technological migration problem; they might also have to retrain or outright replace a large number of existing engineers.
I'm inclined to say that it was a mistake to choose PHP, and moreover, to continue to use PHP as they scale. However, funding the implementation of better PHP runtime implementation may be the most fiscally conservative decision left available to them.
One of the biggest reasons PHP supplanted Perl as the de facto web programming language ~10 years ago was that Perl running through CGI was incredibly slower than PHP.
mod_perl was spanking PHP 10 years ago from a performance standpoint, but the democratization of the web meant that a lot of people that started with basic HTML layout then learned to extend it with PHP in templates, then moved on from there. Much the same as Perl became a dominant CGI language in mid/late 90s because a lot of sysadmins and hackers transitioned to back-end development due to web programming demands.
I personally transitioned from writing Perl CGI scripts to writing PHP scripts about (pause while I look through my records) 9 years ago, and it was exclusively for performance reasons (I still prefer Perl as a language). I was not alone in my thinking back then.
- cruftyness of perl
- good timing, few alternatives (C and Perl basically) at a key point in the growth of the internet and web developers.
- very easy migration from a static only site
- easy to deploy, leading to...
- wide availability of PHP shared hosting
- in depth docs
- commenting on docs (cut-and-paste programming ;))
- thousands of builtin functions: first real batteries-included language
- recognizable syntax (esp vs Perl) for Java/C programmers
- not awful performance
- builtin MySQL support from an early stage
- oh, it was free (and also Free)
- dynamic typing
- weak typing (as in, values coerced to other types easily, I know this isn't a real term)
Very true and rarely mentioned. PHP docs never had the fancy wiki/social/javadoc features you see in many languages, just a primitive comments system - and it was perfect.
When you were picking it up back when "PHP3" yielded 0 results in Amazon (and we had to change the oil on our desktops every week) the docs were your bible, not merely in the sense of occasionally contradicted themselves but also in having examples, Q&A and recipes for common tasks posted by your peers in the comments, much faster than doc writers could catch up with the language's growth.
Two web language competitors to add here: MS .ASP and ColdFusion. PHP broke out by being both free and Free (the REPL helped too).
I don't know why mod_perl was known to very few and PHP become popular.
PHP sucked at the time too, but it sucked in ways that were easier to track down and fix.
Let's say that there's 1M lines of PHP code right now handling Facebook's site. In the time it takes the team to re-write those million lines of code, another million have been written. So they can never catch up. Almost like Zeno's paradox, except the turtle moves faster :).
All that aside, you can teach PHP to pretty much anyone, and it's rather effective at solving web problems.
For quite a while they had some really smart people working on APC to help with performance, they've since switched horses to work on HipHop and the like to get the performance they need.
Deleted comment