Hacker News new | past | comments | ask | show | jobs | submit login
PHP is much better than what you think (potencier.org)
248 points by timmipetit on July 4, 2012 | hide | past | web | favorite | 334 comments

For reference's sake, this article is written by Fabien Potencier, the creator of the symfony framework. This guy's probably single-handedly responsible for lifting the PHP community to a higher level, by making great software (which, when he started, was pretty unique, with horrible hacks-upon-hacks like CakePHP being the norm), and by showing people how to do so.

A great part of Fabien's work is that he pushes people onto the latest releases. Symfony2 cannot be used without PHP5.3 which is great of keeping people's servers more up-to-date.

Frameworks such as CodeIgniter were guilty of keeping compatibility with PHP4 for far too long.

The world of PHP is a nicer place if you are on the latest version and are aware of the latest features such as namespaces etc.

It's a double-edged sword however.

Users stuck on PHP 5.2 will miss out on potential security fixes to Symfony 2. This can potential compound an already bad situation.

I'm not saying Fabien didn't have good reasons, more playing Devil's Advocate.

Symfony2 is not compatible with php-5.2 and never was.

Python will be under the same situation when the big push onto python-3 finishes over the next ten years. The vast majority of applications runs on python-2 (for performance and backwards compatibility reasons), however that is changing.

If only cheap shared hosting was consistently up to date :<

If a host doesn't stay up to date and doesn't let you stay up to date, you shouldn't be using it!

I'm referring more to end-users of PHP packages :/

