LOL at adding PHP support to app engine almost 5 years later. PHP gets a lot of bashing but you can't deny its popularity, as evidenced by the number of stars.
https://code.google.com/p/googleappengine/issues/detail?id=1...
https://code.google.com/p/googleappengine/issues/detail?id=1...
Many hosting providers only support it because it's popular.
At no point in this equation does the relative merits of the language itself factor in.
When using PHP, a lot of the basic data structure transforms are implemented in the core language. You can integrate simple server side functionality into a static HTML page in just a few minutes, and it will work on 99%+ of hosting providers, and requires no fees and no tools.
For pedantic hackers like us, sure, it's garbage, but for the average person that just wants to get things done, it is pure gold.
Also, WordPress, while the biggest POS in almost every possible way, has a vast community of users, designers, plugin makers, and a marketplace for various extensions and themes.
Google just opened up a huge chunk of the web app / CMS market.
I disagree. The developers of Wordpress are not "the average person". There are too many production sites that run on PHP to say it's garbage.
I mean nobody in the almost literal sense. Stack Overflow serves as a rough barometer of popularity and either Symfony users have no questions, use another support platform, or they don't make up a significant population.
The #1 problem with the PHP community is it's complete anarchy and filled with people that should not be developing web apps, or at least should not be developing the way they're going about it.
Maybe Symfony could fix that, but there's a lot of work to be done here.
I am specifically talking about Symfony2, by the way.
A great number of frameworks and CMSs are using Symfony2 components. Two popular ones are the http-kernel and http-foundation components.
Drupal is integrating several Symfony2 components.
Composer, the PHP package manager that has taken the community by storm, is using Symfony components.
eZ publish is integrating several Symfony2 components.
Joomla! adopted YAML, using a Symfony2 component.
Stating that Symfony2 is not widely used simply tells me you're not keeping up with the PHP community - which would be fine if you're not a PHP developer, but makes your statement not trustworthy.
edit: PHPUnit, the defacto standard PHP unit testing framework, also uses Symfony2's YAML component.
I can go on.
Nobody uses Drupal, or eZ Publish or Joomla. They just don't. There's good reasons for this, notably these are some really obnoxious platforms to build for, but that aside their impact on the PHP world at large is inconsequential.
PHP, by and large, consists of people slamming together applications from the ground up the same way they built them in the 1990s. It shouldn't be this way, and people should fix it through education and outreach, but I really don't see that happening on the scale that's required.
Also, if you think even a quarter of the PHP devs out there even know what a unit testing framework is, you're more of an optimist than I am.
You could probably build a competing CMS in, say Laravel 4, replace the plugin system with Composer packages or something similar, use Twig and PDO out of the box, and have a much more elegant and modern system that probably almost no one would use, unless the user experience was just as brainless as it is with Wordpress.
Which is also one reason why, I think, despite all the arguments in their favor, static site generators (which do get mentioned now and then as an alternative to WP) still have a while to go before they're ready for mainstream use. It's not enough that it's well coded, it has to be easy too, and easy wins out over pretty every time.
WordPress is being pushed only because the majority of web developers can tinker with PHP only.
I think you're forgetting that most of the people who use Wordpress aren't web developers at all, and most of the 'web developers' who use Wordpress probably can't code much, either, because they won't need to. The ease of the Wordpress install is something they advertise. Once you ever have to touch the code, yes, it's a nightmare, even if you're inured to the horrors of php code. Most 'web development' jobs with Wordpress involve the install, setting up themes, maybe editing the css and installing plugins (because even that is still more arcane than some non-technical bloggers and people want to deal with.)
The "low bar for entry" for PHP comes up as an epithet now and again, but if you're trying to increase the adoption of your particular language, having an application the plebs can run isn't necessarily a bad thing. Does anything similar exist in the Python or Ruby worlds yet, for which someone wouldn't be expected to know how to use a terminal, or handle git?
It is, I think, almost entirely down to being less of a hassle than anything else out there, and especially less of a hassle than anything not written in PHP. Call it laziness if you will, and I wouldn't entirely disagree with you.
PHP is like Perl blended with C and a whole lot of confusion.
Frameworks have made it "better" like ketchup improves the quality of prison food, but it's still terrible on the whole.
No, it does mean it's good. You're comparing opinion (everybody has one) with actual hard real world results (tons of major sites with million hits running on Wordpress and around 15% of the web too).
Inertia is powerful.
Though, to be honest, I don't think that using Play (today) or Rails/Django (yesterday) is sufficiently less productive to merit the technical debt you almost certainly will incur starting with a PHP stack. (And I am an ex-PHP person, to the point of hacking around in PHP core...that's a few months I'd love to have back.)
Facebook's former CTO has said that the only reason Facebook is still on PHP still today is legacy. It wouldn't be written in PHP if it were started today.
PHP once was the right tool for the job, but those years have passed. We have many better options now.
A sane engineer considers the full pictures before picking a solution rather than pick their pet languages just because it's nice and clean.
Wikipedia's Mediawiki software is awful, and serves as a great example of how not to build an application. It makes WordPress look like a precision engineered Swiss watch.
Yahoo uses PHP because, like Facebook, they could make FORTRAN work in production if they wanted to.
A sane engineer don't pick technology based on what is most theoretically pure, but based on what can deliver on the requirements on time and on budget.
If you are building a simple CRUD style application, for example, there's likely nothing in your technical requirements that precludes PHP in any way. Then the question turns to ease of deployment and maintenance, operational costs, cost and availability of developer time, and there PHP tends to score quite well, not least because there's a huge pool of relatively skilled engineers that know it.
I personally prefer Ruby and don't like writing PHP at all, but I'd be a horrible engineer if I wrote it off in situations, where, e.g., it is hard to hire Ruby developers at a reasonable price, or there's a lot of existing PHP knowledge within a team that is already in place.
If you can find RoR developers, they are not cheap. If you're building a v1 product on a limited budget, and don't want to spend 80 hours per week writing it yourself, PHP is an excellent choice.
Having to read the code with a clothespin on your nose is a small price to pay.
Are there automated deployment tools written in PHP for PHP applications? I mean ones that can be taken seriously.
What optimization options do you have for PHP? What latitude do you have with hosting? If you're not Facebook, writing your own PHP engine, you're going to be stuck with one of a few that are generally crappy.
Cost and developer time are non-factors since the time you'd need to learn PHP is probably higher than other languages that make more sense and aren't filled with anachronisms you will spend half your time working around.
You can train someone up in Ruby on Rails in two weeks. Django or Node would take about double that time, but only because the platforms aren't by default as feature complete and the tooling will vary from project to project.
"Cost and developer time are non-factors"
Bro, do you even startup?
His point was that learning PHP properly with all the shenanigans takes at least as much as time as learning a well thought out environment.
It's not snobbery. It's called doing your job like a professional. This is harder in PHP than it is in other languages.
The only language more cantankerous and difficult than PHP is C. Learning PHP properly is hard. There are hundreds of little things you will have to be very careful about because they are easy to get wrong and the cost of failure can be enormous.
If you can't see this, you're basically a PHP snob. You're holding your pet language to a different standard than others.
I detest PHP from a language writers standpoint. Programming language design is a hobby of mine, and I am a real snob about programming languages from a personal preference point of view, and PHP certainly does not measure up.
But I don't let my pet ideas about what a programming language should be like stop me from doing my job, which is to ensure we have an environment and team where we can get projects in on time and on budget with a staff that is both skilled enough and cost effective enough to keep us profitable. Is it possible to do this with Ruby? Sure. But the dynamics are very different, and the potential customers tend to be quite different.
I've written web services in a number of languages, including C and C++, and been responsible for systems in a mix of PHP and Perl that handled ~$50 million worth of card payments and invoicing, and I've developed Ruby based systems and hybrid PHP - Ruby - C++ stacks. When I can justify picking Ruby, I do, because I love the language. But I refuse to pick Ruby just because I personally like it and it has a higher coolness factor in the face of economics where it doesn't make sense, such as when there's installed bases or teams that are already skilled at PHP. It'd be irresponsible.
You don't have to use those things, but they are there if you want them, just like they are in other languages. Neither Python nor Ruby enforce unit test or parameterized SQL requirements.
I don't like the language itself, but I do like the myriad benefits it brings. The only pet language I hold to a different standard is Perl.
I agree that if you already know another platform there's no reason to switch to PHP, but similarly i've not seen much reason to switch away from PHP, aside from personal preference in language syntax.
Contentious. The VM itself is, but there are many functions implemented in C. Whether it'll be fast or slow for your application is not necessarily immediately obvious.
If you think that, you don't have much real world experience.
> Are there automated deployment tools written in PHP for PHP applications? I mean ones that can be taken seriously.
Why do you need a deployment tool written in PHP for PHP applications? Are you serious? It's a ridiculous proposition to care that much about the language the deployment system is written in. What I care about is what benefits it brings me.
Where I am now we have our own deployment system, btw. - we operate a private multi-tenant cloud specifically tuned to the type of workloads our customers have, at a cost ~1/3 of what it'd cost us to host our current infrastructure somewhere like EC2 with equivalent redundancy and performance. That is including the development and maintenance costs for our in-house tools. As part of that we have a rapidly improving set of deployment tools. Handling deployment of PHP was pretty much the simplest part of that system.
> What optimization options do you have for PHP? What latitude do you have with hosting?
Are you for real? I love Ruby. I'm working on a Ruby compiler as a hobby. But scaling PHP is trivial compared to RoR. I don't need optimization options for PHP - one of our clients processes restaurant bookings worth 50 million pounds a year via a setup that consumes ~30% of CPU resources on two frontend servers with a combined leasing cost of ~1000 GBP/year. The vast majority of their cost (their total yearly cost for their internet presence is about 3 orders of magnitude above the cost of the servers hosting the PHP code) for this system is marketing, support, power and bandwidth in that order. Cost of the frontends that PHP run on comes at the very bottom - it's a rounding error. If we needed more frontend capacity? We'd add another couple servers like that, and it's still be <1% of their cost.
What costs us money on the hardware side is database servers and network infrastructure. Web frontends for typical simple web apps are cheap. Sure, there are exceptions (but as much as I love Ruby, RoR is certainly not going to save you scalability grief in the cases where scaling PHP becomes hard or costly).
> If you're not Facebook, writing your own PHP engine, you're going to be stuck with one of a few that are generally crappy.
If you're not Facebook, there's no compelling reason to write your PHP engine as PHP is fast enough for pretty much anything you throw at it until you're in a situation where you have thousands of servers, where shaving a few percent off here and there starts creating large savings.
A vanishingly small number of companies ever reach that scale - optimising for that in advance is lunacy, and most "cleaner" languages does not provide a better starting point in that respect. Ruby, for example, is far more costly to scale.
> Cost and developer time are non-factors since the time you'd need to learn PHP is probably higher than other languages that make more sense and aren't filled with anachronisms you will spend half your time working around.
Spoken as someone who doesn't know the market. I have a steady supply of qualified PHP staff. In fact, we have recruiters hounding us every day with cheap candidates that know PHP. Ruby? Rarely, if ever. Those who know Ruby well enough have an easy time finding better paid jobs.
> You can train someone up in Ruby on Rails in two weeks
Bullshit. You can get a senior developers that is already expensive to relative beginner level in that amount of time. Or you can hire a PHP developer that is already skilled at ~60% of the cost.
I've seen "RoR developers" with two weeks experience, and what they produce is not pretty, and certainly does not result in a good ROI compared to more pragmatic solutions. I'm all for using Ruby if/when you have a good team of Ruby developers, but you then also need to realize that you have an expensive team. It makes sense when your team is highly experienced and rapid turnaround is more important than keeping the cost down, or if your personal satisfaction is more important to you than the cost - both can be perfectly valid reasons. If I were to start a new company now, I'd pick Ruby myself. But I would do it because it is what I would prefer to work with, not out of any illusion it's currently a cheap choice.
Yes PHP has a lot of bad parts. But its good parts are really really good.
Most hosting providers dont allow serious php development anyway , so it makes little difference. You need a vps or a PAAS to do serious PHP development , like any other solution out there.
I love python and ruby. But I really miss type hinting everytime i use one of these.
... except for "easy to deploy", which is a merit.
* Cheap to deploy
* Easy to find programmers to help you
* Affordable programmers
* Code is easy to read for non-programmers who understand HTML
* Ton of free code available to reuse
Inconsistency, poorly thought out OO, lack of purity, and disdain by hipsters are a small price to pay for those merits.
"Hating PHP? That's so mainstream. Personally, I'm hating on Haskell and NodeJS."
So I would say you should learn something in addition to PHP so that you bring more value where you go.
Put another way: don't be a PHP programmer. Be a programmer. Then, use the right tool for the job based on the constraints given to you. If that ends up being PHP, you'll still be paid more to do it.
Secondly, the reason some programmers are more expensive than others is because they're more efficient.
Who would you rather have? Six PHP programmers that flail away for a month and ship a buggy but usable application? Or maybe two Ruby or Python developers that ship a unit-tested, well engineered application?
The two developers will cost you about the same as the six others if they're top-notch, but they will not make the same mistakes and they will not stumble into every potential pitfall along the way to the solution.
Wielding a master's sword does not a swordmaster make. Surely you've seen enough RoR and Django projects to know that.
Some people will say that something not written in a strongly typed language is not well engineered. If it's not compiled, it's not efficient. This is just programming snobbery. For what it's worth, I was that kid in high school, except back then it was Perl. That's how I learned. Something that makes it even easier? That just creates more programmers. Without shitty programmers, we'd be paid a lot less.
I talk a lot of smack about PHP and JavaScript, but these terrible languages have brought more people to programming than any other languages.
Remember, both PHP and JavaScript were serious tar-pits ten years ago.
JavaScript has made enormous strides in that time, the cultural shift is unbelievable. People went from writing absolutely terrible client-side code, to using frameworks (Moo, Scriptaculous at first, later jQuery, RequireJS) to using it server-side for serious applications. It's gone from complete anarchy to highly civilized. There's some things JavaScript does very well now, and in an elegant way mostly free of quirky tradition and/or obnoxious anachronisms.
Meanwhile PHP has only degraded. It's improved, technically, but the community is now hyper-fragmented. Best practices are routinely ignored. Frameworks don't inter-operate even on the most basic level. There's no leadership. There's opposition to even the most obvious improvements to PHP, like deprecating components that are doing nothing but holding PHP back. Killing off `mysql_query`, for example, is absolutely imperative, but it's going to be a bitter fight.
braces for downvotes (I did try to be fairly balanced, to be fair)
[1]: the wisdom of doing this left to the reader.
Thought: ah, my sibling commenter managed to put it better than me (and less controversially).
They're both awful languages that are popular because amauteur programmers can easily get started and churn apps. There is just as much, if not more, horribly written spaghetti JavaScript out there, even by Rails and Python developers, as there is horrible PHP code.
The only reason people don't belittle JavaScript (as much) is because there are no other options. If there were, I think JavaScript would easily be the next PHP (and for good reason).
I think once people know how to use JavaScript appropriately and uses it's strengths then it's a much better language. Back in the day I found JavaScript weird and messy but that was partly how I used it. The prototype pattern is extremely powerful and JavaScript is a multi-paradigm language, which is great. OOP or Functional, it's your choice.
With the rise of really good front-end frameworks (they're getting better), the quality of JavaScript applications is getting better and better and Node.js has also done a really good job at boosting JavaScripts rep.
I do think the standards body is greatly flawed and all the different browser implementations are increasingly frustrating. The ability to use new features is extremely little, unless you use JavaScript as an embedded language in another application (i.e HTML5 App in a native context).
I don't think JavaScript will be the next PHP.
JavaScript isn't a great language, but it's OK. Maybe "awful", but lots of languages are.
PHP, on the other hand, is in a class of its own, far worse than JavaScript or any other mainstream language I've experienced.
For example, javascript at its core has a string type that is treated like an array of characters in proper unicode, with a sane extensible method-based string api. PHP at its core by contrast only knows byte arrays and its string handling (global!) functions are basically useless for dealing with unicode (there's mbstring and intl, but too many people don't use those).
Wikipedia, Facebook, MailChimp, WordPress, tons more -- they all load fast and are hardly ever down.
You can argue all day about the fine details of programming languages, but PHP is popular for good reasons.