Hacker News Reader

Comment by hvs | Hacker News Reader

I'm not sure that I'd refer to PHP as a "historically technologically poor language". I'm not even quite sure what that means, exactly, but PHP has proven itself over and over again to be more than capable of working in environments with heavy load and numerous simultaneous users. In fact, in comparison to something like Ruby, it historically destroys it.

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

View on HN

It's always hard to talk about these differences because 90% of the time we're actually just chest beating and comparing the length of our respective community's e-penises.

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

Isn't that what Matz is doing now at Heroku?

I think Engine Yard pays 3 people to be fulltime on the JRuby core team and 2 (not sure on that, certainly one) to be fulltime on Rubinius. Microsoft was supporting IronRuby until a couple years ago.

Absolutely. PHP just works and it's easy to make it work. That's the most important thing when choosing a platform. Asthetics are always secondary. It's certainly a pain to deal with inconsistent syntax, but fighting your toolchain is a far worse fate and with PHP, that's rarely an issue.

For a hack, maybe.

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.

> Once things start moving smoothly, they tend to continue to work smoothly.

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.

But, I don't use the languages those cool kids are using. :) I imagine I would have to formulate a very defensive strategy to deal with breaking changes that would gobble up my productivity gains from using said cool language, just like the people that use Mongo have to DIY the checks that RDBMSes get for free.

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.

> I use Java and C++

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.

Mack Truck

When you're trying to ferry boatloads of bits down the information superhighway, the Mack truck starts to look pretty good. Sure, the automatic transmission Mustang is cheap, quick to acquire, and easy to find drivers for, but you have to get 10 of them for every Mack truck's worth.

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.

> But guess what? Code that was written in PHP3 over 10 years ago works just as well today under PHP5.

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.

> legacy installs of old PHP versions around to run business-critical processes

Why? Your code should work in the latest version. Can you give an example?

"See NodeJS and Python for examples."

What's an example of the Python community doing this. Usually Python get's criticised for being overly-conservative if anything.

http://www.python.org/doc/essays/ppt/euro2008/Py3kEuro08.pdf

Funny, my experience is that learning to read the idioms (and write the most convenient idioms) of the language is an upfront penalty, and once you've made the investment things start moving smoothly.

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.

(You know, the funny thing with downvotes is that you never know if you just made someone uncomfortable, or if there's a credible argument against what you just said. Though one tends to assume that if the later were true it would have been employed along with -- perhaps even in stead of -- the downvote.)

The best way to deal with a downvote is to assume that it was an accident.

It doesn't "just work" for Facebook though, look at all the effort they have exerted to be able and use it. They don't get the main benefit of PHP, but still get all of its flaws.

Nothing out there "just works" when you are at Facebook scale.

I'm referring to the quality of the implementation, its performance profile, the soundness of the type system and syntax, and -- like the original post -- measuring relative to the state of the art in JITs, including the JVM.

If the JVM is state of the art, how many applications of the scale of Facebook are using it? A serious question, as I don't know of any.

The JVM is one of the most advanced production-quality JITs available.

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 also in my experience a massive memory hog, makes deploying your web application a pain (restarts anyone?), and is much more complex to develop for. 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.)?

> It's also in my experience a massive memory hog

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.

Reply on news.ycombinator.com