I feel for you :(

If people are so incompetent that they can't choose a decent host or install a recent PHP (or deploy on anything but mod_php) then there is probably nothing that package maintainers can do to rescue them, no matter how much they want to.

End users need more help but there are lines between "end user" and "needs to learn things" and "stubborn idiot". If you want to write and deploy web apps, it is your JOB to choose a halfway decent host, keep dependencies up to date and deploy with some appropriate technology!

It's not reasonable to host symfony on anything less than a VPS. It can be done, but you can also punch yourself in the face.

Servergrove.com has the best options for symfony sites IMHO

For what it's worth, CakePHP was a hack to get PHP working as it properly should. Our base object class was made so that PHP4's broken object model would work as expected. It has also gotten a lot better, but has also taken a different approach to application development than many of the other available PHP frameworks.

Indeed a good point, fabien is the catalyst in the current generation of PHP projects, just take a look at Symfony2, Symfony CMF, Silex, Composer, Doctrine, ... they all spawned in the trail of his work. I actually wonder how he gets so much work done.

I think Doctrine is not related to his work. The Symfony CMF, while part of the Symfony community, has been mainly pushed by companies like Liip AG

Projects like Doctrine & swift mailer for email have been adopted and had development funded by Sensio @fabpot's dev shop.

So while not a tightly coupled part of Symfony they are related through developers, community, and funding

The recent PHP releases are nice, but is there any plans about .. pardon me .. rewriting the core libs ? I guess they're close to zero. Even with a nice Object model, traits, closures and literals .. whenever I see old core functions poke it hurts. At the same time the world has moved: Scala, Go .. PHP still looks odd to me, even with his new found maturity.

What's so horrible about CakePHP?

Admittedly, I used it a long time ago. Back then, it was obviously never really used by any of its developers for things beyond the trivial "Blog Tutorial". For example, you couldn't reasonably put model-related code in your model classes, because the model data (coming in from the ORM as nested associative arrays) were structured subtly different depending on how it came in (i.e. on which ModelPeer the query originated). This effectively forced you to make fat controllers and useless models.

Additionally, I know of no framework that reinvented more wheels than CakePHP.

Its legacy (who wants to still support PHP4?). AFAIK, it's no longer maintained; I believe all the core development is now taking place on the Lithium project: http://lithify.me/

None of these things are true, I don't know where anyone comes up with this stuff. Sounds like a smear job more than anything. CakePHP2 is PHP 5.2.8+[1]. It's still being maintained and 2.2 was released this week[2]. Lithium is not a real 'fork' from Cake - rather it is a project that two of the Cake devs were working on as a 'next gen CakePHP' but decided to make into a separate project - the two frameworks don't share any code in their 'production' releases. Lithium has a much smaller community and is still poorly documented (as far as I can tell having tried to use it for a project).

[1] http://book.cakephp.org/2.0/en/appendices/2-0-migration-guid...

[2] http://bakery.cakephp.org/articles/lorenzo/2012/07/01/cakeph...

> Sounds like a smear job more than anything.

Not at all. I'm sorry you misunderstood. Cake has been quite good to me over the years. Ever since I switched to Lithium I haven't looked back.

Wrong wrong wrong wrong wrong. I can see you posted this without doing so much as a single google search pointing your browser to "cakephp.org".

I am interested in hearing skrebbel's response to this question however (what makes cake so horrible).

Goodness. Sorry.

Perhaps I just misunderstood. To me it seems sold as the successor to Cake. http://www.meetup.com/lithium/

The Lithium folks (nate & gwoo in particular) split off from the Cake core team. There was some contention but generally speaking I think everyone is still friends. As for lithium being the successor to cake 1.3... well certainly nate & gwoo feel that way, that's why they built it. :) And certainly phpnut & mark_story don't feel that way, that's why they are still driving forward with cake 2.0. Anyway they are both cool projects but I was reacting strongly to your assertion that cake is "no longer maintained", which is as accurate as saying RoR is no longer maintained and has been officially superseded by Node+Express.

CakePHP 2.x did a major rewrite of nasty parts and dropped support for PHP 4. It's actually very well done and much more consistent now.

Isn't Lithium just a fork? CakePHP 2.2 was released just a few days ago and they dropped PHP4 support in 2.* I think.

It's not a fork, it's a separate project by 2 former Cake developers.

> AFAIK, it's no longer maintained

False. Last commit was 18 hours ago.

yeah he has done an amazing job.

PHP is easy to deploy on. That's it. That's why it's popular. It's braindead easy to go from text editor to web URL, it's braindead easy to unzip someone else's project and run it. It requires virtually zero sysops experience to be able to use. You don't even have to worry about setting those +x bits like you used to in the good old cgi-bin days.

For those of us who aren't afraid of a little ops work, there are far better options, and I say that as developer that's been using PHP regularly for going on 13 years.

"PHP is easy to deploy on. That's it. That's why it's popular. It's braindead easy to go from text editor to web URL, it's braindead easy to unzip someone else's project and run it. It requires virtually zero sysops experience to be able to use. You don't even have to worry about setting those +x bits like you used to in the good old cgi-bin days."

And that's exactly why PHP is the better choice for those of us who distribute software to non-technical users.

Spot on - you nailed it.

The end user counts here, big time. A lot of the products out there would have precisely zero traction if they required literally hours of piddling around.

If you compare it to JVM based commercial offerings, and I'll pick Crucible as an example here, it requires:

1. Find a working JVM that matches it.

2. Piddle around with PATH settings and JAVA_HOMEW.

3. Unzip it.

4. Lots of database configuration.

5. Frig around with ACLs.on disk so it can actually write to its home directory.

6. Frigging around getting it to run as a service using a JVM service wrapper or init script that you have to write yourself.

7. Extensive backup/restore scripting.

8. Hours of dredging through Atlassian's shitty web site.

9. Fuck around with Tomcat to persuade it to work behind a proxy.

10. Set up an IIS ARR or apache AJP/HTTP proxy in front so you can serve it on a decent URL or port.

This applies to anything with stateful that requires any intevention other than copying files. That includes Python, Ruby, .Net (which is less painful I will say), Java, Scala, Clojure, common LISP. You name it.

The only things that it doesn't occur on are: ASP, PHP.

Most stuff in PHP is:

1. Unzip.

2. SFTP it up

3. Change the connection info in config.php

4. Run install.php and follow instructions.

5. Done.

People don't care about nginx vs fastcgi vs apache vs this vs that. They just want it to work and PHP gives a viable and simple solution to that.

The funny thing is that if you do care about nginx and fastcgi you can get blazing fast high-volume/low-overhead php hosting with varnish + nginx + php_fpm.

Not to be a hater, but what's funny about that? The point is exactly that. Most people don't care about "blazing fast".

Right, most people who decide to use PHP aren't overly concerned about performance. And the folks who are concerned about it tend to choose other solutions (say, node.js, for example). The funny part is that it's fairly easy to take even bloated PHP apps like wordpress and turn them into high performance sites on very modest hardware.

When you're putting Varnish in front of static content, it doesn't really matter what the backend is, it's going to fly.

But it still doesn't make PHP a good programming language.

I am doomed to fix legacy PHP projects for the rest of my life, because they are so badly written they simply cannot be upgraded to newer versions of PHP.

Yes it's popular and I've even seen designer jobs asking for php knowledge (lol), but that just tells us why it's so hated!

The new PHP might be great, but all those numbers the article has don't tell us how many of those are using newer versions of PHP. I bet 80-90% of everything written in PHP is STILL <= 5.2

Why is PHP so big? anyone can use it. Why is it so bad? When people actually learn how to program, it simply lacks everything.

I have been stuck with PHP for 4 years now and if at any point my boss lets me fix these projects, I'd run away from PHP as fast as possible...

> it simply lacks everything

Can you elaborate on that a little please? What does PHP not have that all the other choices offer that make such a big difference?

How many webapps are installed by non-technical users? I guess for scripts (Wordpress, phpbb, etc.), PHP is the best option for this reason, as they have thousands of installations, but most webapps only have a few.

Hacker News really doesn't like PHP. There's a whole lot of blind prejudice in this thread

Arguments against PHP are as futile as arguments in support of PHP. It's a programming language. The only thing that matters is the person using it. I'm sure Ruby, Node and Go are super duper awesome in a lot of academic ways, but unless we're talking about awesome things that have been made with them, it's just blah blah blah boring opinions no one should care about.

> Hacker News really doesn't like PHP.

But Y?

    function Y($F) {
        $func =  function ($f) { return $f($f); };
        return $func(function ($f) use($F) {
                return $F(function ($x) use($f) {
                $ff = $f($f);
                return $ff($x);

Honestly, and with complete sincerity, that just means you're a bad programmer. It has nothing to do with the language. And trying to correlate the two is makes you look even worse.

Did you mean to reply to a different comment?

No. Why do you think the parents sample code is an example of quality code?

I think there's a grammar problem with "that means you're a bad programmer".

Anyway, that's a joke implementation of the Y combinator[1] in PHP.

[1] http://en.wikipedia.org/wiki/Fixed-point_combinator#Y_combin...

I would fire anyone who wrote code like this in a real app. Surely there can be another way to achieve the same result with a much cleaner and maintainable implementation. Code like this is written by prima donna programmers who have no respect that other people will someday have to read and maintain their code. I say this about any similarly-convoluted code, not just in PHP.

You can write that code in almost any language and it will look bad and be hard to mentally parse.

But that's beloved ycombinator! Non-godlike developer can't mentally parse this unless he reads this: http://worrydream.com/AlligatorEggs/

That might be true, but it's a lot easier to do in PHP than Python for example

I looked at rosetta code - they both look pretty similar in clarity. Compare to JavaScript or R, which are much more legible.

"The only thing that matters is the person using it."

Well, sure, I guess if you're really strange, you can be as efficient with Brainfuck as you can be with Python.

I don't think not liking language so broken as php is a blind prejudice. That language is garbage. His creator said so many times. You don't have to care about that, but don't act like it's not true.

It would be easier to "act like it's ... true" if that statement weren't so damn objectivist. It's a non-ideal language that runs most of the web. There's an incredible nuance to that truth that makes it difficult to say that it's "garbage" (useless? no. unworthy of your time, maybe. I don't know what that means) I just don't get how people have time to be such puritans about things that don't immediately pertain to them and need so badly to make a binary judgement.

Disclaimer: never touch the stuff myself.

> I'm sure Ruby, Node and Go are super duper awesome in a lot of academic ways

I find Hacker News loves PHP in comparison to most places developers hang out. Mostly because of the prevalence of the kind of anti-intellectualism on display in your comment.

Some of us have used PHP for years AND many other languages and have a basis for comparison.

> It's a programming language. The only thing that matters is the person using it.

No! Please see "Beating the Averages" [http://paulgraham.com/avg.html] (skip to "The Blub paradox" for tldr)

It it true that a lot of discussion here is pointless evangelization and bashing, but the argument "programming language does not matter, only the programmer" is even worse. If that was true, there would be no difference between a C# programmer and a Visual Basic programmer. Languages would stay the same with no initiative to change. Yet they do change and evolve. Programming languages vary in power, even though they are Turing-complete.

>Hacker News really doesn't like PHP. There's a whole lot of blind prejudice in this thread

PHP apologists make this claim every time PHP is mentioned here. And yet the threads are always full of these apologists, claiming PHP is awesome because facebook uses it, or because every cheap shitty webhost has it installed. Never making any actual argument that PHP is good, or rebuttal to the numerous arguments that PHP is bad. I'm sorry, but for a site that is supposed to have an intelligent, technically literate userbase, HN has far too many head in the sand PHP supporters, not too many PHP haters.

> And yet the threads are always full of these apologists, claiming PHP is awesome because facebook uses it, or because every cheap shitty webhost has it installed. Never making any actual argument that PHP is good

That is the argument. PHP is good b/c it allows a lot of people to be productive. C is probably a better written language then Ruby, but it doesn't matter b/c if you're doing web development you're not going to be as productive in C as you will be in Ruby.

PHP allows a lot of people to be productive.

Python/Ruby/whatever language higher up the power curve allows fewer people to be more productive.

Is it really that hard to understand that different levels of expertise suit different tools?

Then these threads are like carpenters arguing that hammers are stupid because we've invented nailguns.

They are, a bit. There are also poorly made hammers in this analogy as well.

The big difference is you don't have people in professional carpentry forums arguing that hammers are better or just as good as nailguns and if you disagree then you are an anti-hammer elitist. But our professional is a young one in more than one way.

I agree. Once you've gone nailgun you never go back. I haven't used a hammer on my woodworking in years.

And what about cross dowels! Don't get me started!

>That is the argument. PHP is good b/c it allows a lot of people to be productive

That isn't an argument, because every other scripting language also allows a lot of people to be productive. If A is equal to B in one respect, and far worse in dozens of other respects, pointing out the one way it is equal doesn't make an argument that A is good.

> If A is equal to B in one respect, and far worse in dozens of other respects, pointing out the one way it is equal doesn't make an argument that A is good.

I didn't state it was better then any other language. I simply made a case that it is a good language.

Did you read the words you quoted? You did not make a case that it is a good language, that is exactly what I said. PHP is not a good language because "it is equal to other languages in one respect, and vastly worse in a dozen other ways". That is the argument you put forth, but it most certainly does not make the case that PHP is a good language.

>PHP is not a good language because "it is equal to other languages in one respect, and vastly worse in a dozen other ways". That is the argument you put forth

No it isn't. I never compared it to any other language commonly used for web development. I never even hinted at that being my argument.

Is this a bad attempt at trolling? You said "PHP is good b/c it allows a lot of people to be productive". Everything else is equally good at that. Simply not pointing it out doesn't make it go away. So your argument is "PHP is equal to other languages at X", even when you word it as "PHP is good at X" while trying to ignore every other language being equally good at X.

>Is this a bad attempt at trolling?

I really have the same question for you. You keep assuming I was implying something I wasn't in my original statement. I do not know why you keep doing this. Clearly we have two different opinions on two things:

1. PHP

2. What I said.

I think we should just agree to disagree on both, because we are not getting anywhere.

EDIT: I just want to add that IMO - you can call something 'good' without comparing it to something else. It would only be a comparison if I called it 'better'.

Will you guys please stop?

> PHP must have done something right, no?

Shitloads of people also believe in organised religion or naturopathy, doesn't mean that's a good thing.

> PHP is the best web platform... ever.

So because it's nearly caught up with other languages and you can install stuff easily if you have the prerequisite of knowing about composer? Bullshit.

I'm sure composer is great, but if your main argument is that PHP requires zero previous knowledge you can't really use that.

Honest question: Do you have more than a months professional experience writing modern PHP?

While I love appreciate the Java ecosystem with amazing stuff like Play framework, Scala, Camel (several apache sub projects actually), Python micro frameworks etc there still is something magic about PHP. I still haven't made up my mind but there is something about really fast turnaround time, transparency, and shared nothing from the ground up. Maybe "Just Works" is the word. (Cheap hosting and next to zero installation just to be an argument but I guess Play is even better in this regard.)

(background: I am allowed to be opinionated on this (programming since I was a kid) professionally mostly Java but also PHP (greenfield, maintenance), and since this is also my hobby I have also scripted non-trivial python, tried rails back at 1.0 etc.)

I have years of professional experience writing PHP.

It's much slower to develop in or get up and running than any other language I have experience with.

Now it was faster when I had no experience, absolutely. That's solved with a few hours of reading docs and playing around. Then the other language is likely faster turnaround, easier to setup, etc.

And besides I'm not even convinced that "easy to set up" is a metric you should be using when you are deciding on a language for a non-trivial project.

I'd argue PHP is, for any project of reasonable size, harder to get up and running than say Rails. For any serious development a PHP developer (some experience, did several years of PHP dev) will have to setup a local instance of Apache/ MySQL/ PHP and deal with making sure libraries installed on this dev server match libraries on the production server.

When it comes to deployment for both Rails (in this case) and PHP you can choose between pretty automated providers like Heroku/ PHPFog which make git deployment trivial or you have to deal with server set up and configuration.

So I'm not really sure these days that for anything except the smallest projects PHP just works any more than any other reasonably popular web language?

PHP 5.4 has a local development server, so even that point is moot. But how hard is setting up apache, mysql and PHP?

sudo yum install apache php mysql


And anyway, for a serious project you need a local dev environment that somewhat mirrors live, and then staging (which exactly mirrors live).

And what % of PHP devs alive today will ever be able to develop in modern PHP without dealing with abhorrent hacks and 4.3 code because the entire ecosystem is a giant cesspit of attempts to work on shit old shared hosting that have never been upgraded.

To clarify, I know that PHP 5.4 is getting to the point of a modern language (despite lacking the deliciousness and usefulness of modern interpreted languages like Ruby and Python), and despite that it's still a complete mess of inconsistent standard library and weird not-quite-deprecated extensions, but the attitude it has fostered, that DON'T GIVE A SHIT JUST MAKE SOME STUFF DUUURRRRR has meant that PHP is essentially the bane of everyone's existence.

Agree it's not that hard, I also don't think it's in any way a bad thing to have to learn how to do it (in fact probably a good thing). Just that learning how to do that is no easier than learning to deploy a rails/ django/ etc app so I'm not sure PHP really 'just works' any more than any other popular language.

You're comparing it to frameworks. You don't need a framework to handle URL routing, input parsing, output headers, etc. You save a PHP file and it's a URL; no routing. The query string, POST body, request headers, uploaded files, etc. are already parsed and sitting in variables in your global namespace. Output will automatically go to the web server, with the appropriate headers already set. No downloading or configuring of frameworks, no deploying. It "just works", to the point that an empty .php file with no source code at all is a working URL.

You can have a framework, you can do your own routing, input parsing, output sanitizing, and all the other things Rails/Django do. But unlike Ruby/Python, you don't need to just to get started on the web.

PHP is really a framework. It includes builtin routing, builtin request parsing, builtin templates, etc. All very tightly integrated. And it is definitely not just an interpreter or library.

And a lot of what you are listing as "just works" are misfeatures which break things and make life unnecessarily hard down the road. They are time bombs, because everything will seem OK up front and the problems won't occur to you until they are already serious and chronic.

There IS routing, it is just implicit, magical routing performed by the server by inspecting a filesystem (e.g. the same filesystem where you have code, databases, password files, configs, etc.) Exposing my internal project organization publicly as a grody looking URL scheme that will become enshrined in all my links? Oh boy!

I don't WANT everything magically parsed by default, regardless of whether I need it for this request. This must happen when and how I specify or the tool is useless to me. Also: it is not a POST body, it is a request body. What do you call the body of a PUT? (And this kind of mis-education is another PHP misfeature)

I don't WANT random mistakes like leaving empty files to pass silently. I want bad code to fail early so I can easily detect the presence of a problem, and locate it. There is nothing worse than silent failure. If you think that silencing errors "just works" then you have your head in the sand. Don't think that users don't notice when a site is broken.

You can use a builtin framework which behaves inappropriately by default and then rewrite later, but why would you actively choose to do this? I think that most people do not choose to do it, because they just don't know. That is why this topic keeps coming up.

It is nice to nurse people along, but it is not nice to require them to nurse your tool along continuously because of all its broken behavior. Their time is better spent working on their own code rather than nursing yours. So perhaps other frameworks could somehow do an even better job of nursing users along, and those specifics are worth discussing. But that doesn't mean the right answer is to hook people on PHP's builtin framework.

And by the time you dress up PHP with a third party framework and other tools to make it fit for use, which you can certainly do, it is absolutely not easier than frameworks in other languages.

Rails and Symfony were pretty much the same framework 3 years ago. Now Symfony 2 is doing things that Rails doesn't. The sheer number of programmers who use PHP versus the amount that use Ruby means that good software in PHP will evolve faster than good software in Ruby.

No, the sheer number of programmers who use PHP just means that there's a much higher signal-noise ratio of half way decent code.

I'd say setting up Rails or PHP takes pretty much the same amount of time unless you need a really specific custom setup.

Plus of course Heroku has simplified it down to git push so setup times are a bit of a given now.

Hahahahaha! No, Heroku has simplified it down to:

- git push

- fix all the stuff Heroku complains about regarding which assets have to be precompiled and where

- repeat until someone who's used Heroku a long time knows your specific problem

I started writing PHP about nine years ago, I'd say about five years of that was within a professional context. I can elaborate more if you like but whilst I understand PHP can be used in an effective way in the hands of someone that understands all the nuance, and I know that PHP enables people to start hammering stuff out with ease, it also enables people that don't know the nuances of the language to write utterly shit code that people like me have to deal with for ages on out. It's as if the low barrier to entry, shit, actually means that the door is wide open to cowboys who just abuse shit to go wrong.

Of course you can write decent PHP, but I've since switched to Python (which I really enjoy, but I'm not biased toward it, I can equally imagine people writing decent Ruby or whatever), but I'd never look back. It's an enabler of people who care little, not for the love of code, or the technical beauty of things, but an enabler of people who don't give a blind fuck about whoever is the next person to inherit their code. No, this is not necessarily a language flaw (because there are many of those, I don't have to elaborate), but what's lauded as the brilliance of PHP, especially lately, is an attitude that fucks people down the line. Look at osCommerce FFS.

I mean, perhaps now osCommerce is a decent product, but it wasn't in 2003, it was a godawful mess, and this is relevant now because there a bunch of hapless fucks that are tasked with maintaining a clusterfuck of hacks based on a version of software X that was made many years back because very little of the people who are developing in PHP give a blind fuck about the next dev to come along.

What's the point of talking about the latest generation of PHP nearly-catching-up-to-decent-interpreted-languages when the entire culture is based around godawful hackery, misuse, half-arsed ports of 4.3 codebases and developer laziness and insecure anti-patterns and other shit buzzwords I can't be fucked to mention but most likely apply to the majority of PHP code out there?

PHP. Never. Again.

Also Wordpress.

I am so sick of this kind of talk.

What language do you like to code in? Really? That's great. Now shut up and go code in it.

What difference does it make to you that I use PHP, Ruby or original ASP?

My website achieves the result I desire. I chose the programming language I use because of reasons that made sense to me and my project, not because I want the approval of a bunch of hipster start-up kids.

To be fair, this has been a while coming. There's so much PHP bashing that takes place now it's ridiculous. People take inefficiencies of the language from 5 years ago, tart them up as crimes against humanity, and then pretend that the only reason PHP is more popular than their language is because most people aren't smart enough to code in their language.

Fabien, though I sometimes disagree with his technical choices, is one of the brightest stars in PHP right now and he's just putting forward a somewhat modest defense of PHP.

A number of these critical articles point out problems from 5 years ago... which are also still problems today.

I would have more sympathy if it were clearly evident that serious bugs were taken seriously rather than being ignored for a decade

Do you have an example of one of these serious bugs?

Every time one is posted (at least once a month), you and others complain loudly about how PHP is being unfairly picked on.

You can't be satisfied

The difference it makes is that with PHP being so popular, it gets a lot of support from cheap web hosts (often being the /only/ language supported), and thus if you write software to be deployed, PHP is the only option, thus it gains popularity, thus nothing else gets supported.

I've been working with PHP for ~8 years, having it as my main source for income, and I'm /still/ finding new and interesting things to hate about it on an almost daily basis. I wish I could go and code in a better language, but that's not an option, because cheap shared hosts don't support any better language, because of people like you keeping the PHP ecosystem limping on.

This comment completely describes my situation.

PHP is like javascript: I use it not because it's good, but because it's what's available.

People can bitch about PHP as much as they like, but my project for today is hosted on a server running PHP 5.2.4. I don't even have shell access; only FTP.

Mate, nail on the head.

The way I see it, is if the final item is as you've envisioned it, what difference does it make what it's written in?

> what difference does it make what it's written in

Tell me you believe that after you've both maintained a project for years as it evolves and had to hire a team to maintain and extend it.

And done this multiple times with different languages.

Damn, the language ecosystem and surrounding community are in the top 3 things that matter most.

agreed. Language is nothing but a tool. A good programmer will get the job done with any tool.

Even good craftsmen prefer top-notch tools over tools in bad shape.

I don't know if PHP is in a particularly bad shape nowadays, since I haven't touched it since 2005, but I do know that tools are just as important as the end result.

To be honest I don't like PHP for exactly the reasons I don't like javascript.

It's easy to write in a way which is stupid.

You can write good php and you can write cool stuff with it. It is easy to non-technical folk to pickup and write a little bit of.

It's also amazingly easy to:

1) Write code which is broken and stupid (woops, left error_reporting(E_ALL) on! silly me. dumped all the passwords out into the website. woops. stabs designer)

2) Write code which is clever, but different from the coding style of every other piece of code in the project (>_> look, my js is so clever, its using closures for everything and events and... oh, you guys weren't doing that? um... ok. Well, now we have some piece of code that only one person knows how to understand stabs self important javascript ninja with spoon).

3) Introduce bugs.

Managing your developers is really the key. If you can keep your php programmers in line, and keep bad code out of your project, php isn't that bad.

...but its that much harder to do when twice as many people are working on the code, and some of them belong to another team.

1) Use a framework like Symfony2.

2) Yes, I agree, PHP encourages you to write esoteric code. Oh wait, what the fuck am I smoking? Better yet, what are you smoking? You can do this in every language I know.

3) Use unit and functional testing. You do use automated testing, don't you?

I think you missed the nuance in #2. Yes, you can write esoteric code in any language, but few languages actively encourage it like PHP.

Read the Symfony source, it's a template for how good PHP should be written.

No, it's exactly as bad _of a language_ as everyone is saying it is. In addition, it filled a void that is no longer a void (dynamic HTML generation in a programmer-friendly way) and has rightfully been supplanted as the go-to language for new projects by a number of superior languages.

Every blog post about PHP mentions its 'easy to set up for non-technical people'.

I can't disagree more. PHP is as easy as any language should be. As if everyone implies the harder a language to use, the cooler it is.

In my understanding a smooth set up experience is a sign community cares about the thing. Extensive and up-to-date documentation means the community is large and not stagnating. A language easy to learn and use is a properly designed language. If the language is hard to understand and write code in, it should not exist at all.

Learning how to use a language is, essentially, an O(1) operation. The constant factor may be high, but it's just that--a constant. Moreover, it should not take you more than a couple of weeks to learn any language (save obviously impractical ones like Malbolge) well enough to use it for a web project. The policy at my school is that you should be able to pick up a new language well enough to use in a class over the weekend; I agree with this. Picking up a language to use for a web project should not take much longer.

A language that's more productive gives you an O(n) benefit where n is the amount of work you do. Assuming you do a nontrivial amount of work, this is always going to outweigh the amount of time it takes to learn even the most difficult of languages.

Now, in a perfect world, a language would be both easy to learn and productive. Unfortunately, in practice, the most productive languages are also the most difficult to learn. However, this doesn't mean they shouldn't exist--quite the contrary even; I think they are more important than languages easy to learn but less productive.

Assuming you'll be spending any significant amount of time programming, don't pick a language exclusively because it is easy to learn!

> Moreover, it should not take you more than a couple of weeks to learn any language

This is why I find the "you can't find Ruby/Python/whatever developers" argument unconvincing. If you're a good software developer, you can learn new languages. You like learning new languages. It's only the crap developers who typecast themselves in one role throughout their career.

And while I don't believe in all the nonsense about ninja coders and only hiring the best of the best, really, the ability to learn a new imperative language is not a very high bar to clear.

You can, but I think the benefits are vastly overestimated. Languages are tools and the purpose of engineering is building, not having a tool fetish. This doesn't mean one should use bad tools, but when learning new frameworks or languages I almost always feel like I am wasting time.

The innovative ideas in programming language design are few and have been known for many years. Learning Ruby or Python instead of let's say Perl will bring you almost no benefits from a technical perspective.

You're essentially paying with your time to enter the Ruby&Rails ecosystem of jobs, consulting gigs, events and so on but you're still building websites using the same protocols, servers, databases, etc.

The innovative ideas in programming languages design may have been known for many years, but at least half are cleverly not incorporated into mainstream languages like Python or Ruby, and don't get me started on Java.

Language design, more than anything, seems to be a field where using actual academic research is passé. C# seems to be the one rare exception among the popular languages. On other platforms, the innovative ideas are all stuck in less popular languages like Scala, OCaml or Haskell.

One major problem I see in this article is that the stats that are cited as "proof" that PHP is the most widespread language are skewed.

* The sample is not representative. It's the top 1 million according to alexa.

* The percentage cited is "x percent of all pages that we can determine are..." which skews heavily in favor of PHP since PHP exposes it's version by default at least in older versions while other languages such as ruby don't. The percentage of pages that turned up as "unknown" is not listed.

* They don't give an error margin for their stats.

* Same is true for the Content-Management Sites. It skews heavily in favor of wordpress because lots of sites do have a wordpress blog installed somewhere.

I do acknowledge that PHP is probably leading by market share, but I'm not convinced that it's as pronounced as Fabien wants us to believe.

Composer is a nice step forward, but it's still behind of what bundler can do. One of it's main problems is that it created a completely new package format, so you need a new package repo - now they're at a respectable 1900 packages. Bundler uses the regular rubygems packages and has the full list of over 40.000 gems available. All tools that used to work with gems still work. There's also a couple of features that it's missing (local overrides for development, binstubs, etc.) but I guess that's just catch-up work. That the commandline interface looks plain ugly is probably just personal preference (heck, why do I need to call 'php composer.phar' instead of 'composer'?) Last but least, it's pretty much a feature-wise copy of bundler - that's maybe "on par" but not "the most awesome and best thing in existence".

So yes, PHP has taken huge steps forward but it's still ugly. You can get shit done if you know your way around and you can write amazing and elegant software in it - it's just harder than it needs to be.

While Composer introduced a new package format, it can be used to retrieve PEAR packages, 'plain' zip files and even git, svn and hg repositories - and these can be integrated even if they don't contain a composer.json file, needing just a little extra configuration in your project. This is a huge step forward and very convenient.


I don't know how Bundler handles this and it probably isn't even needed, as gems are just the standard in Ruby but PHP didn't really have a standard besides PEAR and Composer brings everything together.

Well, it's not needed - that's my point. Bundler just uses the one well-established format for packaging libraries and declaring dependencies. Even git repositories and local code uses the same depency-declaring format: A standard gemspec. Otherwise bundler just stays out of the way to do it's main job - dependency resolution. There is no such thing as two package formats in the ruby world. There is now in the PHP world - PEAR and Composer (and zip and tarfiles). PEAR has always been severely lacking - no way to install two versions of the same PEAR package, improper dependency-tracking - so I guess that's required. It's probably a huge step forward, but it's still not "better" to be able to track two package formats "with just a little extra configuration" instead of "it works just fine without extra work with the default package format." And that's exactly what the article claims: "Yes, PHP has a better dependency manager than any other languages.

I didn't mean to say it is better than all other dependency managers and basically didn't want to argue at all. My point is just that I am happy that Composer is around now, as it lets me include all dependencies from various sources in a convenient and reliable way. So no matter which dependency manager for which language is 'the best', Composer definitely means better times for all PHP developers.

Seems that Ruby had one good standard solution with gems for a long time, let's hope that Composer has a similar bright future. From my perspective, it's already the standard and including a composer.json file is a 'best practice' for all 'well-connected' PHP developers releasing a library these days.

> (heck, why do I need to call 'php composer.phar' instead of 'composer'?)

You can.


    $ curl -s http://getcomposer.org/installer | php
    $ sudo mv composer.phar /usr/local/bin/composer
    $ composer --version
      Composer version 6573fd3

right. I could write a short shell wrapper as well - but why do I have to? I don't have to with pip or bundler.

Uh, no. See, those instructions are from the getting started page. Why do you have to? Because, you can install composer just by downloading it and running it. You dont need to "install" it. This is handy on shared hosting environments where you won't have root.

How can I install bundler on a shared hosting environment like composer?

Well, yes. I can install bundler on a shared hosting environment where I don't have root. In fact, pretty much all my installations are non-root installations. Still, I don't have to manually move it around, symlink or shell-wrap it.

It's not a deal-breaker or a major nuisance that I have to do it, it just fits in what I'm used from php: it gets the job done, but feels unpolished.

> Well, yes. I can install bundler on a shared hosting environment where I don't have root.

So what command do you run to get that installed like that?

> it gets the job done, but feels unpolished.

Unpolished like make && make install.

> So what command do you run to get that installed like that?

"gem install --user-install bundler".

I think at this stage it would be tempting to give some kind of penalty to PHP good/bad posts. Pretty much everyone who cares one way or the other has taken a position and there is a minimal amount of people actually moving one way or the other.

Anyone who frequents Hacker News is well aware of the options out there for web development. If some people decide that they like PHP for any number of reasons and produce awesome stuff in it great. If some decide they hate PHP and go produce awesome stuff in another language then that is great to.

One thing is for sure we have seen a lot more of "this is all the reasons that PHP is bad" than "PHP killed my startup" posts.

There are almost no "X killed my startup posts" at all. Indeed, there are very few "killed my startup posts" of any kind. So that means nothing about PHP. It means that people don't see a lot of benefit in publicly advertising failure and then flagellating themselves for their own choice of tools. People don't do that, they just quietly switch.

People do hear about the problems with PHP, when they are mentioned. It's good to have specifics available rather than just delivering some general subjective statement, which is why we get one article after another highlighting various screwups in the project itself.

You can use any Turing complete language to write programs. That sets an upper bound on how difficult it can be to do virtually anything. But this is hardly a defense of PHP. There are also principles of good engineering beyond "write something which seems to work for now in any way possible".

Namespaces, closures and traits are "all the bells and whistles you might dream of in a modern web language"? Really? Now I understand why Lisp users are smug. And that's ignoring the basic syntax touted as a feature.

What I actually dream of in a web language (or any language, for that matter) is quite a bit more. I want to be able to get event-driven IO without writing event-driven code. I want to get parallelism for free or as easily as possible. I want to encourage smaller functions and reduced coupling. I want good, or at least decent, performance with no especial effort. I want a consistent and elegant underlying design rather than an ad-hoc collection of features somebody thought were useful.

Ultimately, I want a high-level, modern language that's concise, fast to write, easy to maintain and reasonably performant. And PHP is none of those things. Which is why it's no good.

Well, we can all dream, but what are you using now do get things done and make a living? I'm pretty sure Python and Ruby fail your criteria.

Using the "perfect language" is a luxury that I for one can't afford. I need something that I can use reasonably easy and that is sought by employers. The fact that is has event-driven IO and parallelism (what kind of parallelism do you need for web sites?) is nearly irrelevant.

Yes, Python and Ruby do fail my criteria. Which is why I don't advocate them either.

I'm currently using OCaml, but I would probably prefer to use Haskell. They are both far ahead of PHP.

Assuming your website is doing anything non-trivial, parallelism would certainly be useful. Just because it's a web project does not mean you're not doing something computationally intensive, after all. But even if you don't need it, it certainly doesn't hurt to have the option!

Event-driven IO allows you to maintain more connections on the same resources than a thread-based model. There is just less overhead per connection. That's going to be relevant for most web projects. If you could get this for free (that is, without having to rewrite your code like in Node.js), why wouldn't you want it?

Just because employers seek PHP does not make it a good language, or even not a bad language. It just becomes a necessary evil.

Besides, that depends entirely on the job market in your area. Where I am (near SF), PHP is not in very high demand where Java, JavaScript, Python, Ruby and Objective-C are. I've also seen jobs using Haskell, Scala and (obviously) OCaml. This is obviously going to be different elsewhere, but my point is that it's all relative and not a function of any particular language's quality.

I don't know why you are being downvoted for your opinion. Redditors - go back to your caves, you heathen!

Well, OCaml and Haskell are nice, but I wouldn't think of using them for webdev. I would be literally unhireable in my area (major EU country).

I haven't done any webdev in years, but I am focusing on PHP instead of Python because I have more experience with it and it's easier to relearn. It will be a complement to my main skills which are actually mobile/desktop/embedded dev.

Yeah, PHP isn't perfect, we all know it has its quirks and oddities, but isn't that part of learning a language? What separates a hobbyist and professional PHP dev is experience, and knowing the correct method around such quirks.

In the end, PHP gets the job done. I've yet to come across a problem in my 11 years that was due to a bug or a quirk that I couldn't overcome.

Whether you defend PHP or rant about it, I still think PHP deserves respect within the programming community. It would be nice to see the end of rants and defensive posts, and for everyone to agree it's down to personal taste and experience. If we (defenders) are doing it wrong, then let us find out for ourselves.

What doesn't "get the job done"?

People who argue for PHP as a language always brings up this one argument: "PHP gets things done". Great. It get things done. Quick and dirty, but it gets things done.

That is all fine and dandy, but what when you need things done proper? How does it stack up then?

Oh. You mean you have to consider input-data as actual text, not as some byte-streams which incidentally maps to the same character-set you used to write your code with?

Oh. You mean I need to have locale-ware date, time and number-format handling?

Oh. You mean I need to actually validate these input-data and sanitize them for SQL injections and all that before sending off to the database?

Etc etc.

When you need things not just "done", but done proper, how well does PHP stack up then?

It is my opinion (as in opposed to fact) that when you add that one tiny, but oh so important clause, all arguments for PHP being the one language which gets things done falls apart.

Or am I being too simplistic?

I think with the proper tools (and I don't mean using the bare language, but enough libraries that give you nicer abstractions), it can be used for doing things properly just fine. Heck we do a living out of building custom apps for customers that range from financial world to data-oriented startups. You just have to know what you are doing, like with any language really.

- The mbstring ext gives you more or less decent transcoding support. I never had huge issues since it's generally ISO-8859-15 or UTF-8 I'm dealing with, but you may have a point. I can't answer conclusively.

- date handling overall is really great in PHP, I don't know about it in details in every language, but I know in some it's a massive pain. See http://php.net/DateTime and http://php.net/manual/en/intldateformatter.format.php for locale aware formatting.

- SQL injection is handled by the PDO db connectors just fine, and all libraries abstracting this basically take care of it. Unless you follow 10 years old tutorials it's pretty hard to have SQL injection leaks.

Etc etc.

The key is just this: know your tools.

I'll play devil's advocate here.

Define "proper"? Does meeting a business need, bringing in money, putting food on the table, and paying the rent mean "proper"? If not, why not?

PHP has a plethora of flaws, but it's still a serious tool and used to build creations of significant value, that can't be ignored. As far as quality, what platform do you use to guarantee quality? I've heard many stories about terribly broken code bases in every language that's out there, from C to Ruby and Python to Java.

By "proper" I mean building a piece of software which has a clean and maintainable implementation, logical semantics, proper encapsulation, and last but not least, which is solid.

That is, should be able to withstand real world challenges and input-data without crashing, failing, silently failing, creating corrupted data or any combination of those things.

Granted, it's been quite a while since I've done PHP, and it that sense the initial point of the article stand true, but when I need something done in PHP, I always find myself spending more time ensuring basic truths which a proper language should guarantee for me are actually true, than I spend writing code doing something.

I find PHP silently failing all the time making debugging code hard. And it makes it hard to do things proper, because you may have failure-modes which you should have been able to catch, but which PHP "kindly" shields you from.

Hope that clears things up.

Right. So by your definition there are no good platforms to write "proper" web applications in, since it takes a lot of special effort to avoid all of those problems in any language (ruby, python, c, c#, java, node.js).

Some languages makes it easier, some make it hard. I would argue that PHP falls into the "hard" camp. And C would definitely be in the "very, very hard" camp.

And then you have stricter languages like C# which makes doing things proper the default, although often at the expense of making other things harder.

That said: This is definitely crossing the line between factual and subjective right now. And I can see how this is a subject open to discussion.

Have you written a production app for PHP in the last 5 years? It handles (out of the box) multibyte encodings, locale-aware number and date formatting, parameterized prepared statements for your SQL, etc as well as most any language.

I'll be intellectually honest and admit that, no, I haven't really touched PHP for anything near a production app in the last 5 years.

But to be absolutely clear: before PHP used to be the only language I wielded for money. I have enough lines of PHP on my back to claim the right to an opinion.

That said, last time I looked into PHP, modus operandi seemed to being focusing on making things easy, not making it easy to do things right.

AFAIK this one quote from "PHP is a fractal of bad design" still holds true and that if you ignore all the other obvious things (wildly inconsistent BCL, etc), it is probably the core reason why I can never bring myself to like anything PHP:

PHP is built to keep chugging along at all costs. When faced with either doing something nonsensical or aborting with an error, it will do something nonsensical. Anything is better than nothing.

AFAIK that's still true, and I find it hard to have confidence in any code written on top of something based on that core tenet.

Edit: Experience clarification

So why did you comment in the first place, in what world do you find it expectable to berate something with no working knowledge?

Also I have no trouble developing PHP code that halts on the first sniff of an error. But yes, with no experience of the language it will happily chug along.

See my clarification. I think I may have been a bit unclear and/or you may have misunderstood my post.

Talking about the PHP of 2006 and then blasting the PHP of 2012 is like talking about George W Bush and then blasting President Obama.

They're almost completely different language, and while PHP 5.3 certainly has warts it's vastly better than PHP 5.0.

Surprisingly, out of all the comments, this one caught my eye. I've been hiring programmers since 2005 that have to maintain or extend PHP systems. In 2005, it was difficult to find programmers that knew only PHP (or Perl, which was still used) who had any familiarity with object-oriented programming. Over time, PHP has bolted on features, and at each point, the vast numbers of available PHP programmers are (understandably) not familiar with those features. And obviously the systems that have to be maintained don't have these features. So the armies of PHP programmers are well matched to the old systems. This eliminates a huge risk to the business -- finding relatively inexpensive developers. This is an often cited advantage of PHP. But only the PHP of 2007 (or so) is relevant.

The PHP of 2009 might be worthwhile for the creation of business value (and possibly the reduction of maintenance-related risks), but as I said, the easily available programmers have no experience in those features or concepts. The more common scenario is that a particular programmer has experience in some other language that already included those features and doesn't mind working on old PHP systems. Believe me, there are not legions of these people.

And regarding the 'PHP of 2012', the major problem isn't the availability of programmers who have experience in the new features (they almost don't exist). It is the availability on distros stable enough to support an SLA or provide a modicum of security assurances. This problem applies to all languages though. I'm just pointing out that the 'PHP of 2012' is not as much of an option as it may appear.

To me, every PHP version being vastly better than the previous version says something: the current version is shit too, it's just going to take another few versions until you admit it :P

Compared to something like python, where version 3 has basically one major improvement over version 2 (ie, a unicode core); everything else was done pretty much right the first time, and massive changes aren't needed.

Heck, you can still use 2.5 (the python of 2006) quite happily today, and you'll be missing out on a few nice features that would make your life easier, but there's nothing wrong with it like there is with previous version of PHP.

If I plot two lines on a graph for you:

y1 = 0.02x + 1

y2 = 0.10x + 0.5

Regardless of the fact that y2 started at 0.5, fully half of what y1 started at, at some point y2 overtakes y1. It's impotent to whine endlessly that a language used to be bad.

So PHP 5 years ago was terrible. PHP today is 'nearly as good' as Python (I'd argue it's better). In 5 years PHP is going to blow Python out of the water.

These languages that are 'better than PHP' have no appreciable market share, and it's not a vast conspiracy and it's not because PHP caters to the lowest common denominator. It's because they suck, fundamentally, at getting things done. WordPress doesn't exist in Python. Symfony doesn't exist in Python. Doctrine does, but PHP has more database drivers than Python so Doctrine is better.

You can be terse, elegant, and beautiful in Python. That's great, but no one I know has ever cared about what the code they're paying for looks like. They care about stability, agility, and testability - things you've been able to get in PHP since 2005.

I think your graph is accurate when it comes to the amount of effort put into polishing each language -- but as to actual quality, I'd firstly say y=1 is the goal (the language is basically complete; you can add more around the edges, but the core is solid and needs no more changes), and it doesn't account for the fact that with a constant large amount of effort as input, progress as output slows down exponentially due to backwards compatibility concerns. As such, I still think that starting off good and evolving slowly is better than starting off awful and rapidly turning into a giant blob of band-aids :P

Again with the scales, I agree that PHP is great for getting things done to start with, and once you've started with something then carrying on using it is easier than changing. That's why my biggest and most successful project still uses PHP, even though experience has taught me that everything else is more productive after the initial setup hurdle~

Stability, agility, and testability have been in other languages for decades, and in all three cases other languages have done them better, so I'm not sure why PHP having them since 2005 is supposed to be a good sign...

> I'd firstly say y=1 is the goal (the language is basically complete; you can add more around the edges,

Not your functions, not your plane, you don't get to define parameters.

> starting off awful and rapidly turning into a giant blob of band-aids :P

PHP has been completely rewritten at least twice.

> everything else is more productive after the initial setup hurdle~

Can you give a single example of something in Python that introduces greater productivity than PHP?

> and in all three cases other languages have done them better

> so I'm not sure why PHP having them since 2005 is supposed to be a good sign...

Now you're just being a pedant. The point is that it isn't 2005 and it's not 1978. It's 2012. Talking about what the capabilities of a language were almost a decade ago is useless.

The PHP interpreter is much like any other compiler or interpreter. It will halt on errors. It will, by default, output warnings/notices for things like accessing uninitialized variables. Like any other compiler or interpreter, you can tell it to hide warnings, or to halt on warnings, or to log them somewhere instead of outputting them. What makes this a fundamental weakness of the language, but not of, say, C, where gcc will also happily compile code no matter how many warnings it runs into?

C is intended to be low-level, like an extra fancy set of macros for writing assembly. It is intentionally not supposed to do that much for you because you need greater control to do things like writing UNIX. Nonetheless, if you use it seriously then you will find that gcc does outright refuse to compile a great many things that it recognizes as broken, rather than chugging along. There is no way to simply suppress all compiler errors because there should not be.

Nobody in this discussion has raised the possibility of writing web apps entirely in C and suppressing all compiler warnings as they did so. That is a scary idea. And it gets even scarier if we are advocating for newbies to start writing web apps that way.

HTML also chugs along at all costs:

You don't have to close tags,.

You can add(misspell) unknown attributes to tags.

<input type="text"> works the same as <input type="foobar">

You can have multiple tags with the same ID field.

You can do ALL that and your page will still render, and probably look just fine. That's a major reason why the web took off. Because it didn't take perfection to get something done. Anyone that wanted to make a webpage could fumble around and make something that looked like a webpage.

Perhaps the web would be in a better place if browsers gave an fatal error if it tried to load a page that doesn't validate ... or maybe there wouldn't be a World Wide Web, much like there aren't any CueCats lying around.

Hey now, I still have my CueCat... I hacked it to work as a standard barcode scanner.

You're being some what ignorant. Modern PHP platforms support locales, utf8, and SQL injection prevention out of the box, and the libraries to do so are vast, varied, and decoupled.

I disagree, just because PHP has recently obtained features long available in other languages doesn't bring it close to being on the same level. All the other ecosystems are still light years ahead in terms of features, and contain fewer gotchas.

What? You mean that while PHP figured out library management the other language ecosystems weren't just sitting on their hands?

Easiest language to learn for non-technical people? I do not believe that comment was made by someone who has tried to teach a non-technical person on how to program PhP. To get started to write a simple thing like a blog, you need to explain concepts like: classes, inheritance, public/private members, global/local decelerations, and context to name a few. Add that with the X number of ways each thing can be done, and the what ways are "right", and what ways are "wrong", and it becomes a huge information load for the student even before getting started writing something simple.

IMO, more important than the language itself are the frameworks built on the language. Ruby might be _the best_ language ever, but without Rails it wouldn't have gotten famous. It wouldn't have mattered so much that Python is a beautiful language if Django sucked. If a good framework came out of the PHP community, we could forget that "PHP sucks". A good framework which prevented you from doing stupid things would be really great. Not sure if PHP has anything like that, at this moment.

I use PHP and Python(Django) - work and play.

I actually think that the PHP language itself is the cause of this framework disparity.

Alot of those nice framework features rely on higher level language features that are missing from or atrocious to use in PHP.


I am not convinced. My argument is not that PHP sucks or that anything else. It is rather that PHP is lexically tied to corner-case development. In that case PHP is very good at some things but not really all that great for others.

PHP started out as being a pre-processor for SGML documents. All PHP code is contained inside SGML program instruction tags. PHP has never changed this, so however it has developed it is still, in essence an SGML preprocessor because even today, all PHP code is contained in SGML PI tags.

This means that your class files, etc. all begin with opening a PI tag....

Now that doesn't mean there aren't some really cool niches for PHP. Using something like PL/PHP and the native XML support in PostgreSQL, you could do some pretty cool stuff. Similarly for lightweight web development there is simply not a better language.

But when you are building a framework where logic may have to be used in non-SGML environments, PHP is a very poor choice. This means when you choose PHP you are limiting yourself to web environments only. Better choices where there is any possibility of escape from the web include Perl, Python, and Ruby.

You've heard of PHP SAPIs right? You can most defiantly use PHP outside of a "web environment". I have PHP daemons managing the sending of email and sms, and another used to manage incoming data that is fed into our local database. These have all ran for years (7+) with no issues.

I have used it for all kinds of things. However your code is still embedded in SGML output ;-)

Erm, no it is not.

Your code doesn't start with a "<?php" tag?

What does that have to do with SGML?

It's the opening of an SGML process instruction tag. That's why PHP code is inherently embedded in SGML documents......

That's why the LedgerSMB project uses Template Toolkit with <?lsmb ?> tags (that and [% %] causes problems in LaTeX).

You seem to think you have some understanding of PHP which you blatantly do not. You've made a nonsense assumption based on the choice of tag used by PHP to tell the interpretor to treat the text following the tag as code and not to direct it back out the SAPI.

Ummm... I think you are missing my point.

<html> <body> <?mypitag ... ?> </body> </html>

That's an SGML document. It doesn't matter where the PI tag is, or what is in it, it's an SGML document.


'<html> <body> <p>fun stuff here</p> </body> </html>'


That's still an SGML document.


# logic goes here


That's an SGML document.

This is not splitting hairs. The reason is relatively subtle.... When you are doing SGML stuff an extra newline or a space in front of the opening tag really doesn't have any effect but if you do any output in binary form, it's a mess.

You are making little to no sense. Sorry, but I've got to give up on this thread.

You are looking at it from the interpreter's perspective. I am looking at it from a document semantics perspective and what this means for more complex application environments.

Let me give you an example.

Suppose I have a GUI application that prints some XML fragments to standard output. The most natural way to do this in PHP is to write an XML pre-processor which happens to make decisions based upon operations in the GUI. In other languages you would print to standard output explicitly and the GUI would be primary. In PHP the XML output would be primary and the GUI would be secondary.

In fact your entire GUI is sort of contained in XML fragments to start with.

Yes, the daemon. The actual interpreter is still thrown away every few requests, because it is leaking memory like hell.

"Yes, the daemon. The actual interpreter is still thrown away every few requests, because it is leaking memory like hell."

I'm talking about the CLI SAPI, NOT the Apache SAPI.

7 years? Really? Cause resource ids in PHP are not recycled, and I figure that at some point during those 7 years, you'd have opened enough connections, files and database handlers that you'd reach the limit of integers and PHP would just abort.

Hah! Yeah, sorry I should have worded that better. They have been restarted as servers have been upgraded / restarted.

I don't follow this argument at all. PHP cannot be used outside the web because each source file starts with <?php ? If I wrote a preprocessor for you so that your files wouldn't start with <?php, what would your argument be?

It would be a lot less of an argument then, and I would be willing to bet that the language would evolve into a far less web-centric area. But in part because of this, if you actually try to do anything outside the web (I have) in PHP, it's not all that pleasant.

Also on the PI tag issue, I would rather keep my PI tags limited to the view or template. it leads to a lot better clarity. and your object classes are no longer technically SGML fragments ;-) This has some nasty side effects if you have a leading space before your opening PI tag and you aren't outputting SGML....

