
Why We Stick With PHP (and don't move to Ruby or Python)  - jv22222
http://blog.liip.ch/archive/2011/02/24/why-we-stick-to-php.html
======
latch
Renaming this to "We stick with PHP because it's what we know" would eliminate
the need for most of the post. I'm not saying it isn't a valid point, I'm just
giving a TL;DR.

The other two, less emphasized, points are: it isn't as stale as everyone
thinks and you can be as [un]successful with it as anything else.

These are three very common and legitimate arguments. However, both sides of
the language wars tend to see things in absolutes. Experience can be an asset,
just like it can be a liability. The chance that you'll recognize your own
experience as anything but an asset are slim to none.

~~~
Udo
There may be another point: the author asserts PHP is just glue "between the
front and the back" of a web application, I guess with the implication being
that it's not really important. However, I don't believe the glue analogy is
valid. Typically, the server-side scripting language implements the business
logic, the real data structures (as opposed to what's being saved to DB) and a
large part of the layout. That's not just the glue, that's pretty much the
whole neocortex.

~~~
jasonlotito
> I guess with the implication being that it's not really important.

You'd guess wrong then. The implication isn't that it's not important. Rather,
that it's not important to the resulting web page. That the web page is
written in Ruby or Python or Perl. This isn't to say that what inside doesn't
matter to those working with it.

To provide a comparison: I don't care if a game uses C, C++, Objective-C,
Java, etc. I care about the end result.

At least, that was my understanding of what was written.

~~~
Udo
> _Rather, that it's not important to the resulting web page. That the web
> page is written in Ruby or Python or Perl._

Without going into a pointless flamewar about the definition of _important_ ,
and what the author possibly meant as opposed to what was actually written, I
believe the choice of technology stack does indeed influence the outcome of
the project in many ways. But that's not really the point here at all. The
author's assertion that PHP is "just" a glue component simply doesn't reflect
the amount of heavy lifting done by it.

~~~
jasonlotito
> I believe the choice of technology stack does indeed influence the outcome
> of the project in many ways.

Project.

> Rather, that it's not important to the resulting web page.

Web page.

I was merely referring to the HTML that gets sent to the browser. I wasn't
suggesting that the technology being used doesn't affect the project.

> The author's assertion that PHP is "just" a glue component simply doesn't
> reflect the amount of heavy lifting done by it.

I just said I think you are reading too much here, and inferring things the
author never intended, especially considering the context of the article,
especially around the part being referenced.

I agree, it's useless to speculate. So, maybe you should focus on what's being
said rather than putting your own spin on it? =)

~~~
Udo
> _So, maybe you should focus on what's being said rather than putting your
> own spin on it? =)_

This is the second time you used language designed to escalate this into some
kind of personal attack. Why? Simply say you disagree and move on. (I even
modded you up the first time.) It's not like one of us has a huge thesis to
defend here. It's a minor point about a minor article.

~~~
jasonlotito
> This is the second time you used language designed to escalate this into
> some kind of personal attack.

I've done no such thing. I've stated clearly my opinions. If you feel offended
by my opinions, I apologise. That being said, I don't preface everything I say
with weasel words.

I personally believe doing this (though you might disagree and if you do
that's fine) that weasel words are mostly useless (though they do help at
times for people who infer more than intended) and I really try to avoid using
them as much as I can, though I have been known to fail at this. =)

> Why?

I haven't intended to do this. I didn't "design" anything. At most I felt that
the previous statement _could_ have been taken the wrong way, hence the smiley
(Which is basically my way of saying I don't intend to start a flame war). You
were, in fact, putting your own personal spin on things rather than discussing
what was actually said.

Basically, no offence was intended.

~~~
Udo
I'm not offended, I just felt the discussion was taking an unnecessary turn
towards the unproductive side, about a point that is simply not worth the
effort we both have so far unwisely invested into this exchange ;-)

I do believe "weasel words" are important, not only because stating personal
opinion as fact is impolite, but mainly because it can be vital for the
structure of an argument to distinguish possibilities, speculation, belief,
theory, and factual data.

------
bad_user
I guess this is a joke; but in case it isn't, this is what I'm getting when
visiting the website:

