
PHP is the right tool for the job (for all the wrong reasons) - samuellevy
http://blog.samuellevy.com/post/41-php-is-the-right-tool-for-the-job-for-all-the-wrong-reasons.html
======
IgorPartola
One thing I really like about PHP is it's execution model. Here, every request
is mapped to a single static .php file which is executed by a single PHP
interpreter process. The execution is essentially stateless (aside from any
bugs in the interpreter which from what I've seen tend to be few when it comes
to this issue). Essentially, every request gets its own execution environment
and does not have to worry about anything outside of itself. You also get code
reloading: requests currently in progress are handled by old code. New
requests are handled by new code after you replace the .php file.

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.

~~~
judofyr
> You can mess up and create a dirty execution environment.

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.

~~~
polyfractal
> _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._

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-...](http://guzzlephp.org/tour/http.html#managed-persistent-http-
connections)).

3) While not part of PHP itself, most serious PHP applications use something
like APC, which caches PHP opcodes to prevent constant reparsing.

~~~
papsosouid
>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.

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.

~~~
polyfractal
Ah fair point, I misinterpreted the grandparent's statement in terms of
persistence, not necessarily pooled persistence.

------
robomartin
These threads always get "interesting" don't they?

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.

~~~
papsosouid
>However, when faced with having to do a benefits analysis it is almost
impossible to not choose PHP these days

For what? We were already heavily invested in PHP, but still our benefit
analysis had it second last, only ahead of javascript. What benefits were we
missing?

~~~
robomartin
Each organization is going to be different.

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.

~~~
samuellevy
That's pretty much how it is, but I believe the _why_ is largely to do with
the large amount of bad PHP learning aides available for free on the internet
(I'm looking at you, w3schools).

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".

------
nnq
Can you spot the outliers here?: "where PHP has excelled with projects like
Wordpress, Joomla!, _Drupal_ , _Magento_ , Moodle, PHPBB, and so many more.".

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!

~~~
bhughes
Based on experience, I would agree with you on the Magento front (as my
perpetually-in-the-planning-stages blog "I Hate Magento" will attest), but I
have yet to find anything more usable (and customizable) for larger scale
operations. I know there _must_ be something less bad. Thoughts, anyone?

~~~
meaty
Agreed - its a stinking turd, but at least it's not oscommerce :)

------
JonnieCache
I don't understand why "low-skilled people can use it" is constantly trumpeted
as an upside. If you can't work out how to set up the DB by hand (for
example), there's little chance you're going to be able to get through the
rest of the job without making a horrible mess which you (more likely your
client) will come to regret.

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.

~~~
EwanToo
You're right, if we took this attitude in civil engineering or medical science
then it'd be a problem, but hey, it's not those things, so why waste the time,
money and effort that it would need?

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.

~~~
JonnieCache
Let's torture this analogy some more.

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.

~~~
pc86
God I hate analogies.

------
darkxanthos
Why is PHP so threatening to so many developers? Don't use it. Don't take jobs
where it's the primary tool.

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.

~~~
papsosouid
>Why is PHP so threatening to so many developers

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.

~~~
dubcanada
"horrible mess of shit PHP developers" has nothing to do with anything.
Horrible mess of shit Ruby developers can be just as ugly if not more.

~~~
jeltz
It can be but in my anecdotal experience the mess left by PHP developers is
the worst. Especially when it comes to blatant XSS and SQL injection
vulnerabilities PHP holds a clear lead.

------
nkozyra
I don't see PHP as any more easily deployable than Node, Rails or even self-
contained Go/Gorilla.

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.

~~~
StavrosK
Come on, I hate php with a passion and even I will admit it's easier to deploy
than anything else. Go comes close, but still requires writing a service.

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.

~~~
nkozyra
> Come on, I hate php with a passion and even I will admit it's easier to
> deploy than anything else

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.

~~~
StavrosK
Say you're on a shared host. How do you deploy Python in the same time as
copying a few files in? You have to copy the files in _and_ do some more
things, which is a strict superset of the PHP way to deploy.

------
donutdan4114
If you use a decent web framework for your project, I think PHP isn't a
terrible solution. It will be maintainable, organized, thoughtful, and
documented. Obviously in the end, _it's still PHP_ , but a good framework
makes those more complex PHP applications understandable.

If you're building a website (in any language) without a framework, you're
doing it wrong...

~~~
papsosouid
If you are using a framework, then you've lost the "advantage" PHP had to
begin with: simplicity. Once you are using a framework, everything is just as
complex as with rails or django, so why not just use one of those?

And your last statement is terribly ignorant. There's tons of web sites and
apps that are better off built without a framework.

~~~
donutdan4114
I'm sure if you think of any successful web site/app they use some type of
framework, even if they made it themselves.

~~~
papsosouid
I'm sure you are very wrong. Again, tons of sites a framework is counter-
productive, not helpful. Do you think a framework makes sense for a 99% static
site that just wants to use include($header) and have an email contact form?
Or any of the tons of random admin interfaces people need to write for things
that don't fit in to the assumed database backed web app mold?

------
conradfr
I'd love to use Python or Go or whatever. But everyone wants to pay me to code
PHP on some mediocre stack. So be it ...

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.