Oh, as a side note, by 'escape from the web' I guess what I really mean is 'escape from SGML-world.' There's a lot of the web that's not SGML-driven and there's a lot of the non-web that is (XML, DocBook SGML, etc).

Bottom line, PHP is a decent tool for working with SGML but it is highly specialized for this. You run into weird things working in SGML mode but not in non-SGML output with things like leading spaces before opening PI tags if you move out of that. Since this is lexically part of the language, I just don't see it changing.

What would happen if you could put a <?python> tag with python code right in a page just like you do with the <?php> tag? Is this even theoretically possible?

I feel like the biggest advantage PHP and classic ASP have is that there is a low barrier to get the most basic dynamic content working. If you're not a programmer, you don't need to understand a framework or a design pattern to get things going.

There's no reason you couldn't. It wouldn't be Python, but you could do it by defining a new file format to be parsed by the server (mod_whatever).

The earliest Python web frameworks were obsessed with this kind of stunt and it gave rise to a profusion of templating engines, some of which look pretty much exactly like what you are discussing.

I think what happened is that people tried it and found that the advantage is not that great, but the disadvantages are substantial for things significantly beyond "hello world".

> PHP is used by 77.9% of all the websites (...) PHP must have done something right, no?

My favorite answer to this is "because millions of lemmings cannot be wrong".