[http://farm6.static.flickr.com/5131/5472866239_05117cc8a4_b....](http://farm6.static.flickr.com/5131/5472866239_05117cc8a4_b.jpg)

Hey, what can I say, if it works out for you ... :)

 _EDIT -_ I guess I'm upsetting people :)

I've got nothing against PHP or other technologies. If it works out for you
that's fine.

But a big error stacktrace on an article that tries to explain your decision,
coming from that same platform you've chosen, giving away the directory
structure of your website and even some implementation details?

Come on, that's like a security consultant getting hacked :-) At least put a
custom HTTP 500 handler in Apache through the ErrorDocument directive. How
hard is that?

~~~
damncabbage
Good God. MDB2?

(For reference: it's a very old, very deprecated DB abstraction library; it'd
be like building GNOME apps with GTK v1.)

~~~
chregu
yeah, we ditched using that a long time ago (but the main contributor to MDB2
is actually working at Liip ;)), but our blog software still uses it. The next
iteration of that will not, we're switch to doctrine2's dbal.

------
edw519
Normally I avoid these language war threads, but I just thought I'd mention
that I have customers who use this 47 year old language:

<http://en.wikipedia.org/wiki/BASIC>

and absolutely eat their competitors' lunch with it.

It's not how big your tool is, but how you use it.

~~~
pavel_lishin
What do they use it for?

~~~
edw519
Business systems: inventory, sales orders, purchasing, forecasting,
accounting, etc.

One is one of the largest master distributors of industrial supplies in the
world.

Another is a web-based and catalog distributor of consumer goods (mostly
apparel.)

Each has acquired 5 competitors in the past 10 years, converting all of them
from whatever they were running to their 20+ year old software written in 40+
year old technology. Both were super agile long before any of us ever used the
term.

(All client side web software is written in javascript. Some things do
change.)

~~~
tianyicui
Which kind of Basic? Visual Basic .NET?

~~~
edw519
There may be concurrent instances of "super agile" and "Microsoft", but I have
never witnessed one.

The two companies I cited use InfoBASIC, each on a different variant of the
old Pick operating system:

<http://en.wikipedia.org/wiki/Pick_operating_system>

~~~
jacques_chester
In fairness, Pick would be a lot of the secret sauce here.

------
PedroCandeias
The op makes an extremely valid point: php _works_ for his company. Clearly
they're more concerned about the end result than the means through which it's
accomplished. And isn't that the way it should be?

We're not talking about a freelance web developer here, who can easily
experiment with different languages for each new project. It's a company with
a large existing code base, which needs to function properly and, as it
happens, _so it does_. Why throw all that in the bin just to be cool?

Remember, the op does say they experiment with other languages at the company.
They have yet to find one whose advantages are amazing enough to be worth a
complete rewrite of the company's code base. That's not unresonable. So why
all the "they're just can't be bothered to change" comments?

~~~
FreebytesSector
There are many situations in which rewriting the entire codebase can destroy a
project. I have seen it happen. People get excited about a new language or
framework and decide to rewrite their code in it. They want to add a single
new feature that would be easier to do in the new language. They could still
do this in the old language, but it would take longer. So, they begin to
rewrite. They get bored, and the project never gets finished or they are
inexperienced, and the project takes much longer than anticipated to get up to
the level of the original. It is an unacceptable delay in most cases. For new
projects, use the appropriate languages, but rewrites for large businesses are
often the nail in the coffin.

------
oemera
To be honest in most of these mentioned languages you can reach the same goal.
There is nothing you can't do with a language which can't be done in the other
from the end user perspective.

But I have the odd feeling that while it is good to stick to a language (for
strategic reasons) it is bad for improving code, getting better at what you
are doing from a developer perspective. If I hadn't learned Python and wrote
something in Python I would never be the same developer as I'm now.

When you look at for example Ruby and Rails there are so much better things
you can do in the testing area. Ever used RSpec and Cucumber? You should know
what I talking about. This is awesome stuff and it will let you develop a
quality web app in days which is also fully tested.