~~~
nkozyra
But this is a different issue altogether.

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.

~~~
conradfr
I guess it goes hand in hand. PHP is good enough for most of the jobs,
cheaper/easier to host, and you get cheaper and easier-to-find developers

------
bradwestness
This is what the team behind Discourse is attempting to address somewhat,
making Ruby software as idiot-proof to set up as PHP applications.

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.

~~~
samuellevy
I think that's a chicken/egg situation there.

~~~
corry
Agreed. As is often brought up in PHP threads, the biggest thing is universal
adoption of PHP in web hosting. People learning how to stitch together web
pages aren't going to grab a VPS, learn the complexity of managing the server,
and use something complex like Rails (where there's a language, a framework,
and MVC to learn).

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...

------
dicroce
My opinion on the success of PHP has more to do with how it integrates with
Apache... All of the other languages were designed as languages first, then
web development was bolted on... HTTP is fundamentally request / response
oriented and PHP provides brain dead access to GET and POST vars via simple to
understand global variables... In addition, the same mechanism is provided for
session state...

------
kennu
I would note that the article doesn't consider having to install any custom
PEAR/PECL packages that your PHP application might require. Sometimes they
need to be installed on the command line (as root), or sometimes as OS
packages. If you're using managed web hosting, you will probably need to email
the administrators and ask them to install the needed packages, and they might
refuse.

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.

~~~
davedevelopment
Composer (getcomposer.org) and Packagist (packagist.org) are largely a popular
replacement for PEAR, though once you need a C extension (PECL), you're right,
it does become a pain.

------
ollybee
"the only language that makes deploying a website effectively idiot-proof"

I work for a large web host and can assure you this is not the case.

~~~
samuellevy
I've worked for a reasonably sized (business) host myself, and yes - anything
that's idiot proof is just waiting for a bigger idiot, but PHP is far easier
to deploy for a non-programmer than anything else.

------
DoubleCluster
Exactly. I detest PHP, but I've used it to quickly build a sign-up website for
an event. If you pair PHP with an interface library like Bootstrap and an ORM
like Paris/Idiorm you can have something up and running cheaply and quickly.
Is it maintainable? No, but that's not important in this case.

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.

~~~
mgkimsal
"Is it maintainable? No"

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.

------
netmute
Simply not true.

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.

~~~
jstalin
Really?

apt-get install nginx php5 php5-fpm php-pear php5-common php5-mcrypt php5-cli
php5-gd

Takes about 2 minutes.

~~~
papsosouid
If you want to pretend that is all that is involved, then your argument
suggests web development with haskell is just as easy to setup as with PHP:

    
    
        $ pkg_add snap
    

Well, that was easy.

------
mwcampbell
The one technology that's nearly as ubiquitous on shared hosts as PHP is CGI.
Plain, one-shot process-per-request CGI.

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.

~~~
sneak
Except that my web host runs freebsd.

------
rywalker
When people complain about McDonalds being horrible food, not fit for human
consumption, they will often talk about the health benefits of their favorite
foods. And you know what? They're right.

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

~~~
alexjeffrey
"best" is a very subjective term. PHP is not the best language for making in-
house web app stacks like many people on HN build, but it is the best language
to deploy a basic marketing web page for the chip shop down the road. That's
the point I believe this article is trying to make, and basically just boils
down to "the right tool for the right job".

------
gnuvince
I guess that if "can be deployed my a non-technical user through FTP" weighs
heavier than all other technical considerations put together, then I guess PHP
is the right choice. Or you could just CGI.

------
mqzaidi
Try dropping files in an environment where apache / php is not installed, or
where db drivers or gd bindings are missing. Or try to set it up with nginx
and php5-fpm.

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.

------
grimborg
I disagree. Deploying a Python site, for example, is equally easy.

~~~
scribu
So, you're saying that you can buy cheap shared hosting with a Python server
set up, where you only need to upload the files via FTP and it will just work?

~~~
rywalker
Deploying with FTP is harder than deploying with git.

~~~
scribu
Maybe, but even so, learning to use FTP is a heck of a lot easier than
learning to use git.

------
taproot
Its sad no other languages have noticed this. PHP is a natural progression
from HTML for beginners. Learn HTML, sprinkle a bit of inline PHP here and
there, and bam you have a "dynamic" website.

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.

------
btbuildem
> It works, out of the box, for people who don't know what they're doing

here's the worst of all the bad reasons right here..

~~~
coldtea
Absolutely nothing bad about it.

It's called empowering people.

------
mwcampbell
How cheap does the shared hosting need to be? DigitalOcean offers virtual
machines starting at $5/month. At a somewhat higher level of abstraction,
WebFaction offers shared hosting for $9.50/month with a broad selection of
technology stacks.

~~~
andyroid
When doing freelance jobs, I've rarely had the chance to choose the hosting
provider for the client as they in most cases already have a web site which
they need to extend with certain functionality (web shop, blog, etc).
Convincing them to switch hosting provider without obvious (to them) benefits
is pretty pointless. Of course, your point still stands if the job entails
creating a platform from scratch.

------
mnazim
Only way to "idiot proof" anything is to not let idiots build your software.
Regardless of the tools, idiots _will_ create a mess.

