Contrast this with RoR/Django/nodejs/etc. Here you have to be the one controlling the process/thread. You can mess up and create a dirty execution environment. In your requests you have to be aware of what the other requests might be doing at the same time. Moreover, running two simultaneous applications requires two different execution environments (apache processes, nodejs processes, etc.) The common solution to this is to either provide some environment isolation by running one set of interpreters per application or to have a whole virtual server dedicated to every application, incurring the overhead of an OS per app.
Don't get me wrong, I detest writing code in PHP for many reasons, but the execution model is efficient: if you want more power for your applications, just increase the number of available interpreters. Moreover, every interpreter is the same, so by doubling your total number of available interpreters, you double the concurrency of all of your applications. This is the pinnacle of cloud apps: you have a simple single toggle that controls how many requests you can process concurrently. This is why shared hosting now costs $2/month while Heroku is an order of magnitude more expensive.
Then don't mess up. It's not that hard. If you follow best practices (don't use global variables) you should handle this fine. I haven't heard anyone having this problem in Rails at all.
> I detest writing code in PHP for many reasons, but the execution model is efficient
No it's not. You'll have to re-open connections to databases all the time. You can't use keep-alive to external HTTP APIs. You'll have to re-parse the PHP for every request.
(Added later: Yes, this isn't how PHP actually works, and that was kinda my point: parent's concept of "PHP execution model" isn't actually used in PHP because it's stupid! There will always be some things that you want to share (connection pooling, opcode cache) so even PHP isn't a "perfect" share-nothing architecture.)
It's perfectly possible to write a shared-nothing architecture without dumbing it down to CGI.
What? This is all factually incorrect.
1) PHP has supported persistent database connections for ages. The fact is, persistent DB connections aren't really that great for websites, where you need a few resources quickly and then nothing for a long time. Having 10,000 idle DB connections is a great way to eat up resources. But you can do it.
2) PHP can use cURL's multi-handles, providing a per-application keep-alive connection pool (e.g. see Guzzle: http://guzzlephp.org/tour/http.html#managed-persistent-http-...).
3) While not part of PHP itself, most serious PHP applications use something like APC, which caches PHP opcodes to prevent constant reparsing.
Which is why you should be using connection pooling. Which can not be done efficiently with PHP. Necessitating that people create an entire extra layer of database proxying software to do the pooling for you.
Sure, though how do you know all the library code you are using isn't going to mess things up for you? Granted, chances are small, but they are there.
> No it's not. You'll have to re-open connections to databases all the time. You can't use keep-alive to external HTTP APIs. You'll have to re-parse the PHP for every request.
Use a cache for your bytecode to not re-parse all the time. Use a special purpose TCP proxy to keep connections open if that is your bottleneck (in most web apps it's not). Also, certain DB drivers let you have persistent connections out of the box.
> It's perfectly possible to write a shared-nothing architecture without dumbing it down to CGI.
It hasn't been done yet for the price that PHP offers. It is very limited in some areas, but if you go with the grain, it is very cheap.
My main point is that two different applications cannot share an interpreter in RoR/Django/nodejs. This leads to overhead which is not there for PHP. Places like Heroku and Google App Engine try to be clever about this. You can technically shut down interpreters that aren't used frequently, and spin them back up when many requests come in, but guessing when to shut things down and spin them back up is tricky. This is why Google App Engine is so pricey: they suck at figuring this out. But even if you have a great way to figure it out, you are still going to have unpredictable performance, and the cost of waking up/spinning up an interpreter is fairly high.
> Also, certain DB drivers let you have persistent connections out of the box.
If you have connection pooling you have have a "dirty environment". PostgreSQL/MySQL makes it possible to set per-connection settings so you have no guarantee that the SQL executes in a clean environment. You might say that "oh, but the library handles the resetting for me", but how do you know all the library code you are using isn't going to mess things up for you?
In short, unless your database has a way of saying "reset all settings", you cannot have persistent connections in any environment.
WSGIDaemonProcess myapp processes=5 threads=5 display-name=myapp-name user=myappuser
WSGIScriptAlias / /var/www/vhosts/example.com/apache/myapp.wsgi
Edit: obviously, don't use this config example.
Note that in environments where this sort of thing is trivial to do (java for example), virtually nobody does it, preferring to run separate servers per application anyways.
Now I've got a tiny (280mb deployable, 5 hosts, 37 application pools, 5000 in flight requests 24/7) behemoth on my hands and I can testify its an arse pain to manage resources.
It is somewhat expensive to startup a new interpreter process per http connection. This can be alleviated by using FastCGI, but then the interpreters are long lived and are no longer completely independent.
It is quite the opposite. It is incredibly inefficient, running hundreds of copies of the exact same code, building up an entire framework of objects to use for a single request, then trashing them all to do it again from scratch on the next request. It is easy for beginners, which is why it is so popular. But that is not the same as being efficient.
Or are you talking about parsing the code? At that point, something like APC would help immensely.
A common problem I see in these kinds of discussions is engineers. Yup, you and me. In my case it took me years to move away from being a typical clueless egocentric engineer. I am sure I still am to some extent. Whatever is left pales in comparison to my younger self.
What made the change? Business. And the realities of the insanely simple business equation coupled with actually launching and running them with my own money.
There's a huge difference between holding a cat by the tail and watching someone else do it from afar. Huge.
Where I am going with this is that we (engineers and technical folk) tend to focus on, and talk about, FEATURES almost at the expense of BENEFITS. The reality of business is that the value of the former pales in comparison with that of the latter.
I love Python. However, when faced with having to do a benefits analysis it is almost impossible to not choose PHP these days. Liking it has nothing to do with making the choice. Well, it shouldn't.
I wish engineers could see what they sound like from the vantage point of a business person. You see this all the time at pitch events. There's an absolutely abysmal difference between presentations from "virgin" engineers and those who have had even a few business scars.
I'm wondering if it is also influenced by long/short term view of the benefits. IMO PHP has extremely high short-term benefits, but many of those break down when taking a longer term view on development and maintenance (mainly because the benefits for one often end up being liabilities for the other).
If you have a team that already rocks on PHP, migrating people to Python is likely to be a problem.
Depending on where you are located, finding good Python programmers could be difficult (stats: over 10x more PHP programmers than Python.
If your project is pretty far along, translating to Python might carry with it a non-trivial cost.
In general terms I think it might be easier/cheaper to launch an MVP in PHP with a sensible framework (like Yii) and then migrate to Python + web2py or Django for the "real" product.
I prefer Python, but it is hard to ignore job market statistics when considering what it might take to put together a team.
I'll go out on a limb and piss off a bunch of people in the process. I'll venture the thought that most PHP-only programmers are really bad programmers. Someone not formally educated in CS or having no experience in a variety of languages (and paradigms) before adopting PHP will probably be "challenged" as a programmer in more than one way. I have a feeling that, because of the nature of the language, a larger percentage of Python programmers are really good "traditional" programmers with a good balance between theoretical and practical knowledge.
Let the flaming begin.
That being said, I have met (and work with) some "PHP first" programmers who are genuinely great programmers, and who get how to write clean, reusable code. "I learnt in PHP" isn't a blanket euphemism for "I'm a horrible programmer".
>In general terms I think it might be easier/cheaper to launch an MVP in PHP with a sensible framework (like Yii) and then migrate to Python + web2py or Django for the "real" product.
Why do you think that?
>I'll venture the thought that most PHP-only programmers are really bad programmers
Some projects "swing the PHP-way" and they are "retarded" but easy to use and fix and keep with the "fail fast, fail cheap" philosophy. Otoh, things like Drupal or Magento "swim against the tide", are hypocritically claiming to be newbie/weekend-warrior friendly, and basing your project on them lands you over-time and over-budget 90% of the time, ending up costing more than a custom made Rails app - unless you have the rare mystical creatures called "real Drupal (or Magento) gurus" working for you. It's a very weird jungle the PHP ecosystem nowadays, and lots of the creatures in it byte hard!. If you stick to riding a gentle sloth like WordPress, you're fine... but I'd suggest rapidly switching languages and technologies (something like Django + django-cms is almost as cheap and can be deployed even on dirt-cheap shared hosts) as soon as you grow over WordPress level, otherwise something will end up biting you hard!
Sure they have problems, but so does Rails, and Django.
Both of them have such powerful plugin/extension frameworks, that most of the effort in building drupal or wordpress sites is finding the right plugins, and skinning. Very little actual programming work is required to get an operation site running for a client in either framework, which makes them ideal for many of these low-yield "corner store" sites.
It's an inherent issue with frameworks not with any particular language IMHO.
Imagine if we took this attitude in civil engineering, or medical science. Not good. Obviously not every web project is as important as those two things, but "the barrier to entry for foot-shooting is low!" should never be a plus point for a technology. Especially when it's not your foot.
There's obviously a need for a tool for low(er) skilled people to make websites, but perhaps it should be less powerful to match? It should at least have abstractions that don't leak so much.
I'm happy to be lectured to about why this is wrong.
PHP generally allows developers to just get up and go, both in terms of installing it on a server and building an application, and requires minimal learning. Unfortunately that does mean you end up with a large number of substandard developers, but at least they're getting things done.
EDIT: it's also perfectly possible to clean PHP up using e.g. autoloaders and the builtin interfaces and spl classes, if you want to work cleanly - this capability seems wholly underused outside of frameworks and I hope it gains more attention soon.
You say "obviously not every web project is as important" as civil engineering, but I'd put it the other way "Almost every web project is not anywhere near as important" as civil engineering.
People build Ikea shelving units in their home all the time, without a civil engineer being involved.
Ikea shelves often break, and thus commonly need replacing every couple of years. This might end up with a higher total cost/kg/year for holding your stuff up in the air, compared to hand building your shelves out of oak or whatever.
Of course, many people move apartments each year anyway, and the old shelves will not fit in their new apartment. So it makes sense to use ikea shelves in this case. Unless of course, the handmade oak shelves were modular and could be easily reconfigured in a way that the pressed-fibre ikea shelves couldn't.
The real problem comes when your ikea shelves fall down, breaking all your stuff. In which case, you were an idiot for putting your important stuff on ikea shelves. In this scenario, you may wish to hunt down and disembowel the interior decorator who told you the ikea shelves would be fine.
So yeah, the right tool for the job. Who'd have thought it? ;)
Personally I won't be giving up my life as a designer of premium bespoke home storage solutions for a job on the checkout at ikea.
I think it may be more like communicating. In that sense, English is "better" than Esperanto, even though it's not as well thought out, simply because more people can use it at some level.
I'd argue while it's very easy to get started with PHP, it's very hard to build some of good quality with any significant functionality compared to say rails/ django (ignoring framework != language).
Not at all suggesting it's impossible to build good quality apps in PHP but that it's very easy to build bad ones so to build a good one, the programmer already has to be pretty good, making it a poor choice for low skilled people use imo.
The complaining that it's a poor tool while many people create tons of value with it leads me to believe there's a disconnect between the two camps that I don't get.
Because we inherit the horrible mess of shit PHP developers leave behind when the company finally releases they've painted themselves into a corner and can no longer move forward because every time they try to fix a bug in their software they add two more.
>Don't take jobs where it's the primary tool.
It is so widely used that even avoiding jobs where it is the primary tool, you will still almost certainly be stuck dealing with some PHP mess.
Oranges are a citrus fruit.
Does my argument strike you as being somewhat flawed? Making a true but irrelevant statement is not an argument. PHP is worse than other languages, not equal to them. You create more debt, and it is harder to fix. That is why experienced developers spend the time explaining to beginners that PHP is bad, rather than just ignoring PHP as the original poster wondered.
But what makes it "bad"? Everyone says it, but I don't think I've seen any solid arguments behind it. If it's just because you get a lot of less experienced developers using it (for the reasons mentioned in the article), then I fail to see how that is a flaw at all. If you're 12 years old and trying to get started with web development, then you're probably going to use Apache and PHP to do your first "Hello world".
In the grand scheme of things, there are very few websites that actually require a more robust back-end than PHP. Unless you're pulling in millions of hits, you don't have to worry about the inefficiencies of the language.
You haven't looked very hard then:
That's why I never put too much stock into python arguments that feature syntax readability prominently. Unfortunately, being a perl guy I've heard quite a lot of those. There are plenty of other language features that could be used to make a point that have less well understood solutions (for perl, those are Perl::Tidy and Perl::Critic).
Python, maybe, but even that's trivial to get going. Most of these - save Go - are installed on shared servers anyway.
What this sounds like to me is "I'm most comfortable with PHP, thus it's faster (read: cheaper) for me to create freelance projects in it."
Which might be true; there is a cost associated with learning and thus becoming comfortable in another language. But that's a very different argument than you're making here, Sam.
If someone asked a freelance programmer to make X and you can make it in PHP, Python or Ruby ... the actual cost of development should be relatively even. What you're factoring in is an inherent time cost for your lack of comfort in the other languages.
With Python, you need to create a service to run your WSGI server and proxy it from your web server. You also need to handle your static files properly. PHP, you just copy everything in there.
Hell, I have half a mind to create a project that will run Python scripts CGI/PHP style (run this file and send whatever it returns), just to make deployment easier for people. I'm not convinced the convenience is worth the cost of this horrible dirtiness, though.
So you have some PHP app that works fine locally but fails in weird ways on deployment because the server was configured using cPanel by someone who didn't know what they were doing and if you change settings you risk breaking whatever other random php scripts are running on the server.
So you end up hacking around with .htaccess files to get things working.
With Django etc you get a to have a "clean room" and run in relative isolation, only interacting with the outside world via proxies.
What PHP is however is cheap to deploy. It's annoying to have to think about and pay for "instances" , "dynos" , "VPS" etc when you just want to put up a webpage with a bit of server side logic.
I don't see how this is true anymore. Setting up LAMP versus setting up LAMPython or Node are all one line of aptitude/(your package manager here). I can have a LAMP stack spitting out "hello world" in the same time it takes me to get a Node app running.
I'm quite comfortable deploying python projects, and I've done it for a number of clients, but the problems I'm faced with are:
- Sometimes the client comes with hosting for a previous site, and insist that it has to be hosted in the same location
- There isn't much in the way of reliable, cheap hosting where the client will get support for anything other than PHP.
- I am not going to manage a client's server for them. They do not pay me enough to justify waking up in the middle of the night to restart a linode that crashed. I am not in the hosting business (I used to be), and I like it this way.
I will often try to push the client towards managed business hosting, where there's a bit more freedom to move, but even then, it's an uphill battle. PHP is a (the) reality of my line of work.
Honestly, shared hosting rarely even handles PHP - I don't know many hosting places that will support the code you write. I can't see going to your host and complaining that your site is down because you wrote a script with an infinite loop that's eating up Apache.
Dreamhost, as an example (seeing as I use them), just upgraded all of their servers to support PHP 5.4, which is much better than any of the other hosts I've found. They're cheap, give relatively good support, and have recent versions of PHP available. If there's a problem with PHP or apache, that isn't broken application code, they'll fix it.
With python or ruby, you're on your own.
Which is no different than with Dreamhost in this scenario. If, for example, PHP 5.X or 6.X ends up breaking your code, it's not like Dreamhost is going to debug it.
There's no functional difference here between PHP and any other language except that the hosting provider will automatically update PHP. And there's no guarantee that won't bork something else (which they will also not support).
But even so, if I build some PHP code that isn't future-proof for even the warranty period that I offer on any code, then I've got to fix it at my cost. If I build some code that, in 3 years time becomes incompatible with a new version of PHP, then it can be fixed then. I can't be expected to predict the future of PHP and build forever-proof code, though.
> just upgraded all of their servers to support PHP 5.4...
So what you say is true: they won't support code, but they'll restart the server and handle core updates. That isn't a big enough benefit for someone who detests a language that much.
I still think you're more comfortable with PHP than anything, which is how your valuation is being assembled.
Really? Rolls eyes.
PHP deployment = copy the files to the shared hosting area. Done.
Go even needs building a binary for god's sake!
And people paid Katz nice money to make RoR more easily installable.
PHP deployment = copy the files to the shared hosting center. Done.
Node deployment = copy the files to the shared hosting center. Done.
What's missing is the setup. Most shared hosting centers just preinstall a LAMP stack and call it a day.
In PHP you only have to do the copy part. The setup is done for you.
>Most shared hosting centers just preinstall a LAMP stack and call it a day.
Which is our point exactly. If and when "most shared hosting centers" also do the same for Node, RoR etc, then we can talk again.
Until them, PHP is vastly easier to deploy for most people.
Obtuse on purpose? For one, what npm install? On most shared hosting services there is no Node environment at all. Heck, in most of them you cannot even install one IF you want it. We're not talking VPS here.
If you read the article, our topic is where the vast masses get to deploy: in shared hosting services. No VPSs, no AWS, no Heroku, no nothing.
If you're building a website (in any language) without a framework, you're doing it wrong...
And your last statement is terribly ignorant. There's tons of web sites and apps that are better off built without a framework.
At least I home I am free to use whatever I want. So I use Symphony2 ;) ... which adds verbosity and complexity to a language that still can't decide if 0 is something empty or just the number 0.
If someone asks for product X without a language specification, you're probably free to create it in any language you're comfortable (although admittedly it would be stupid for a client to allow this).
PHP is not faster to write, debug and deploy than most other languages. It is faster to write, debug and deploy if you know PHP well and language X not as well.
Whether they will end up succeeding is yet to be seen, but this does definitely seem like an area where competition will benefit the greater good, as displacing PHP with any one of the better designed languages out there would benefit the internet as a whole.
I do wonder though: is the procedural nature of PHP equally responsible for it's adoption by inexperienced developers?
Sure, PHP is cheap and widely available, but you also don't need to understand the concepts behind object orientation to hack together a "dynamic" website with a few includes. And at that point you're just familiar enough with PHP to favor it for future development.
I'd like to believe maybe one day someone will commit the 6 months to make such a thing happen. But I really doubt it.
With PHP --> the newbie just has to FTP the files up and it works. Fewer variables to manage, fewer things to learn. You go from 0 to 60 much faster. Now, you probably will go from 60 to 100 much much slower than with a different stack, but that's a different discussion...
In this context Ruby on Rails wins because of its standardized Gemfile approach. Every RoR application always specifies the dependencies in a standard way and their installation is always part of the deployment process. PHP has nothing like this.
The same applies to asset pipelines. When your application contains SASS/SCSS or CoffeeScript files, you need to worry about how they're going to be compiled, optimized and deployed. Ruby on Rails also standardizes this so that all you need is the same basic RoR application layout that you generated in the beginning.
So, as long as the web hosting provider supports Ruby on Rails, I think it's currently the simplest way to deploy full-featured web applications. Using PHP will require you to either 1) not use many modern web technologies or 2) build your own deployment processes to support them.
Where the argument of PHP run on any cheap shared hosting fail for me is more about the php.ini config. You can't rely only on the PHP version to know if your app will run.
I work for a large web host and can assure you this is not the case.
If not, then you're not assuring him at all.
edit: let me clarify, I don't assert that ALL php code is unmaintainable, just the quick site I built. Though if you're in the mood to argue: statically typed languages are infinitely more maintainable than dynamically typed ones in my opinion.
Anyone who has worked with codebases in multiple languages for any length of time realizes that's a wrong statement. Maintainable is, to some degree, in the eye of the beholder (and often author), but you can write unmaintainable code in any platform. Everyone seems to love RoR - I inherited a Rails 1 app written over 18 months that still didn't work right, and was essentially unupgradeable - every piece of advice from every Ruby person I talked to was "just start over in Rails 2 and port some of the old logic over".
OK - so now I'm talking 'upgradeable' vs 'maintainable'. Try to 'maintain' a Rails 1 app in 2011 - simply searching for how to do certain things in Rails 1 is pretty hard to do, because the docs are wrong/outdated or simply gone.
But hey - "Ruby is maintainable, PHP sucks", right?
Give me a well-thought out Zend Framework app written by a senior developer with experience writing good code vs Rails hacked together by someone with 2 weeks of udemy lessons under their belt any day.
I think that's an exaggeration. Also, I have something to say about JIT.
Sounds like you're the problem here.
Have you ever tried to install and setup PHP on a fresh server? It's almost as painful as writing code in PHP.
The article is talking about managed hosting, were that might still be true (Admins are incredibly conservative and stubborn individuals).
But for everything else? PHP doesn't work 'out of the box'. It's due to the work of a poor admin somewhere that you can just upload your crap and it runs.
In contrast, I can install and setup a complete Ruby server in about 15 minutes.
whatever the packages are - there's about 4-5 core packages (yum/apt/whatever) or other packages like xampp that set up a default environment in about 5 minutes on most modern systems.
There's certainly a lot of configuration that can be done, but getting a LAMP system set up to allow PHP/MySQL to work is trivial these days compared to 2000.
Cue the puppet and chef supporters who would suggest scripted recipes for everything anyway. :)
apt-get install nginx php5 php5-fpm php-pear php5-common php5-mcrypt php5-cli php5-gd
Takes about 2 minutes.
$ pkg_add snap
$ apt-get install lamp-server
$ apt-get install lamp-server^
Also you have MAMP which is as easy as it comes for setting up a PHP/mysql environment on your computer.
But the strength of PHP goes far beyond this simple point.
I wouldn't even know where to start in Ruby or Python. Just too many dependencies before you can even get started.
So yes it's by any metrics it matter true.
Take it from someone who had to teach himself how to do it and have tried to get started with several languages.
$ sudo tasksel install lamp-server
From scratch, everything is easy to install. I wouldn't say Ruby is any easier to install and setup than PHP. You're talking about installing something like Phusion Passenger on top of Apache. A LAMP stack takes as long as it takes to run `apt-get` or `yum install`. By no means is it 15 minutes; I'd say 5 to 10 with minor Apache configuration and a VirtualHost entry.
He's not only implying it, he states it explicitly. No need to guess, the article is there.
Which is so totally beside the point he makes, that I'm pretty sure you didn't RTFA.
The "market" he describes is NOT installing PHP from fresh on servers.
So if we want a language that can displace PHP in its niche, perhaps we should choose a language that's amenable to short-lived CGI processes. For this, I think a language that can be compiled ahead-of-time to fast-starting native code is appropriate. By fast-starting, I mean that startup should consist of little more than the kernel's exec routine.
I think the Go language would be a good fit.
So the next time you need to write a web app that should be easy to deploy on a shared host, try writing it in Go, using a web framework that supports FastCGI, which can then degrade to plain CGI. Then compile the app on a Linux box, upload it to the shared host, and thanks to the self-contained nature of executables produced by the Go toolchain, the app should be ready to go with no fuss.
But McDonald's is still better food.
Imagine a programmer from a top software company writing long-winded rants about how horrible PHP is; how PHP should cease to exist. Everyone would roll their eyes, and say "Well that's the bloody point of PHP, you idiot!"
McDonald's caters to poor people, especially those who don't have their own cooking skills. This is the challenge for all the people who want to complain about McDonalds - if your chosen food is so much better, then make it accessible in the way that McDonald's is.
"The easy path is often not the best path." -Me
There is a big difference in being ubiquitious and being easy to use, and lets not infer casuality where there is none. Most popular PHP projects come with a good installer, but go to sourceforge and try a lesser known project. Or go back to the 90s and see if installing drupal or wordpress was as easy.
I can argue that shell scripting is the best programming language by this logic.
An incredibly bad and impossible to maintain website, but a "dynamic" website none the less.
From there, ramping learning up to MVC / Frameworks / caching / templates / optimizers is all small leaps from the initial understanding of "put html here, sprinkle php here". Nothing else really has this apart from maybe ASP.
here's the worst of all the bad reasons right here..
It's called empowering people.