What I'm trying to say is that YOU HAVE TO stay hungry as a developer about
what is next BUT you should carefully choose what to you use in business.
Looking at the same stuff (PHP) and going only to PHP conferences and hanging
around only with PHP developer won't help you to get a better developer in the
overall perspective.

Last but not least I want you to read Paul Graham's essays about Python people
and why you will get better Python developer than any other:

<http://www.paulgraham.com/gh.html>

<http://www.paulgraham.com/pypar.html>

~~~
aDemoUzer
I had read the Python Paradox 2 months ago and had agreed with it. A month
ago, I got a job at a company which uses Python. I had not used it before, for
I am a PHP-guy. I learned Python because I wanted to get the job. I continue
to use PHP for my own personal projects. Hence, I disagree with the statement
"people don't learn Python because it will get them a job; they learn it
because they genuinely like to program and aren't satisfied with the languages
they already know." I am actually quite satisfied with PHP - it is still my
primary language choice, while I learn Python on the side.

~~~
mak120
Python Paradox was written quite some time ago. Back then there were far fewer
jobs for Python. python has become a lot more mainstream since then, hence
your story of learning Python just for the sake of getting a job. IMHO, the
idea of the Python paradox no longer applies to Python today.

~~~
nagnatron
One day people will start learning Haskell to get a job.

A boy can dream...

------
chregu
I'm the op and that's what I just posted as a comment on the blog for all the
(very constructive) input I got from here and on the blog itself:

 __*

Some comments to your comments (thanks for the feedback):

First: We don't stick to PHP just because we have invested so much in the past
and can't easily change. We stick to PHP because we think it's actually good
and as Jordi said: "Gets the shit done" and therefore still do invest a lot
all the time in PHP. We know there are other solutions to the same problem and
we're sure they are also very good, but we don't think they are better than
our approach with PHP for our use cases.

And we don't hire the wrong people (because most of them are actually using
PHP as well in their non-work time). We specifically try to hire the best PHP
people available, we're heavily involved in the PHP community and from time to
time one from those communities comes to work for us.If one would say "I love
coding Python, but for money I'd do PHP as well" THIS would be the wrong
person for a job here.

So, everyone saying we're just sticking to PHP for historical reasons got it
backwards. We're sticking to PHP because we think it has a future and still
investing in it is definitively worth it (that we have such a large "rucksack"
of PHP code and knowledge is an additional advantage, not the only defining
one)

If we would think "Ou shit, we have used PHP so much, it's actually shitty and
we'd all like to code in python" then something would be very wrong with this
company and I'd have to expect a mass-exodus all the time :)

And one last thing: We of course do use other technologies. The obvious ones
like Javascript and HTML5 (we think more and more interesting stuff happens
there than on the server side), mobile stufff with eg. Phonegap, content
storage with jackrabbit, redis, varnish, etc etc... We also use rake and
python stuff in some projects (mostly for CLI-scripting). And last but not
least we're starting using node.js as well. That looks indeed very promising.

------
jbm
As someone who switched from PHP to Python, I don't understand why this is so
controversial as a statement. I'd expect 58 comments on Reddit or Slashdot,
not on HN. (Aware of the irony of commenting on this myself, but please
forgive me the blasphemy)

TLDR is "It works for us, why shake things up?". Doesn't that fit the Startup
ethos?

Python and Django work for me far better, but I often find mod_php and php
allow you to prep quick "small scripts" for sites that are far more easily
deployed than an equivalent in Python or Ruby. I wouldn't build a whole site
in PHP anymore, but I can see how one might feel the ease in testing /
deploying might yield benefits.

~~~
scott_s
Most of the comments here agree with the article. I wouldn't call it
controversial, but it's a topic people clearly want to talk about.

------
soulclap
The most promising point in this article is that they're mentioning that the
newer PHP frameworks are trying to work out how to make components reusable.

Most of the good (and 'modern') PHP code is 'jailed' in frameworks right now
or quite hard to find, hidden away in github repos that aren't getting any
attention. Really wish PHP had a central place for new libraries like
rubygems, based on phar. (And yes, I know PEAR but that's not very PHP5 at
all.)

~~~
jasonlotito
> And yes, I know PEAR but that's not very PHP5 at all.