PHP is a horrible language. Like FORTRAN and COBOL. Like BASIC.

Let me be clear about this. It is a horrible language.

Having said that, a good programmer can make good programs even in the most horrible (and I'm deliberately excluding the deliberately horrible ones) language. It is possible to write elegant PHP just like it's possible to write concise Java. All it takes is lots of discipline. Something most programmers, sadly, lack.

PHP is immensely popular and its runtime is incredibly easy to deploy. I sometimes have small fights with Apache to enable some WSGI app (I never remember every detail I have to include in the configuration) but PHP is unusually easy to set up. That probably is a good explanation on why it's so popular on cheap hosting - because it's easy to manage. That also makes it a good choice for quick projects such as hotsites. I prefer to do those on Google's App Engine, but this is a question of taste, not of availability. In all fairness, those sites could be developed in ASP/VBScript and I wouldn't regard that as a mortal offense - they'll live for months under a single release lifecycle. Use whatever gets the job done for less. And programmers without discipline usually cost less.

Much like there are millions of lines of COBOL, FORTRAN and BASIC we'll never get rid of, there are millions of lines of PHP that'll keep running for decades. PHP is a fact of life. I won't be using it for any new projects and would question the sanity of anyone willing to start a long life one with it, but each developer must choose which tools they want to spend their lives with.

"PHP is the easiest language to learn for non technical people".

I believe that is a flawed statement. I think looking at the number of existing sites and using that as evidence that because there are a large number of PHP websites, the website authors must have made some value judgement at some point on the easiest language available and arrived at PHP, is incorrect. I think the early availability of PHP as a web language, the perception of it as an easy language, and the wide install base drive its adoption.

I helped my brother learn PHP and JavaScript at the same time, my belief (at the time) being that PHP would be the easiest server side language to learn. Watching him struggle to: A) find adequate, modern PHP tutorials, B) see good examples of data structures, and C) understand the division between server side and client side development made me question my decision to have him learn PHP. By comparison, while JavaScript lacked a centralized site (php.net) to educate its users, he was able to find more than enough resources to help get learning fast.

