Hacker News Reader

Comment by neilk | Hacker News Reader

PHP has a lot of virtues. It's fast. It has libraries for almost everything a web programmer needs. Deployment is trivial with SCP and with rsync scales to hundreds of machines easily, with barely more infrastructure than a shell script.

Even its supposed deficits are advantages sometimes. PHP stops you from a lot of temptations to go non-REST. Anyone who's seen a Java project where the web server is spawning multiple threads per request can understand.

It just gets incredibly annoying when you try to do anything complex with programming logic. Due to its rather low ceiling of abstraction, PHP encourages you to cut and paste rather than refactor. Again, not actually a problem for many, until you get to a very advanced stage (say three years) and how many projects even last that long?

View on HN

PHP is very good for little, dirty projects coded in a weekend, but also for big, long-running projects (well, maybe Java and Rails are better for that).

Facebook, Yahoo! and lately (at least, looks like) twitter (that's just a guess after seeing their server-status pages) do use PHP. I do, also.

You can build huge projects using a self-made (or external maintained) abstraction structure fitting your needs (database, data clustering, middleware). Or just a countdown page with the days before the next party (?). And, in both examples, it wouldn't be slower to code things with PHP than with RoR.

Using PHP does not mean that it is turtles all the way down. Best tool for the job, i suppose.

Twitter uses a combination of Ruby and Scala, by the way.

You're right.

I should have been more precise. I should have said the vast majority of web development is not complex, not web development is not complex. PHP is a good fit for the majority of projects. For exceptionally large projects (the far right of the distribution), the weak abstraction may impose a penalty.

"Again, not actually a problem for many, until you get to a very advanced stage (say three years) and how many projects even last that long?"

Two of our oldest clients who also happen to be the busiest and most profitable have been with us for 4+ years, and have been requesting feature changes, etc., without a total rewrite.

So, from my experience, enough.

By fast, you mean 70 times slower than other dynamic languages?

http://shootout.alioth.debian.org/u32/benchmark.php?test=all...

Nice cherry picking.

I can cherry pick: http://shootout.alioth.debian.org/u32/benchmark.php?test=all...

too: http://shootout.alioth.debian.org/u32/benchmark.php?test=all...

My favourite chart is still this one though: http://shootout.alioth.debian.org/u32/benchmark.php?test=all...

If that doesn't show how optimized Erlang is for certain use cases, nothing does.

Just saying that PHP is not objectively fast. "Fast enough", perhaps.

It's also worth noting that where PHP does well is in direct calls to C libraries; compare the C version and PHP version of pidigits; they are almost identical. A few languages do as well with their native numerical tower, which is very interesting.

> A few languages do as well...

Specifically?

Haskell: http://shootout.alioth.debian.org/u32/benchmark.php?test=pid...

(I am pretty sure GHC uses GMP for its core math routines, though.)

> GHC uses GMP

Exactly, so I don't understand in what sense we could say GHC is an example of languages that "do as well with their native numerical tower"?

http://hackage.haskell.org/trac/ghc/wiki/ReplacingGMPNotes

It is GMP, but the programmer doesn't know that. It is simply a good implementation choice (for speed, anyway), which is what the benchmark measures.

CMUCL: http://www.cons.org/cmucl/

And few of the Ruby programs are re-written for quadcore so:

http://shootout.alioth.debian.org/u32q/benchmark.php?test=al...

And that PHP :: SBCL webpage has a link to "Overall Performance: PHP is rarely the bottleneck (HTML slides)" ;-)

If you work someplace where LISP and PHP are both contenders for the same numerically-intensive task, I agree you should use LISP.

I am curious to see evidence of the encouragement to cut and paste. Especially now that 5.3 has real first class functions, I can not see what paradigm/feature (other than macro expansion) you are using in another language which can not be done in php. Well ok mixins would definitely be nice...

I don't have evidence - I'd need a study for that. It's just one guy's experience.

Ok, maybe PHP 5.3 has this now, but previously, the lack of anything lambda-ish made some refactorings just impossible. Even with Java you could make a functor that, while ugly to code, would be reasonably performant.

As your comment shows, PHP spent most of its life as a procedural language and it took a few versions to get objects right. And being not-strongly-typed, refactoring tools are necessarily incomplete or primitive. I just went Googling and it seems that many PHP devs think that refactoring is the same thing as applying a regular expression search and replace to their codebase. Compared to what's possible with Java plus IDEA or Eclipse, it's no wonder PHP devs hate to refactor.

Lastly: PHP encourages you NOT to separate presentation and logic. This is why big PHP sites tend to use some other templating language even on top of PHP. The barriers to refactoring when presentation and logic are commingled should be obvious.

"PHP encourages you NOT to separate presentation and logic."

Is this a stated policy, or are you inferring it based on the structure of PHP being embedded in HTML?

There's nothing about PHP which prevents separating the two. There are even the shorter tags and braceless syntax, which are especially friendly to templating. Eg,

    <? foreach($pages as $page): ?>
    <h2><?= $page->title ?>
    <div class="content">
      <?= paragraphs($page->content) ?>
    </div>
    <? endforeach; ?>

BlogPost blogPost = BlogPost.factory("post");

Ahhhhh, Java.

I've been trying to implement rubyisms in php for fun and got some pretty cool mixins functionality working. Requires php 5.3 though: http://github.com/huberry/phuby

Wait, how do you deploy with with scp? What happens when you drop a file locally?

He's saying that all you have to do is post the file on a webserver with PHP installed and it should work. No compiling. No raking. No installing Passenger, Rack, etc...

I'm a Ruby guy, but I do recognize that PHP deployment is generally fast, smooth and easy.

That exact same workflow exists for Passenger. I'm not even sure you can install Rails without Rack anymore. And installing and deploying a fresh Passenger install is easier than deploying a second app on a Mongrel/Apache cluster; it is very, very easy.

I know the first time that I tried to set up Passenger with Sinatra- I had some issues, despite following tutorials. I kept having to touch some file to get it to read the new files and wasn't really working as expected. PHP just seems to run after I apt-get the php stuff and drop the files in there.

But yes, generally Passenger does the trick.

I've consistently had problems deploying Rails apps. I can usually work through them, but it has never once been smooth.

It must be me, though, because every time I mention it, someone accuses me of being an idiot or trolling.

It used to be way complicated, but Passenger has made everything orders of magnitude easier. Tried it?

I understand the above, I was asking something else.

Your app machine pulls the new version from the source machine via scp, then changes a symlink. like a poor man's rsync --backup

I'm not sure what you mean by "drop" a file.

Small websites with low cohesion between pages can probably get away with scp or rsync and nothing else. For a more highly trafficked website, you'll hide server instances from the outside world as you update their files and configuration. But this still isn't rocket science.

What I think they mean is that if you remove a file locally, it is still probably accessible on the production machine if you just use scp to copy the files over directly. Rsync is a better option for this if you want to ensure locally removed files are in fact removed on your production machine(s).

I haven't done PHP work for almost 5-6 years, but when we did it, I had post-commit scripts set up in SVN (or was it CVS back then?) that if a commit was tagged "production" would trigger the production server to perform a fresh checkout. That was the only deploy step needed.

Funny, but you can get the same type of setup working with any language. Scp a WAR file into the appropriate Tomcat directory and your Java project is good to go (no reloading of the appserver required). Or, if you have auto-reloading of modules setup in Python, you can do the same thing.

So, this type of deployment isn't just for PHP... but with PHP it is the default (only?) method.

Reply on news.ycombinator.com