Symfony uses pear to distribute itself. You can get Zend from pear. PHPUnit
does as well. Numerous other highly respected PHP libs use pear. Granted, they
use their own distribution channels, like Debian. Pear isn't intended to be a
central hub, but rather a distribution method. Couple with this Pyrus
(<http://pear2.php.net/>) and Pear2, it's widely used by experienced PHP
developers. Then you have pecl on top of that.

The problem isn't pear or pecl or any of that. It's that people don't bother
to learn what's out there. They just associate pear with PHP4 and leave it at
that. This carries over.

The other problem is that your average PHP devs build environment isn't as
server based as it is for perl or ruby. Most PHP people just upload a file
directly to the server and refresh the web page.

I imagine most people would be surprised by the number of really cool and
interesting things going on in the PHP world, but because it's PHP, they elect
not to learn about it.

> Most of the good (and 'modern') PHP code is 'jailed' in frameworks right now
> or quite hard to find

That's another misconception. I think it's hard for 'new' people to PHP to get
a handle on everything, and I think their would be great value in pulling it
all together. The problem is, the people that know about all this stuff aren't
new, and we haven't really stepped back to look. However, most modern
frameworks are easy to mix and match, and use only the parts you want from it.
Their is obviously cases where it could be improved, and their is always a
push to do this better.

~~~
soulclap
When I said PEAR I referred to the pear.php.net packages being PHP4 style and
dependent on PEAR_Error and all. I am aware of the fact that Symfony and a
couple of other large projects are available via PEAR distribution servers.

Haven't seen pear2.php.net before though but after a quick look just now -
with just a couple of libs and hardly any updates in 2011, it doesn't look
like it's doing very well. And again it seems to have dependencies and wants
you to use custom error libraries.

And I am not sure what you mean to say regarding most code being jailed and
this being a 'misconception'. If you aren't on PHP 5.3, you can't even find a
lightweight (means not Doctrine) working standalone implementation of
ActiveRecord, although lots of frameworks provide similar functionality. Just
one example. And looking at the other comments here I don't seem to be the
only one who noticed this.

And it's not that I am not seeing what's going on. I see that Symfony2 is
making an effort but haven't worked with it yet. But I also see that I am
watching 50+ repos of 'promising' more or less under-the-radar PHP 5.3
projects on github to prevent 'missing out' on something I _could_ use in an
upcoming project.

Just saying that it'd be great if someone steps up and manages to establish
something like rubygems in the PHP world, most likely for PHP 5.3 and up,
maybe based on phar but with emphasis on loose coupling, reusability and
keeping things 'compact'. I don't have the perfect solution either, all up for
discussion.

~~~
jasonlotito
Gotcha. That makes more sense. =)

You might be interested in this: <http://pearhub.org>

~~~
soulclap
Ah right, I totally forgot about that one!

------
smokestack
These are all very good reasons for why _they_ should stick with PHP, and for
anyone else who has already invested a lot into PHP. I think minimizing your
server-side technology to "glue code" is a mistake, and there still needs to
be a good deal of weight placed on that decision for new startups, based (as
always) on the problem and the people. It would be a disastrous mistake for a
company in their position to suddenly switch over to python or ruby this far
into it. For projects that aren't already that deep into the hole, there are
usually better options.

~~~
jdap
I'd like to see some posts on practical experiences in cases where there's
enough perceived benefit in switching from LAMP to justify the effort. I have
experience a generation back, moving from proprietary stacks, and learnt two
contradictory things:

1\. Re-engineering projects constantly fail the catch-up test (the legacy
system picks up speed under threat)

2\. Legacy systems kill great companies slowly but surely

In that contradiction you also have the startup gap - if your v1 does a tenth
of the incumbent's v100 and you can pick up some market share, you can win on
pace and focus alone.

------
mnazim
"server side language is just a glue between the front end and the data
source" is the stupidest part of this post. Rest is fine, as latch said that
sticking with what people know best is not bad and probably does not need a
blog post. :)

Just my thoughts!

------
PaulHoule
It's not true that "PHP isn't being innovative"; recently PHP has added
closures and it's also addressed issues in static inheritance that have been
completed ignored by C#, ruby, python, scala and such.