Well, the reasons I started learning PHP were:

1. It was the most popular web language when I started (in 2000), the alternative being ASP...

2. It's extremely easy to use and set up. Most starting programmers/developpers work on Windows. If you want to start developping on Ruby or Pythons you have two possibilities:

- Install linux, which (whatever you may think) is not easy for any newbie.

- Try to work out the Windows ports of your programming language of choice. In the case of ruby, you have to find windows installs for ruby, gems, bundler, rake, rails (or whatever app you want to use), git, probably cygwin, your webserver of choice, etc... Most of these elements are not made for the Windows ecosystem and the ports are usually pretty poorly documented.

If you use PHP, you just have to: 1. Install XAMPP. 2. Click on "launch server" 3. go to http://localhost/

This is why PHP is still popular.

"Has made great progress and will continue making great progress" is another way of saying "got it wrong first time and is still getting it wrong now" :P

It took more than 10 years and almost 6 major versions of a supposedly quick and easy scripting language to have short array notation? Or binary numbers? Seriously? And this improves your faith that they know what they're doing?

If all your friends jumped off a bridge while programming in COBOL, would you follow them?

If Visual Basic was a popular language, did that make it good?

Maybe PHP Addiction is real: http://www.marco.org/2012/06/29/php-addiction. It does seem like its users will go out of their way to defend their choice, as if it really matters what anyone else thinks. Jeff Atwood didn't really rant on PHP so much as link to another rant and lament that there aren't any decent alternatives that are as easy for the rest of the world to deploy. He even called for us to quit whining about PHP's shortcomings and do something about it.

Why is that suggestion so offensive? What's wrong with trying to advance the state of the art of Web development?

Did anyone attacking this "rant" actually read the whole thing first?

OK, I hate PHP. It's ugly, and I don't want to code anything with it.

