PHP is much better than what you think
fabien.potencier.org
fabien.potencier.org
So while not a tightly coupled part of Symfony they are related through developers, community, and funding
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.
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.
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!
Servergrove.com has the best options for symfony sites IMHO
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.
[1] http://book.cakephp.org/2.0/en/appendices/2-0-migration-guid...
[2] http://bakery.cakephp.org/articles/lorenzo/2012/07/01/cakeph...
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.
I am interested in hearing skrebbel's response to this question however (what makes cake so horrible).
Perhaps I just misunderstood. To me it seems sold as the successor to Cake. http://www.meetup.com/lithium/
False. Last commit was 18 hours ago.
Additionally, I know of no framework that reinvented more wheels than CakePHP.
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.
And that's exactly why PHP is the better choice for those of us who distribute software to non-technical users.
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.
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...
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?
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.
Well, sure, I guess if you're really strange, you can be as efficient with Brainfuck as you can be with Python.
Disclaimer: never touch the stuff myself.
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);
});
});
}Anyway, that's a joke implementation of the Y combinator[1] in PHP.
[1] http://en.wikipedia.org/wiki/Fixed-point_combinator#Y_combin...
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.
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.
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.
I didn't state it was better then any other language. I simply made a case that it is a good language.
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.
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'.
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?
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.
And what about cross dowels! Don't get me started!
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.
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.
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.
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.)
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?
sudo yum install apache php mysql
done.
And anyway, for a serious project you need a local dev environment that somewhat mirrors live, and then staging (which exactly mirrors live).
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.
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.
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.
Plus of course Heroku has simplified it down to git push so setup times are a bit of a given now.
- 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
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.
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.
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.
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?
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.
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.
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.
I would have more sympathy if it were clearly evident that serious bugs were taken seriously rather than being ignored for a decade
You can't be satisfied
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.
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.
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.
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 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.
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!
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.
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.
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.
* 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.
You can.
http://getcomposer.org/doc/00-intro.md#globally
$ curl -s http://getcomposer.org/installer | php
$ sudo mv composer.phar /usr/local/bin/composer
$ composer --version
Composer version 6573fd3How can I install bundler on a shared hosting environment like composer?
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.
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.
"gem install --user-install bundler".
http://getcomposer.org/doc/05-repositories.md
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.
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.
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.
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".
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.
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.
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 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.
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.
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?
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.
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.
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.
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
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.
They're almost completely different language, and while PHP 5.3 certainly has warts it's vastly better than PHP 5.0.
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.
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.
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...
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 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.
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.
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.
- 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 use PHP and Python(Django) - work and play.
Alot of those nice framework features rely on higher level language features that are missing from or atrocious to use in PHP.
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.
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.
That's why the LedgerSMB project uses Template Toolkit with <?lsmb ?> tags (that and [% %] causes problems in LaTeX).
<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.
<?printstuff
'<html> <body> <p>fun stuff here</p> </body> </html>'
?>
That's still an SGML document.
<?php
# 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.
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.
I'm talking about the CLI SAPI, NOT the Apache SAPI.
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.
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".
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.
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.
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.
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 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?
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.
I really hope you're using a framework, because that above sentence is a recipe for disaster.
"I take care of my kids! I ain't never been to jail!"
/PHP developer for 6 years
* 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.
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.
However, this is just stockholm syndrome, plain and simple. Fabien is the author of Symfony.
1. http://en.wikipedia.org/?=PHPE9568F36-D428-11d2-A769-00AA001...
> 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.
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.
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?
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 :-(
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
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...)
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.
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.
There is another reason, which is that some of PHP's design choices seem easy but make things harder down the line.
Move along :)
> 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.
ps. I don't mean crontab
ps. I don't mean sewing shirts.
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?
Here is a list of template languages people on 'real' platforms use:
Python.
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,
Ruby.
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,
Java.
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.
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?
None use PHP.
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."
Or they got tired of being bullied by people like you.
> Or they got tired of being bullied by people like you.
Or they really aren't a fan of PHP?
http://www.quora.com/Quora-Infrastructure/Why-did-Quora-choo...
Be comfortable with the language you prefer and quit whining about the rest!!!
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!
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.
"The template language you pick has a good chance of becoming an abandoned project" hardly seems a great selling point.
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.
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.
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.
Talking about what languages programmers find enjoyable and productive is perhaps more meaningful. This is where Python and Ruby shine, and PHP falters.
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.
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.
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.
Since most benchmarks are unscientific, this one is as good as any. So here goes:
http://shootout.alioth.debian.org/u64q/benchmark.php?test=al...
Since benchmarks are completely worthless, let's just stop this pissing match right now.
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.
http://docs.python.org/release/3.0.1/whatsnew/3.0.html#perfo...
> 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
else:
return fib(n-1) + fib(n-2)
for i in range(36):
print "n=%d => %d" % (i, fib(i))'
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)}"
endI 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.
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.
Huh? Since 21 Apr 2012, the benchmarks game has shown - ruby 1.9.3p194 (2012-04-20 revision 35410).
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.
>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
It's a dirty job but it still has to be done ;-)
Let them reply and then answer them.
When the comparison would be better without that complication, look at single core measurements -- http://shootout.alioth.debian.org/u64/benchmark.php?test=all...
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!
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.
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.
Meh. jinja.pocoo.org
> "better documentation"
By what measure? docs.python.org is just as good (if not better.)
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.
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).
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.
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.
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.
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.
http://www.welton.it/articles/programming_language_economics (sorry to those who have read it, but it bears repeating)
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.
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.
Why did they choose to do this in PHP instead of a more respected language? They already had a bunch of PHP developers.
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.
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.
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.
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.
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.
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."
(╯°□°)╯┻━┻
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).
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%.
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.
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...
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.
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.
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.
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?
>PHP's most ardent critics have little hands-on experience with PHP, itself
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.
Why am I meant to use PHP again?
Oh yeah, because you haven't discovered Ruby yet.
And really? Can't do CSV import? What does that even mean?
I mean, it's a programming language. There are packages you can get that will do those things, and if there aren't, you program them.
I'll give you the point on the syntax.
If PHP wouldn't be such a wide-spread problem, people wouldn't have to spend so much time fighting against it.
One positive thing: His post was didn't kill my spell checker, that's an impressive achievement for a PHP developer. You don't see coherent sentences that often from those people.
Although I suppose, strictly speaking, JavaScript has the same thing. (not intentionally, but you can make an array that is both if you really want to)
For example, Lua uses a similar approach ("tables") and works just fine. AFAIK, it does certain optimizations under the hood to make sure numerically indexed tables behave efficiently (like arrays). Maybe PHP does the same thing, but its terminology is confusing.
P.S.: I dream of a future where Lua is the primary tool for web development. It's perfect for that purpose as a language, but unfortunately, lacks the necessary ecosystem :(
Java has keySet(), Ruby has hash.keys, etc.
Your second argument is even dumber. Yes, PHP lets you do lots of things, which improve the speed of development. If you don't like it, don't write it that way.
I don't think he was arguing about the utility. I think he meant that: array_keys($aHash); is less desirable than: aHash.keys. Also, if you you really look at the PHP example, the semantics really suck.