~~~
troels
I think you'll find that the problem with "late static binding" is being
ignored in Ruby, because it's an non-existing problem.

PHP - as a language - is certainly not innovative. That's OK though - The
strength of PHP is low complexity and stability. Innovation can be a threat to
these goals.

~~~
PaulHoule
PHP is definitely conservative in syntax, but it's not a dead language, like
Java.

------
neovive
The article makes some excellent points with regards to not throwing out
existing/working code and knowledge. There's quite a few good articles about
the problems of full code rewrites.

Regarding the "glue" reference, given the increasing popularity of JS on the
client-side and server-side this is clearly becoming more true. Beyond
business logic of your app (the one area where PHP can hold you back on large
projects) more and more code is moving to the client-side. For a small to mid-
size web app, it's entirely possible to write everything on the client-side
and use PHP only for DB / Model interactions (and there are some excellent MVC
frameworks to help with that -- Kohana for example).

------
trustfundbaby
I don't even understand why there has to be a blog post about this. When you
make a major investment in a technology you don't just wake up one morning and
rewrite it using another one.

Thats how you lose money and your competitive edge ... I had a small PHP app
that I transitioned to Ruby on Rails ... it took 2 months (mostly because I
was doing it part time and was only just getting serious with Rails) and that
whole time I was falling behind to a competitor because I wasn't adding new
features and fixing bugs.

I'm glad I did it in the long run, but still ... rewrites to take advantage of
the flavor-of-the-month technology can be _very_ overrated.

~~~
stylejam
Especially because if the main argument is that "it works" you're not
discussing the merits of the language, you're simply stating that it's turing
complete (yes, you can do "everything" with it) and that it works (HINT:
whitespace works too - <http://compsoc.dur.ac.uk/whitespace/>). Doesn't seem
very good points to me, but some kind of catch all statement: if it works for
you, why in the hell should I have to question it ? :)

------
jrockway
I don't think PHP is that good of a language to use for a glue from frontend
to backend. Compared with Perl, Python, and Ruby, PHP is missing a number of
important features; ability to serve multiple requests in the same OS thread
(coroutines / events), ability to abstract the database in an OO way (do they
even have prepared statements yet?), and so on. Its JSON parser is also slow,
and JSON is how browsers and servers communicate now.

Anyway, not buying it. PHP's asset is "you get MySQL and templating for free
in pages served by Apache", but most web apps don't use MySQL, templating, or
Apache these days.

~~~
uniclaude
I'm no PHP fan, but you're a little wrong here. Please see [1], or provide a
better source so we can all be enlighten.

[1]: <http://news.netcraft.com/archives/2011/>

~~~
jrockway
The author of the article says he's using PHP for glue, not for writing CGI
apps. There are certainly a lot of legacy apps are of the old-style "click a
link, send HTML as a response". But the new "glue style" is about writing your
web app as a JSON server that speaks HTTP, and then writing the UI in
Javascript to run in the browser. That's what I'm saying nobody uses Apache
for.

The way people write new apps now is with high-performance server processes
that can handle tens of thousands of clients per thread. Apache and PHP do not
do that. 99.999% of the Internet is legacy apps, and so Netcraft statistics
will tell you how people were writing apps 5-10 years ago.

~~~
Joeri
If you're serving tens of thousands of clients, each client has to have a very
low server footprint, so that means you're not doing much in-memory
manipulation of datasets. In business software, that would be the exception,
not the rule.

I think a big driver behind PHP is the simplicity of the model. Each request
can pretend it exists in isolation, having the whole web server to its own.
Simplicity + good enough = popularity.

------
9elements
I guess in the end it's all about a companies culture and economically it
boils down to "can I sell it". I want to add some random thoughts:

\- Probably PHP wasn't your first language, you came from somewhere maybe
Perl, maybe Java. There were reasons why you'ved switched. \- Is switching so
hard? In my experience it is not! Good programmers are good programmers in
every language. Get an expert to make your transition as smooth as possible.
\- You do sell innovation - why not have an elite unit that can be with the
new stuff. You can do 80% in your biz with stuff you know.

------
zarski
"server side language is just a glue between the front end and the data
source"