Good developers mostly aren't available to small shops like mine; I don't have anything to get them in. I must do with young, cheap developers anyway. Young cheap developers knows only one language, to be chosen among PHP or Java (that's just the way it is).

So I'm getting a whole lot of interns coming in for two months at a time, and they mostly know nothing but PHP. so we make them code PHP.

They built a nice application in a few months for the quarter of the money I would need to get an half-decent <your preferred language here> developer. Getting more done with less money, from a business perspective that's the only thing that counts.

Using intern developers to write PHP.

I really hope you're using a framework, because that above sentence is a recipe for disaster.

No, we're using careful project management, code reviews, the interns are very happy because they're learning a lot, and the code is tolerable. Code elegance doesn't put food on the table, anyway.

Actually that sounds fine. Good they are learning.

This post reminds me of the infamous Chris Rock routine: http://www.youtube.com/watch?v=f3PJF0YE-x4#t=130s

"I take care of my kids! I ain't never been to jail!"

Oh, not this shit again. This article shows everything that is so wrong about people who continue to defend PHP

/PHP developer for 6 years

I think you forgot to back up an argument there.

Composer has been a game changer for me in the last couple of months. Getting setup on a big framework (Symfony2), or even a small framework (Silex) always felt like a bit of a pain.

As a developer I have great respect for Fabien Potencier and his contributions to the PHP community. Sadly thoguh, I think he's done so in vain. You cannot fix what's infinitely broken.

* PHP may have evolved to support many new methods and features that is expected from a modern language, but mixing and mashing ideas and implementations from other languages in a semingly random fashion doesn't make a language good; only messy. It still and always will lack a proper philosophical design.

* PHP's ecosystem is far from healthy. It's flooded with outdated and/or badly written code, so it really doesn't matter if dependency management is good. Wordpress is proof of this, just look at the source.

* PHP is neither easy to learn or code (correctly). It's just so forgivable that you can do more or less everything wrong and still have a working application. Fabien, you should know this.

* PHP is a resource hog compared to the competition; even with the tiniest stack. I.e. running Node.js will use less then a third of the resources compared to a LAMP stack.

There will never be a "best language" to rule them all. Every situation have different needs. Sure, PHP have filled its purpose during the years, but I'm certain that we've hit peak-PHP. It's the IE of programming languages, and its slow death have already begun.

I'll admit, the new-ish built-in web server in PHP is fantastic and it definitely makes me want to use PHP more often. Configuring Apache, setting up virtual hosts, fixing directory permissions, etc. was horrible.

Composer also looks cool, and I'm going to give it a try. I never understood PEAR/PECL/etc and was never quite able to get them to work properly.

Granted, there has been a lot of PHP bashing lately and by and large, those who bash PHP the most - whether they are right or not - generally have little to no meaningful experience with it and are re-iterating whatever they've read about it. Fact.

However, this is just stockholm syndrome, plain and simple. Fabien is the author of Symfony.

Don't forget to turn off the Easter eggs when you use your default install of PHP (expose_php = off in php.ini). [1]

1. http://en.wikipedia.org/?=PHPE9568F36-D428-11d2-A769-00AA001...

It's like he didn't actually read Jeff Atwood's article, or if he did, he entirely missed the point. It wasn't a rant about PHP; it was a rant about people ranting about PHP! So much heat; so little light.

This wasn't a response to Jeff Atwood's article. It was a response to all the articles, with Atwood's being the "straw."


> Rants about PHP are everywhere, and they even come from smart guys. When Jeff Atwood wrote yet another rant about PHP…

That's not how it reads to me.

PHP is ugly? So are knives and forks but i still prefer to eat with them.

PHP is big because 10 years ago, it was the best choice. Back then, the non-microsoft options were Perl, ColdFusion, Java, and PHP. PHP was the best for web development out of that.

This isn't the case anymore. PHP has been far surpassed by Python and Ruby.

PHP is a wonderful templating language.

Where does my opinion come from? I switch us from PHP to Python after writing a large CMS in PHP.

I've written "large" systems in PHP and some things annoy me, but I imagine this is true with other languages too (I hear from Ruby and Python devs all the time, some things get annoying).

That said, I spend most of my time on the web writing templates, and PHP is amazing at making that easier. There's a good reason PHP is used in ~78% of all web sites -- most of them are basic blogs or content sites.

Most web development is just templating attached to a business model layer, so why not use a language ideal for templating?

Does PHP have a function to generate a new URL that is the current URL with one of the GET parameters changed yet?

After working with PHP for years, I've taken a look at rails and a few python frameworks, and looking back to PHP it makes me sad that I have to keep using a "web oriented language" that doesn't come with basic web features :-(

This is an excellent point that I think too few PHP developers care to admit.

If people who bash about PHP , had used symfony2 framework, they would have changed their mind to some extent..

I love and use many parts of symfony2 (as well as other high-quality libraries); however, that doesn't change my highly negative opinion about the core PHP language. It is still a far cry from desirable, elegant, fluent, or expressive.

If you need to learn a framework then PHP loses simplicity, one of the few things its got going for itself. And if your needs validate the use of a framework, you'd probably be better off with RoR or Django.

Composer is pretty nice, but there's at least once vital package that's missing from it: PHPUnit.

As long as the only decent testing framework[1] isn't in the package repository, It just seems somehow not "official" enough.

[1] which still has more than its fair share of legacy warts

If Fabpot seriously believes Composer is better than Bundler/apt/Maven, then he's crazy.

Have you used it at all? I'm not going to pretend it's better than Bundler, we took a lot of inspiration from it and we may have a few unique features compared to it, but that's it. apt is pretty different anyway since it does system level stuff. Maven I think is insane, it does way more than a package manager should do. That said when you look at Python for example, the package management landscape is a scattered mess, and there is a new "greater better" solution every couple years. I wouldn't call that a better situation than what we now have with Composer.

Maven is actually pretty sweet and good.

I know people have their own "perspective" when it comes to Maven: some said it's too big, too complicated, yadda-yadda. Some said it's the best tool out there.

The thing here is that you don't need to know Maven that much to use it. Especially if you were to use it with IDEs.

People typically use IDE to generate the absolute minimum Maven pom.xml file initially when they set up the project. From that point onward, if you're using mostly open-source library, the OSL website will give you snippet on how to add the JAR in Maven. All you have to do is to copy paste that snippet and you're done.

People who said that Maven is overly complicated typically tried to learn Maven from Zero to Expert rather than to "just use it".

It didn't take very long for me or many of my co-workers to become familiar and use Maven effectively from not-knowing to "yes, we can have Rails-like project structure/automation , deployment and packaging for multiple environment in place".

Sometime I'd argue that there's no point separating Bundler, Rake, and Gems. You need all 3 of them and that's what Maven does (and more but you don't have to know until you do...)

> Some said [Maven] it's the best tool out there.

Generally these are people that haven't tried anything better.

BTW, as someone who uses Composer and Bundler almost daily now (npm occasionally), I must say, Composer is right up there and it does offer some unique features that neither of the other two have.

Let me say this. Composer is probably one of the best things to happen to PHP in a LONG time.

I'm not saying I prefer PHP over Ruby, but given I am frequently tasked with providing PHP solutions, Composer is the way to go.

Yep I have used Composer and Packagist - http://packagist.org/packages/orderly/paypal-ipn-bundle is one of mine. And TBH I agree with you on Python - the packagement management scene there is a mess. Maven I think gets a bad rap - once you find out about http://mvnrepository.com/, it's actually smooth sailing.

Funny. People criticize PHP the language and the PHP fanboys retort by praising PHP the platform.

Jeff Atwood more or less said that we should provide the platform advantages of PHP in other languages in order to steer new developers there.

You can't provide the platform advantages of PHP in other languages because either there aren't enough programmers in that language (Ruby, Python) or that language is fundamentally much more difficult to work with (Java).

There are plenty of people writing Ruby and Python.

There is another reason, which is that some of PHP's design choices seem easy but make things harder down the line.

So create something new.

But I like PHP. Even with its numerous warts, it's the easiest language I've ever written.

Jeff Atwood wasn't the first to say that, by a long shot. PHP devs have been saying it since Rails made Ruby popular. That it's 8 years on, and Atwoods rehashing old arguments is telling.

Yeah we know, weak typing and function parameters inconstancies sucks.

Move along :)

From the article:

> PHP is used by 77.9% of all the websites whose server-side programming language is known.

Selection bias. PHP Has a higher tendency to advertise itself.

Great post. The grammar in the post title has a bit to be desired though. "than what"?

English is not his first language.

Do PHP engineers even know what multithreading is?

ps. I don't mean crontab

Do you even know how many days/weeks/months I've seen engineers waste on tracking down threading issues?

ps. I don't mean sewing shirts.

PHP programs are indirectly affected by those issues anyway

I've technically made $millions in transactions on web sites built with PHP, and I've never had to confront multi-threading.

I would suggest that serving webpages falls into the set of embarrassingly parallel problems. The solution is to saturate your cpu running multiple instances.

You can't polish a turd, but you can roll it in glitter.

"homeopathy" arguments.

"PHP is the best web platform ever", because it (finally) has a decent package manager. And don't mind that far fetched statement, the author will surely delete any rude comments.

Congrats, PHP has a package manager. This does nothing to shake my feeling that PHP's most ardent advocates have little hands-on experience with the more full-featured alternatives. You know, like the ones that also have decent package management without PHP's baggage and limitations.

edit: hell, calling PHP a "web platform" at all is insulting. Maybe if "web platform" is constrained to JSP/PHP/ASP style pages with no more complexity. Don't mind anything that requires websockets or anything other than... PHP style page rendering.

Can we stop with the "PHP is everywhere so it must be good meme"? PHP's availability makes it convenient; it doesn't make it good. I said it before and I'll say it again despite its painful obviousness. If you want to write a random script and upload it to some $2/month hosting, PHP is great. If you're going to build a real webapp that is going to have developers working on it and real users hitting it, you're going to be on a VPS or colo or on your own metal and have all sorts of choices that... have package management and aren't PHP. And if we're talking about throwaway quickie scripts, who really cares anyway?

When I first started looking for work here in Dublin, Ireland a few years ago, I saw tens of PHP web stack jobs, 1 RoR job and no Python jobs. While the tides have turned slightly, PHP web stack jobs here still far outnumber Ruby and Python equivalents, especially at the entry level.

Some developers like PHP because they can get easily work doing it. Businesses likes PHP because they can more easily hire people.

Arguments about PHP's ugly and stupid syntax are moot, it has been enabling companies to get shit done with developers at different skill levels for years.

Yeah - "shit" being the operative word there. The problem I've found is that there's a kind of anti Python paradox at work with PHP:

Better than 95% of the PHP jobs out there are horrible scut work for companies that don't give a shit about quality or decent development, even though it costs them an arm and a leg maintaining their steaming legacy codebase.

The 5% that you'd actually want to work for need to have a series of huge hurdles to keep out the 95% of PHP mouth breathers^W^Wdevelopers who can't really code.

horrible scut work for companies that don't give a shit about quality or decent development, even though it costs them an arm and a leg maintaining their steaming legacy codebase

Damn, you just described my job perfectly.

"Test framework? What's that? Sounds like it'd take up too much valuable programmer time. PS enjoy walking on eggshells whenever you try to change something because there's no regressions."


The best bit about those environments is that the devs who crank out the most code (ie. LOC-wise) are feted, but they're basically just standing in the bottom of a hole, digging.

Ah, fortunately, we aren't measured by LoCs. Instead, we're measured by the number of items we manage to knock off our in-house half-arsed basecamp reimplementation. Not quite as bad, I guess.

> "Better than 95% of the PHP jobs out there are horrible scut work for companies that don't give a shit about quality or decent development"

Show me your data? You couldn't be more wrong about the companies using PHP. The last startup I worked at in San Francisco, well funded and very successful, used PHP. I was approached by many well known names all using PHP, most of them exciting new companies working with edge technologies for practicality, which is a trait that goes great with PHP).

> Show me your data?

Bitter personal experience? I'm a Python dev, but figured PHP and Python would be good to add to my resume. I picked them up pretty quickly, but after working for a couple of PHP places and interviewing at many others, I swore off them and went back to Python.

Also, sounds like your startup was one of the 5%, rather than the 95%.

and for every startup company using php, there are 100 shitty local ad agencies knocking out brochure-ware wordpress sites.

Sounds like a big success for Wordpress and PHP to me

In the sense that McDonald's is a big success for American cuisine, sure.

That's a decent analogy, since McDonald's is a huge success and a model of efficiency in business.

If more fat americans is a success, I guess that makes sense.

I have not found this to be the case. There are a lot of small/medium sized companies that probably started out with a custom Drupal/Wordpress site and have now out-grown it, but don't want to re-write the whole system just so that they can use Python/Ruby.

Using PHP is then a no-brainer and so moving the codebase to Symfony2 is a great option for them. While Wordpress and Drupal command such a large share of the website market, there will always be decent young companies emerging who are also tied-in to the PHP community.

How is moving to Ruby/Python needs a rewrite, but moving to Symfony2 does not?

That's what I was wondering.

I also had a look through the Symfony2 docs. Perhaps it's just me being a Python bigot, but the code there doesn't look any better than the raw PHP: http://symfony.com/doc/current/book/from_flat_php_to_symfony... And the "helper function to render templates" in the section above it also looks fairly deranged. Isn't that included in the framework somewhere?

The bits that do look ok seem to be because they're copying Django/Jinja2 templating.

If you stay on the same web stack you might be able to migrate one piece at a time.

You also have the option of refactoring the most important or troublesome bits of your app to use Symfony2 while leaving the rest alone.

It's pretty challenging to take one piece of your big web application and migrate that to Python while leaving the rest in PHP. So you'll tend to do it all at once. That's very expensive, and very risky, even if your original ugly PHP site had an extensive test suite, which it will not.

A framework shouldn't (and most all the popular PHP frameworks out there, including Symonfy adhere to this) matter when your business logic is decoupled from from your framework. Yes, you might have to rewrite some constructors. And some frameworks have different features, but can still be carried over if you need it. You aren't beholden to a single code base.

For example, I can easily move my models from Zend to Symfony without rewriting a thing. Decoupling is a wonderful thing.

So, you have this code base you are using, these libraries that are already written, and tested, and working. Moving to Ruby/Python would require that they all be rewritten, and appropriate libraries be replaces.

Moving to another language isn't a weekend endeavor when you have a workflow and toolset built up over a 10+ years of development in another language that, in that domain, accomplishes the same thing.

So don't work for those companies?

I think you'll find a similar situation with companies using enterprise languages like .Net or Java, certainly here in Ireland where our universities heavily teach using those technologies.

Shitty graduates with no real interest in programming still end up in programming jobs. The shitty PHP developers I meet are invariably actually designers winging it as programmers.

It's a bit of a Catch22 as well. We switched to using PHP for our agency client work because it was easier to hire developers. Not only that, but clients actually ask for it by name (and we lost a number of jobs because we didn't want to use PHP). The cycle continues.

There's a good reason for that though.

If you create an app for someone in rails or django or luanode or some such then they are on the hook for maintaining it if you go away or find other work or just don't want to support it. And it's much harder to find devs for those stacks than it is to find PHP devs.

The technical term for that is "network effect".

http://www.welton.it/articles/programming_language_economics (sorry to those who have read it, but it bears repeating)

I have to admit that I've turned down potential freelance stuff when the customer requests PHP (or has signed up for a service that only allows PHP).

Of course, I have a full-time job, and the freelancing is usually to pay for a new guitar or something. Your situation is probably different from mine, and needs must.

I don't mean to belittle you or anything like that, but isn't it your job to consult the client on the best tool for the project? If they are adamant on using PHP, when it's clear PHP isn't suited, perhaps that implied an awkward client.

Not really, they look at it the same way - we're building something for them they need to support long(er) term. It's a pretty simple business decision really. A number of clients have been burnt in the past by having to support something a bit esoteric. Often clients actually ask for Drupal (which we downright refuse to do) for that very reason. They want something that's they'll be able to find developers for.