I agree. Front end work is dominating my time in web app. development. Server
side is getting less important day by day.

------
S_A_P
It seems to me that there are few reasons to switch from one scripting/dynamic
language to another. One would be a compelling framework/library, the other
would be performance. However, it seems that switching from Python to Ruby to
PHP would amount to negligible performance differences if the code was well
designed. Otherwise, if it were a problem of scale, then you would likely
switch to something lower level/compiled me thinks.

------
AffableSpatula
I have yet to come across a compelling web framework written in php.

If re-use between projects was really of concern for their community, they
would've pushed for a standard http interface like rack - which they haven't,
aside from a couple of brief (largely ignored) experiments.

php is a necessary evil in some instances simply because some useful apps have
been built with it.. but if I'm writing a web application from the ground up
there's no way I would opt for php.

~~~
harisenbon
I rather like CakePHP (it's like ruby on rails, in PHP!(tm)).

While it maybe doesn't live up to it's RoR hype, it is a really solid
framework, and has cut down on my development time by more than I can possibly
express..

I find it alot easier to use than Symphony, and you can generally get a CRUD
up and running in about 10-20 minutes right out of the box.

~~~
morganpyne
Just a quick note - Symphony (the CMS) is different to Symfony (the Framework)
- I presume you meant the latter? These two seem to get confused all the time.

~~~
harisenbon
Sorry, I did mean Symfony (the Framework), not the CMS.

------
sunkencity
What I really like about PHP is that the language is built in such a way that
an exception isn't fatal, a page can still render. Just print out the
exception or log it, and then continue on and try to render as much as
possible. Like a fighter taking a hit but still fighting on, instead of going
belly up like finer languages do.

------
markbao
I generally agree with this article, but...

 _"nowadays all those server side (scripting) languages are mainly the glue
layer between the front-end (the browser part) and the back-end (your storage
and "database" solution)"_

Sorry, what? Maybe if you're writing CRUD apps...

~~~
kingofspain
They did say _mainly_ and I would hazard a guess that most people are just
writing CRUD apps.

~~~
ams6110
Wouldn't most web apps be CRUD apps? Facebook is a CRUD app.

~~~
dmoney
Depends how thin the layer of JavaScript is over the CRUD part of the app. And
if the app talks to a service hub for lots of offline processing, is it still
a CRUD app?

------
KeyBoardG
I stick with PHP because I've always viewed it as a "C++ for the web". C++ was
the first language I wrote useful application with so it was familiar.

------
hackermom
Another "why" that was left out in the article, something that is of great
concern to a lot of projects, is computational performance. A whole lot of
good can be said about both Python and Ruby, but "swift performer" is
definitely not one of those things.

~~~
troels
Python is generally a bit faster than PHP though, and while Ruby is dog slow,
both languages are in the heavy end for their class.

Ref: [http://shootout.alioth.debian.org/u32/which-programming-
lang...](http://shootout.alioth.debian.org/u32/which-programming-languages-
are-fastest.php?gcc=on&python3=on&php=on&ruby=on&calc=chart)

~~~
towelrod
That kind of performance just doesn't matter that much though. I recently
benchmarked my fairly standard Rails app on 1.8.7 vs. 1.9.2, and the numbers
for delivering a page are basically the same.

1.9.2 is much faster for calculating Fibonacci numbers, sure, but since
webapps are mostly IO bound it just doesn't matter.

~~~
igouy
Who's shown Fib?

If "it just doesn't matter" then what's the point of 1.9.2 performance
improvement?

~~~
towelrod
There's not much of a point -- that's why 1.8.7 is still around, and why
uptake on 1.9.2 has been so slow.

If 1.9.2 really made every HTTP request go 2x as fast, don't you think every
Ruby shop would have switched to 1.9.2 at least a year ago?

------
igorgue
This guy is from the past.

I've been thinking: "Why stick with Ruby or Python and not move to Scala or
Haskell?"

~~~
Joeri
Or go right back to Lisp, and get some real work done? ;)

------
carlocci
in short: be careful in choosing the technologies you base your company on
because most of the times the sane business decision is that you might be
stuck with them for a loooong time.