Choosing the "best" platform for the client has both a technical aspect and a financial aspect. In most cases that I've seen in my 20 year career we probably could have gotten the job done with nearly any technology. The choice was ultimately down to whatever platform was most comfortable for the developers or, to be honest, just plain snobbery on the part of one or more of the team.

Of course there may be an ideal platform from a technical sense. I may have a project and I decide that it's 100% ideally suited for Scala. Using PHP may be only 85% ideal. However, is that really best for the client? Are they going to be forced to blaze new trails for things that are already solved in PHP? Is the client going to be able to find Scala developers when we leave? How about in 5 years? How much are they going to pay for that? Is it worth the 15% of efficiency that was gained?

There is no real correct answer here, but I guess my point is that when you are talking about what's "best" for the client, it's not always just a technical question.

Well, yes, but awkward clients are still clients (read: people who give you money). Some of the consequences of the mentioned effect are that you may be forced to work with awkward clients or employers, or make otherwise awkward decisions.

How many of those jobs are for maintaining old PHP codebases written way back when, though? Basically, what is the ratio of "PHP the sexy web framework" to "PHP the new COBOL"-type of jobs. I can't imagine it's even close to 1.

Most of the jobs I interviewed for back then involved new development. The job I ended up taking turned out to be a ground-up rewrite of a consumer website (which sold for ~€250mm the week after I joined) to bring it from poorly designed PHP4 to better designed PHP5.

Why did they choose to do this in PHP instead of a more respected language? They already had a bunch of PHP developers.

"PHP's most ardent advocates have little hands-on experience..."

And from what I've been seeing, PHP's most ardent critics have little hands-on experience with PHP, itself.

Edit: see this http://news.ycombinator.com/item?id=4198900 current rambling nonsense I'm having to contend with.

Edit edit: the voting is up and down, I can only assume that ~ 50% of this community just don't care about facts and would rather subscribe to witch hunts.

Yeah, sure seems like this guy has no clue about PHP alright: http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-de...

And I guess this guy doesn't either: http://news.ycombinator.com/item?id=4177516

He seems like he does. You might notice I never said no PHP apologist understands PHP, but rather contradicted your (frequently posted) lie that PHP detractors don't understand PHP. Of course, he doesn't offer an actual rebuttal to much, mainly just "well yeah it sucks, but I know it sucks so its ok".

In response your undefined edit: Can you point out my lies?

Is this a joke? I made it pretty clear, and you know that is what I responded to. Quoth you:

>PHP's most ardent critics have little hands-on experience with PHP, itself

"well yeah it sucks, but I know it sucks so its ok"

Sorry, but I really don't see how you got to that assumption. Can you enlighten me to what you are seeing that I'm not?

Read the thread, it isn't like his post went without responses.

Flawed and good are not mutually exclusive. I'm no fan of PHP but I have to give it props. It is a legitimate web platform. No other term is more accurate to describe a tool that is used to drive literally billions of dollars in business and to host content viewed by literally hundreds of millions of users every single day.

PHP is out there. Being put to serious work. If you truly believe that PHP is a terrible and horribly broken tool the most dangerous mistake you could make is imagining that PHP doesn't serve as the backbone of much of the web.

What do you mean by "more full-featured alternatives". To me the main webdev languages look about the same when it comes to the major features that have a noticeable impact on a project. e.g: few projects are affected by the lack of closures

And all the talk about real this and real that. I don't think projects become more real when they're written in Ruby or Clojure. They're real when they work and are useful to the customers...

> To me the main webdev languages look about the same when it comes to the major features that have a noticeable impact on a project. e.g: few projects are affected by the lack of closures

Someone needs to read Paul Graham's essay about "the blub paradox"

I can tell you that the quality and ease of use of your web framework/libraries is highly affected by the lack of closures and other higher level language features. Even if you don't use them, your library developers have more tools and more flexibility.

Malaria is everywhere. It's got to be awesome.

That PHP is so omni-present is not a good thing. It's an opportunity to disrupt web development. It's a lesson that we still haven't learned.


Yes. And now Facebook is spending a ton of resource and man-hours programming around this. They had to write their own compiler!

Also, I think they are trying to move away from PHP as quickly as possible without rewriting the entire site. The new projects and tools are not in PHP; moreover, I think most of the new people they hire never have to use PHP at all.

Finally, just because they managed to use PHP to run a bit site does not mean it is the best web language, or even a good web language. It just means it's adequate.

You get the same issues almost no matter what you write a website in, whether it's PHP, C#, Rails, or node.js. When you get to the level of scale that Facebook is at you are in a realm that conventional web application tooling and frameworks don't cover. If anything the "best" and most trusted platform for what facebook is doing today would be java. Does that mean java is the "best" web platform? Not in the least.

The central fallacy here is imagining that one size could or should fit all, whether it's php or rails or anything.

  > Yes. And now Facebook is spending a ton of resource and
  > man-hours programming around this. They had to write
  > their own compiler!
Is there a project of Facebook scale which does not have "their own" at the very core, no matter initial choice of technology? My understanding is that by solving problems no one had to solve before you are bound to create "your own" stuff. Even for desktop — didn't Excel have it's own compiler?

Do you have inside info on this? I've seen several people from Facebook comment that they are in fact using PHP.

The fact that they're compiling to C++ is a consequence of the slowness of the programming language implementations of those languages that are used traditionally for web development. AFAIK Ruby was and still is the slowest of the bunch.

A couple people I know well spent the summer there (I actually visited one at the old headquarters; it was pretty cool). One now works there full time (the other hasn't graduated yet). I also talked to some fulltime engineers who were not using PHP.

Now, it's reasonable that I did not get the full picture, but the people I did talk did not use PHP themselves and claimed that new projects didn't either. Perhaps this varies per team. My impression was that existing code bases using PHP were still under active development (that is, getting new features) but new projects and new developers did not use PHP.

Interesting. What were they using, C++? I've heard about D...

The particular people I talked to were using C++. But I think there is even a team using Haskell for some internal tools :).

MRI Ruby is actually significantly faster than CPython these days.

Citation needed. Both CPython and MRI are slow - if you need computational speed, use something else. But when your are comparing them to each other, CPython is faster. I don't know where you are getting that significantly faster bit from.

Since most benchmarks are unscientific, this one is as good as any. So here goes:


I suspect that parent was referring to the python 2.x branch, which has been catching up with ruby 1.9, but on most benchmarks started at ~ 3x slower and are now ~ 2x slower.

Since benchmarks are completely worthless, let's just stop this pissing match right now.

> I suspect that parent was referring to the python 2.x branch, which has been catching up with ruby 1.9, but on most benchmarks started at ~ 3x slower and are now ~ 2x slower.

Citation needed again. Ruby 1.9 is slower than Python 3, and Python 3 is slower or as fast as Python 2 on Python official benchmarks.


> Since benchmarks are completely worthless, let's just stop this pissing match right now.

Benchmarks are far from worthless. And pissing match? Asking for citations amounts to pissing match? The parent claimed something that isn't true(ruby 1.9 significantly faster than CPython - that has never been the case). And you are adding python 2.x was slower than 1.9, when 2.x is generally faster than 3.

I love ruby as much as the next guy. But when it comes to execution speed, ruby has always been the slowest among ruby, python, and perl.


Python 2.7.2

    def fib(n):
        if n == 0 or n == 1:
           return n
           return fib(n-1) + fib(n-2)
     for i in range(36):
         print "n=%d => %d" % (i, fib(i))'
python -c 20.69s user 0.06s system 99% cpu 20.807 total

Ruby 1.9.3 def fib(n) if n == 0 || n == 1 n else fib(n-1) + fib(n-2) end end

    36.times do |i|
      puts "n=#{i} => #{fib(i)}"
ruby 11.44s user 0.03s system 99% cpu 11.507 total

I guess since benchmarks are not completely worthless, we should conclude that ubuntu doesn't keep up on ruby and uses 2-3 year old versions.

I wasn't accusing you of starting the pissing match.

> I guess since benchmarks are not completely worthless,

The original keeps getting re-iterated: http://programmingzen.com/2007/11/28/holy-shmoly-ruby-19-smo...

The original author, on a basis of a fib benchmark, concludes ruby 1.9 is faster - that is as flawed as it gets.

Did you try running with Python 3? You will get around the same time as you get with Python 2.7. Pick anything from here http://shootout.alioth.debian.org/u64q/benchmark.php?test=al... and run it with Python 2.7 and ruby 1.9. The programs which are faster with Python 3 will be mostly faster with Python 2.7. 2.7 isn't slower than ruby 1.9; it is faster in most of the cases.

Regarding the fib example, when the original was doing the rounds, I didn't find any explanations from python or ruby implementors. I can't say why, but most likely python has a higher overhead with growing call stacks, and ruby does some optimizations.

Data is not dishonest and benchmarks are not dishonest. What is dishonest is this tendency to cherry-pick only the case which is convenient to you, as you have done here. If you want to talk about Ruby performance vs. Python then you will have to dig into something like the site linked previously, which has many different benchmarks run on a uniform testbed rather than a single cherry-picked case run in whatever way you felt like.

>>ubuntu doesn't keep up on ruby and uses 2-3 year old versions<<

Huh? Since 21 Apr 2012, the benchmarks game has shown - ruby 1.9.3p194 (2012-04-20 revision 35410).

If you're looking at measurements made on the quad core machine, then remember to check the "≈ CPU Load" column to see whether some programs are using multiple cores and some programs are only using one core.

When the comparison would be better without that complication, look at single core measurements -- http://shootout.alioth.debian.org/u64/benchmark.php?test=all...

>>Since most benchmarks are unscientific, this one is as good as any.<<

1) You seem to be using "unscientific" as a nothing more than an insult.

2) Your conclusion "this one is as good as any" doesn't follow from your premise that "most benchmarks are unscientific" -- "this one" might well be different from "most benchmarks".

3) If your conclusion was correct then that wouldn't mean that the benchmark was good, just that it was also bad.

>>Since most benchmarks are unscientific, this one is as good as any.<<

>1) You seem to be using "unscientific" as a nothing more than an insult.

More like preemptively declaring I don't want to deal with HN crowd replying with "but benchmarks are worthless".

> 2) Your conclusion "this one is as good as any" doesn't follow from your premise that "most benchmarks are unscientific" -- "this one" might well be different from "most benchmarks".

IMO shootout benchmarks are better than random benchmarks on the web as they detail the testing environment, provide the source code and can be re-created

>>More like preemptively declaring I don't want to deal with HN crowd replying with "but benchmarks are worthless"<<

It's a dirty job but it still has to be done ;-)

Let them reply and then answer them.

I have only a year and a bit of context since starting at Facebook, but here's my viewpoint.

Facebook isn't trying to move away from PHP as quickly as possible. For years, there have been PHP components (primarily web front-end rendering, aggregation/ranking of data from various sources) and C++ components (primarily high-performance back-end services) and other languages like Python (primarily non-production-path/operations back-end services) and Java (primarily Hadoop-related technologies like Hive and HBase, and services that are heavy users of such), and nothing groundbreaking has changed in this.

New hires use PHP or C++ or whatever language (and often multiple languages) necessary to work on the team and projects they choose to work on. New projects use the languages that make the most sense.

Almost all web front-end work involves PHP - the frameworks and libraries and runtime environment are well-developed, well-tested, well-documented, and well-known.

In terms of HipHop for PHP, the question to ask is: What language could have allowed quick low-barrier-to-entry web-app-centric development in the early days while still delivering the sort of runtime efficiency demanded by the environment? Languages like Python and Ruby may arguably allow the first (but remember we're talking about early 2004 here, so Ruby on Rails was not out, and neither were Django, Flask, and so forth and WSGI had just come out), but would have required a "HipHop for PHP"-style solution as well. Languages like C, C++, and Java may have the runtime efficiency, but it would be a hard argument to say they're as developer-time-efficient as PHP (especially back then).

That's a slightly different question to what one should do today if starting a new venture. And _that_ is also a different question to what Facebook should do today - HipHop for PHP exists, and is delivering performance/runtime efficiency that most languages people mention as an alternative do not. And, the PHP frameworks and libraries and runtime environment exist and allow rapid development of production code. It's actually reasonably pleasant to develop for with those in place.

The HipHop for PHP team is small, but have huge leverage - this small team of reasonably hardcore low-level C++ programmers are making a whole bunch (hundreds?) of PHP developers way more productive (since they don't have to use a relatively slower-to-develop-in language/runtime like C++), and also makes the cost of operating the site go down by making that code more efficient and reducing the number of servers needed.

The same argument could be made of Ruby on Rails, just look at Twitter moving core infrastructure to the JVM.

It could, and I think it should. I am no fan of Rails. But that is a different story for a different time.

The Face Book.

I keep hearing people mention Facebook as a reason why PHP is a great development language but they compile it down to C++ using their HipHop compiler, and from what I understand they develop Facebook _in spite of_ PHP ( http://www.quora.com/Do-Facebook-engineers-enjoy-programming... )

I got downvoted on another PHP related thread here for bringing that up. Can you truly say they use PHP when they've invested a hell of a lot of money into HipHop to essentially allow devs to write additional PHP code and transform it into C++ binaries? It's a strange way of using it for sure, but it seems to be effective for them.

Right, but Facebook supposedly receives 1 billion new comments + a couple billion likes + a couple hundred million status updates daily, and is probably the largest photo sharing site on the net. Twitter gets about 200 million tweets daily and Reddit has 250 million comments total. Disqus is not much larger than Reddit.

So, since most people here are suggesting Python or Ruby, what real world example can we provide that compares to Facebook in order to make sure that these languages would perform better than PHP?

Neither Twitter, nor Reddit or Disqus are exactly the most stable and performant sites out there. So?

I would say that quick and dirty comparisons like this are meaningless.

Google is the real-world example of Python deployment you're looking for, although we don't have the full details of where it begins and ends in their no doubt complex stack. So again, the comparison isn't that useful.

Talking about what languages programmers find enjoyable and productive is perhaps more meaningful. This is where Python and Ruby shine, and PHP falters.

Yes, you can truly say they use PHP. You are confusing the language and the interpreter. I've seen Facebook engineers comment on threads like this and say the same thing I just have.

And just because a big site uses it the language does not become good either, see the availability argument. I think most PHP programmers would not recognize what's running at Facebook as PHP with all the customization they have done.

I very specifically didn't say that PHP couldn't be used to build real products, but that still doesn't (at least on it's own) make it good or make it the best.

I guess the worlds most popular websites, and the vast millions of PHP programmers must all not really exist. They can't exist, and can't be making good stuff, because PHP is just doesn't work.

Here is a list of template languages people on 'real' platforms use:


Airspeed, Castalian, Chameleon, Cheetah, CubicTemp, Django template system, Elements, EmPy, Evoque, HRL Powerful macro preprocessor for HTML, Genshi, Jinja 2, Mako, moody-templates, Myghty, Qpy, PML, pyratemp, Spyce, SUIT, Tempita, Tenjin, Template Toolkit, Templite+, thrases, ClearSilver, HTMLTemplate, JonsPythonModules, meld3, PyMeld, Pyxer, pso, Sprite, teng, webstring, XSLTools, PyPa, Genshi, kajiki, htmltmpl, Kid, SimpleTAL, CherryTemplate, AsciiDoc, Markdown, PyTextile, ReStructuredText, txt2tags, PottyMouth, Creole,


Radius. HAML. cs/Template. ERB, eRuby, Erubis, Galena, Tenjin, Liquid Markup. Ruty, PageTemplate, Amrita, Amrita2, Kwartz, Markaby. Maline. Builder::XmlMarkup, RedCloth, BlueCloth, RSmarty, Tempura, TAL, Curtis / Punk, Erby, RBML, RTALS, Tie, RVelocity, RailTags,


FreeMarker, SiteMesh, StringTemplate, Tea, Better Templates for Everybody, jxp, LSP, JCopist, Dynamator, RTFTemplate, Velocity, JByte, Jamon, JDynamiTe, WebMacro, Viento, IKAT, Bluprints, Transformica, Hapax, MiniTemplator, Xtempore,

_Not a complete list._

PHP is a pretty good template language, with pretty amazing documentation.

To deploy, you just upload a file.

You could walk outside now, and start yelling "I NEED A PHP PROGRAMMER!" and you'd probably find someone pretty quickly.

There are millions of hosts to choose from at tiny prices, who can provide support because they know the platform.

Saying PHP is good because Facebook use it is kind of like saying phone hacking is good because it was utilised but some of the UK's most popular newspapers...

I'd be interested to know if there's any commentary from people high up in Facebook on whether they'd use PHP again if they were starting now?

Look at Quora, Path, and Asana, the three most successful consumer startups started by former Facebookers.

None use PHP.

Never heard of them.

You are deliberately trying to miss the point. But in the off chance that you don't really get it, the point is quora, asana were started by early facebook programmers, and they didn't use PHP. If they liked PHP so much, they would have used it.

I can't find a citation, but there was a thread where a fb engineer claimed fb's internal PHP wiki starts with "There are two kind of people. People who hate PHP, and people who don't use PHP."

> If they liked PHP so much, they would have used it.

Or they got tired of being bullied by people like you.

>> If they liked PHP so much, they would have used it.

> Or they got tired of being bullied by people like you.

Or they really aren't a fan of PHP?


And that's relevant how?

What kind of an analogy is that? It is not only flawed but does not relate to your argument. I guess the point that illumen was trying to make is that PHP can be used in popular real world applications and is "proven" to scale. Just like Facebook, you can look at Wikipedia, Wordpress, Tumbler or earlier days of Youtube all of which was/is written in PHP!

Be comfortable with the language you prefer and quit whining about the rest!!!

In no way whining about PHP, I still maintain various projects which use it and for which I think it's well suited.

The analogy was only meant to demonstrate an objection to arguments along the lines of "it's used by something popular therefore it's good" or "lots of people use it therefore it's good" which seem to be common points put forward in favour of PHP.

Popularity/ use by someone popular may be an indicator of quality but it very often isn't, the analogy isn't intended to go any further than that!

No, it's nothing like that.

There is such commentary from people who left facebook to do their own thing. They did not use PHP. http://www.quora.com/Quora-Infrastructure/Why-did-Quora-choo...

I guess your point is that there are too many options. But you have artificially inflated the count as you have made this point. Most of the things you have listed are not applicable (either not used any more, or are not general and were never used to compose full HTML pages). Cut out the ones which are not actively developed and you only have a handful for each language.

Since the problem seems to be that you need someone to choose for you: use Django on Python, use Rails on Ruby, and for each one use the templating that comes with it. If you switch to another framework, use its templating language. If you are advanced enough to use a microframework then you are advanced enough to plug in Jinja2 or whatever it is you really want.

Django, Rails, and Jinja2 have excellent documentation. I can't understand why you would think that PHP's documentation is significantly better.

You get what you pay for on super-cheap hosts who are somehow incompetent to understand Python or Ruby.

And choice is not a bug.

> Cut out the ones which are not actively developed and you only have a handful for each language.

"The template language you pick has a good chance of becoming an abandoned project" hardly seems a great selling point.

> You could walk outside now, and start yelling "I NEED A PHP PROGRAMMER!" and you'd probably find someone pretty quickly.

This is something that I point out as a negative. Yes, you can get a PHP programmer just about anywhere. But being that there are so many, it's harder to find those few truly talented programmers.

My own complaint about this is that if you bring in cheap PHP programmers, you end up with cheaply-written PHP. And the result is inevitably an unmaintainable mess. If you want well-written, maintainable code, you have to be willing to hire talented and experienced programmers. And in doing so, you give up that so vaunted "advantage" of PHP's mindshare.

Moreover, it seems to me that the truly talented programmers that would produce good software have a tendency to distance themselves from PHP.

So it seems to me: Choose PHP for cheap, quick projects on a budget for which quality is irrelevant; or choose a "harder" language for solid applications that will stand the test of customer interaction.

Yeah. That's why they completety rewritten it...

You literally just repeated all of the things that I just got done addressing. You also continue to ignore that I said NOTHING about PHP not being usable for "real sites".

I also, still, don't get your point. There are other templating languages for PHP too.

Again, your deployment argument is just as silly as your availability argument. It's trivial to deploy to Azure (sites) or Heroku, or Ironio or gondor, or any Go project, or etc, etc.

>There are millions of hosts to choose from at tiny prices, who can provide support because they know the platform.

Are you even reading what I write? Please show me a real webapp with actual users hosted on el cheapo shared hosting.

To put my comments in another light, let me postulate this. If I started a project in python, Go, ruby, C# or even something that ran on the JVM, I could give reasons for why I would choose it for something non-trivial. Outside of "I can hire cheap devs" and "I can run it on el-cheapo hosting", I can't think of a good reason to specifically pick PHP.

Reducing the cost of your project is a pretty good reason to choose something. Which template language would you choose for those other platforms? One of 200 half-baked templating languages, or something more complete like php?

PHP has better documentation than all of those platforms, so that could be another reason. It has more advanced, popular, and featureful Content Management Systems than all of those platforms.

> "Half baked"

Meh. jinja.pocoo.org

> "better documentation"

By what measure? docs.python.org is just as good (if not better.)

Python docs are way better on a technical level IMO (more detailed, more accurate - if you want to know what a function does in PHP you need to spend hours reading through the massive comment threads to find the corrections, and then ignore the comments from years ago since the API changed and the comments didn't, etc etc); but much like the rest of PHP, the PHP docs are incredibly convenient - php.net/function_name will go direct to the docs for that function if it's unique, or search for function_name in all libraries if not.

This is really useful when your standard library is an incredible cockup of str_pos vs strpos vs string_pos vs sposition vs StrLib::Position vs ($haystack, $needle) vs ($needle, $haystack) - it means you only need to spend a few seconds double-checking the docs every time you use a standard library function.

Sure, a library which was consistent and thus needed no lookups at all would be better, but if you abandon all hope of making sense of it and understand that you'll need to use the documentation several times per line of code, the convenience of the docs makes it not quite so painful.

No serious PHP developer actually go to php.net to read the documentation, literally all of the big PHP editors/IDEs come with an embedded manual so when you write strpos( it automatically tells you the order of variables.

If I really had to go to php.net to look up order of variables or even a function name then I wouldn't be programming in PHP at all, would take too long. Thankfully, since I'm not restricted to notepad I don't have to worry about this aspect.

You're basically saying that no serious PHP developers are using, say, VIM or Sublime Text, which is not true. I still hit php.net from time to time.

Yeah, this is me too. I haven't done much PHP in the past year, but when I did, PHP.net was ALWAYS open in a tab or two. There was NO WAY you were gonna get me to use some bloated nasty Java based editor just to have code completion. Honestly though, Stackoverflow is my goto point if I want the better parts of php documentation comments. An answer with 7 or more votes is worth taking a look at.

Then you are needlessly torturing yourself, if that's your thing then go ahead, but yeah I'm being blunt and calling that stupid.

Sorry have to quibble on that last sentence. I'm transitioning from PHP to Python at the moment and I constantly keep thinking "jesus, I wish docs.python.org was as good as php.net".

In what sense? I feel it's better than PHP's docs (tutorial, index, module list, everything.) Besides, you rarely ever need to look at the docs. `help(...)` works well enough 99% of the time.

Method and module names are clear and easy to guess. If I remember PHP well enough, it was a sorry_mess_of_underscored_function_names (with no namespaces) and had $funky $dollar $signs before variables. Some of the functions worked one way, some of them worked in another way (I mean that similar functions didn't work the same way.) Don't get me started on the type coercion system and the equality operators (among other things.)

EDIT: Quite a few people have mentioned that it's easy to deploy PHP software and while that might be true, (as I remember it from when I used to develop in PHP) it's much harder to set up a PHP environment than a Python one. Some of PHP.ini's defaults are (were) horribly broken, Apache has (had) problems finding PHP, etc. In contrast, setting up a Python/WSGI environment is like a breeze.

It's better than PHP docs simply by virtue of being versioned and annotated with version information.

This link was right on the Python docs homepage.[0]

[0]: http://www.python.org/doc/versions/

I miss the user contributed notes. I miss the way you can drill down on the left hand side of the screen. I miss the multitude of quick examples embedded alongside the documentation (py docs has some but not nearly as many). I find the descriptive language used more approachable and easier to understand. I also prefer the general look and feel.

To answer your second point about deployment: regarding your ini file, you set this up once how you want it to be and then use that across all your projects. Not very hard. As for apache, I don't know what you were doing but in my experience it's almost impossible for apache not to find php. I've just setup uWSGI (plus emperor) + mongrel2 + Flask (in a virtualenv) and that is 100 time harder to get going than apache and mod_fcgid (IMHO).

Shorten that. "I can hire devs". If you're just a small shop hiring a rails dev, let alone a Go dev, might be effectively impossible. Which is a very big deal for a company that relies on external contractors for a lot of their development, which is a fairly substantial group of small companies.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact