The total cost of using PHP?

by Dan Zambonini

I'm not any kind of programming language zealot/fanboy - syntax is pretty much irrelevant; each to their own.

But I've been thinking about the bigger picture of choosing a language, from the business perspective. Sure, most languages can do the same thing, give or take. But what other (non-syntax) issues are there that can influence the 'cost' of adopting one language over another?

We use a mixture of languages (the best tool for the job), but I'm personally a fan of PHP, and have used it religiously for 6 or 7 years. So here are my initial thoughts on the cost of using PHP, based on this experience. I haven't really elaborated on them, but you get the idea. What have I missed out? Do any of these make sense?

  • Recruitment. This one's probably the most controversial. I think there's more 'chaff' to filter through when recruiting/advertising for PHP developers. You could spin this into a positive, and call it 'more choice'. But - compared to, say, advertising for a Ruby or J2EE developer, I've found that there are more 'designers' who think they can develop because they've written a random image function in PHP. And filtering through CVs costs money.

  • Recruitment. Conversely, this low barrier of entry (and cost) means that kids start using it when they're young. So, arguably, an application from a 23 year old PHP developer is often better (at least, more experienced) than an application from a 23 year old VB developer. Some might elaborate on this (he says, in fear of being flamed) and propose that those people who are born developers - the best, 10x achieving people - are more likely to use PHP (or similar; Ruby, Python, Perl) over, say ASP, as they will have started programming at an early age, when their interest was first piqued. If you are 12, 13 years old and you want to start programming, it's a lot easier to get up and running (and experimenting/learning) with PHP than ASP.NET/Visual Studio.

  • Windows. Like it or not, there are a lot of Windows boxes out there. We probably install an equal amount of our software on Windows and Linux servers. But the PHP development effort have (until recently) not taken Windows too seriously, which does increase our cost of using it in Windows environments (lack of ISAPI support was a real downer for a long time). Consistent, cross platform support is a real plus for many languages.

  • Maintenance/Debugging/IDEs. The majority of most large-scale software development effort is through maintenance. PHP has had (in the not-too-distant past) a lack of good quality debugging support (OK, there are some, but they aren't as good as many other languages) and error handling features (e.g. Exceptions, until recently).

  • Market Perception. This shouldn't be under-estimated. In our market, the majority of our competitors throw around terms like 'J2EE' and '.NET' and all other kinds of frameworks. Big business loves these - they've heard of them, they're trusted, they are low risk. So a PHP solution is often seen as the 'open source' or lesser solution, unable to contend with these big frameworks. This adds to the 'cost' in lost sales. I think Zend/PHP are now starting to take this very seriously.

  • Standards/Speed of change/Backwards compatibility. I'll lump these in together, and just cite one example - XML support. Incredibly important for many web based systems, and hence you'd think it would be an important part of PHP? It was quite slow in coming, it changed over many versions, and didn't have backwards compatibility with the earlier functions! That all adds up to extra costs (lost opportunities and additional maintenance). I'd still argue that there are some important XML features missing (I know, I know - I should shut up and develop them myself...)

  • Richness. I'm getting a bit close to the 'syntax' thing here, but one of PHP's killer attributes is the richness of the language - the sheer number and flexibility of its native functions and extensions. Want to do just about anything with an array? Sure, there's probably a single function for it. Dynamically create PDFs, Images, or anything else? Yup, a couple of extra lines. This is where PHP has real value - in RAD/Agile environments.

This sounds more negative than I imagined it would have. It's not meant to be - I'm very happy with the progress PHP has made over the last few years (finally, native Unicode support is coming!).


2005-09-30 11:48:32
The Other cost of PHP
More costs.

Am I the only person in the world who finds PHP is the most buggy language they've ever used? During the 4.x series every point release brought about a change in how functions worked. Hmm bossing love paying developers to recode tools with every upgrade.

Inconsistancy. PHP's function names and the way things are called are all over the place. Is it function_name or functionName or functionname same with package names etc... while this might seem trivial and one could blame it on individual developers these inconsitancies exist in the core language. PEAR seems to at leat try to make standards... but it's way to rare that anybody follows them. Inconsistancy cost $$ because I have to waste time thinking about how developer of X module implemented their stuff and adapt my code to work with it.

Frameworks. PHP is sorely lacking in any mature frameworks. No Zope, Ruby on Rails, or Struts for PHP users, there seem to some people starting down that path now. Frameworks save time and money but giving developers time tested code and a way think about app dev.

Late to the game. PHP is always the last player to the game, XML , XSL, SOAP, advanced imaging everybody else got there first, and everybody else got it there better. So if I wanted to use XML I had to write all my ownstuff. Devtime = money.

Immaturity. Let's face it the root cause of all the above is immaturity. While languages like Python and Ruby seem to have come after PHP the core dev team are experianced language developers. PHP seems to be kind of a rag tag crew of iconoclasts who are learning as they go. I support this whole heartedly, it's how I learned to code. However it's not very efficient if $$ if your bottom line. I expect PHP will be a great language long around version 6.5. Until then I've moved on to more stable and cost efficient pastures.

The only cost advantage I can see with PHP is. A) there is alot of free code out there so it's great for GUI people who don't program. B) every hosting provider supports it so if you aren't running your own shop you can still develop apps for clients.

2005-09-30 13:26:04
Missing XML features?
I'd still argue that there are some important XML features missing

So. Tell us what you're missing, pleeeaaase :)

I'm one of the developers somehow responsible for the XML stuff in PHP. And in my opinion it's really not that much missing nowadays. At least not in the upcoming 5.1. But we always like to hear what others think.

See also for some input others made. Some requests were reasonable, some were already implemented without the people knowing and some way out of scope.


2005-09-30 15:46:51
RE: The Other cost of PHP
Yeah, the changing of functions/libraries really bugs me. I appreciate that it's often because they want to get support in as soon as possible - and I'd rather have something than nothing - but there are so many bits that change around! "No, don't use this funtion for XSLT, use this one now... No, DOM XML is now the DOM extension, and is now in PECL... Sorry, don't use Classkit, use Runkit...". Argh!
2005-09-30 16:17:08
Re: Missing XML features?
You have a fair point - the most recent releases are much better, especially with DOM. And as I spend most of my time stuck in version 4 (as most commercial software developers are, I'd guess), I can't claim to be an expert in PHP 5 XML.

Assuming I haven't missed these in a recent release: I'd personally like to see support for level 3 DOM, as there are very handy new methods for nodes. I may be wrong on this next one, but as far as I know, it's also not straightforward to use any XSLT processer that isn't libxslt or Sablotron? I really want to get a head start with XSLT 2, and I think (though I'm not positive) that I'd need Saxon support for this (?). Of course, there are ways around it, but it would be nice to have it made easy for simpletons like me...

But no, I concede - you certainly have a good point. And as it sounds like you've got some spare time on your hands now, how about implementing an XML Diff function? That would be so cool.

2005-09-30 16:31:16
Re: Missing XML features?
I pressed 'Submit' too quickly! Sorry - I had one more thing to say quickly.

I realise that, as mentioned on the other page you cite, many of these limitations are due to external libraries that PHP is dependant on. But as a user of PHP, not a developer of PHP, all I care about is whether or not PHP offers me certain functionality. A limitation of an integrated library becomes an inherited limitation of PHP; if I were to switch to another language (e.g. Java or ASP.NET), then these limitations may not exist.

But in no way do I want to disregard the huge effort put in by people such as yourself, so that I am able to make a living from using PHP - you deserve a huge amount of admiration and thanks, especially now that it's all coming together.

2005-09-30 18:30:28
Missing XML features?
A SAX parser. I use the DOM parser, but the XML I'm dealing with is only getting larger, and I prefer SAX parsers because they don't slurp the whole XML file into memory.

I'm an experience programmer, but I only use PHP occasionally. It's possible that I've missed the docs for a SAX parser. I'd rather not have to start using PEAR; I'd rather have the SAX parser built-in. If that's unreasonable, then so be it.

2005-09-30 23:48:53
Missing XML features?
There's a SAX parser in PHP since version 3.0.x, how could you miss that? :)

See for the documentation.

If you're using PHP 5, you may also look into XMLReader, which is an alternative to SAX.

2005-10-01 00:03:21
Re: Missing XML features?
XSLT 2: Saxon is AFAIK the only library currently supporting it And Saxon is written in Java, therefore I don't see how that could be easily integrated into PHP. Better someone tries to improve the general Call-Java-from-PHP integration (or try out the product by Zend, which should do exactly that, but unfortunately is not free). And by the way, Sablotron support in PHP 5 is gone. We came to the conclusion, that libxslt is superior to sablotron (faster etc) and fits very well into the libxml2 environment. To sum up, being able to switch the xslt library is not a top priority on our list, libxslt is very well integrated into the libxml2 world PHP 5 is using and making bindings for any other processor would be possible, but still be a hack (and not perform very well compared to libxslt).

DOM 3: There are already some DOM level 3 methods, certainly not all and this may be improved in the future.

XMLdiff: I think, this could be also implemented in PHP code itself, but I'm no expert in that area.

And no, I don't have any spare time on my hand currently, I'm just asking around to see what people miss and what could be done.

Thanks a lot for your feedback

2005-10-01 01:41:47
Re: Missing XML features?
Yep, fair enough. (OK, if you could just rewrite Saxon in C then!)
2005-10-03 01:31:08
windows - and other stuff
In my own experience, windows support has always been outstanding, going back at last to version 4.0.4pl1 (you never tried installing it on Openserver, have you? THAT was a real pain!!!). In fact, it was one of the main reasons to choose PHP as a development platform: develop on a windows box with a little care, dump on a *nix server, et voila'.
Integration with IIS might have been problematic, but I never had trouble convincing a sysadmin to install Apache on windows.

Unicode support: much overrated feature, if you're developing intranet stuff in any western country (ie the 'big corporate' stuff). Just stick to ISO-8859-1 and you'll be a happy man - in fact, UTF-8 is gonna make novices shoot themselves in the foot more often than not.

A few factors worth mentioning, even tough they come close to the 'syntax thing': gluecode written in php tends to be simpler to understand than complex framework code written in other languages, making for lower maintenance costs. Fewer lines of code mean (as a a rule of thumb) less bugs per application, and faster development - but of course that depends very much on the sigle coder skills.

And last but not least, the debugging/ide stuff: it is probably lacking in part because the language is so rich and so simple that it does not need a lot of tools to be manipulated - there was a great graph somewhere comparing 'hard languages' that usually have a greatly developed tool/framework stack and 'flexible languages' that compensate lack of those tools with language flexibility and ease of use. The bottom line: total producivity was similar for the two approaches.

2005-10-03 01:33:14
windows - and other stuff
Oh, and one more tco-lessening feature: online manual with user-added comments. It in fact redefined the whole concept of documentation.
2005-10-03 01:52:07
The Other cost of PHP
Frameworks. PHP is sorely lacking in any mature frameworks
Frameworks also tend to have many problems, not the least of which is they are usually much shorter-lived than languages, and time spent learning the framework-du-jour is not spent coding.

Late to the game
Sorry, but you got it wrong here, at least regarding to web services: php got there first - and better - with xml-rpc.
This a typical example (imho) of the 'less is more' principle (you can call it KISS or whatever you want) that sounds so bad to big enterprise sw salesdroids and has made php so successful, despite its many shortcomings.

2005-10-03 02:34:21
my 2 cents
"I think there's more 'chaff' to filter through when recruiting/advertising for PHP developers."

Well you could also look at what kind of formal software engineering education they've had, and conduct tests at interviews. Not all too uncommon.

"Conversely, this low barrier of entry (and cost) means that kids start using it when they're young"

A side effect that will rise up if someone started at a young age and never had formal engineering education, is that they only know syntax and language specific glitches. Things like refactoring, design patterns and basic architecture are essential to know in a corporate environment.

"But the PHP development effort have (until recently) not taken Windows too seriously"

Well apart from the ISAPI having been around for quite a while now, IMHO Windows is not comfortable to work with. Even though PHP can run on Windows in a relatively stable manner, I avoid it like the plague. But explaining that would result in another big rant.

".. and error handling features (e.g. Exceptions, until recently)."

Keep in mind however that PHP's exceptions do not replace PHP's default error handling mechanism. I'm not sure if I should be very happy about parallel error handling mechanisms.

".. throw around terms like 'J2EE' and '.NET' and all other kinds of frameworks."

J2EE is not exactly a framework. It's a set of tools that can be used to create web applications. PHP does not need any fancy terms IMHO, as proven in the past, PHP has proven and will prove itself, to a certain degree.

"It was quite slow in coming, it changed over many versions, and didn't have backwards compatibility with the earlier functions!"

If you're referring to the old DOM extension, that one has never been marked stable (it never got out of experimental state), so if you use it and complain about changes to it later, that's your own fault. It has had SAX XML support since PHP 3.0.6.

2005-10-03 06:59:12
I've just switched from PHP to ASP.NET and I sorely miss PHP's flexibility. With PHP, writing code is a lot like poetry. Things just work. I don't have to worry about casting variables and making sure every variable is declared before using it.

Another thing I really like about the LAMP environment is I can set up a test web server on my Powerbook and develop locally, without any Internet connection. And when I move it over to the web server, it just works.

Heh, "it just works." I guess that's my Mac user coming out.

2005-12-01 17:06:08
The Other cost of PHP
I have to agree, I am doing a major piece of code with php, the language is inconsistent. There are cases that become ambiguous because the language is poorly specified. Seems taped together. The fact that the object system was an afterthought, and passed everything by value up until 5.0 is pretty lame.

Because others made the decision we are stuck with PHP on the project we are working on now. I long for Python because it tends to be much more regular, clean and consistent. It was built as an object oriented language from the ground up. Others love Ruby, it may be good, but I immediately liked Python and stuck with it so I can't say much about Ruby.

Trying to add extensions to PHP, not as easy as something like Python and SWIG. SWIG was available for Python but not sure it is supported anymore, last I heard.

Python can be used as the main glue language, where the highly optimized routines are written in C. For example, it is possible to write complete OpenGL applications with Python and they will perform well. The Python bindings match the C APIs very closely. So you don't need to learn a completely new API for accessing OpenGL. If you are on the OpenStep platform the PyObjC provides a really great way to access the APIs which is actually in most cases much simpler than ObjectiveC.

Personally, I think people should think twice and check out something like Python before jumping into PHP. It is powerful, productive and well supported with libraries (modules).

2006-03-17 04:04:53
PHP rocks.
I'm a junior web developer, that only started PHP now.
It's so easy, and support and help is available all over the net.
My first 2 modules I built, was soly with forum support.

PHP, Programming with attitude...

erik aronesty
2006-03-17 15:00:15
curious what you think of smx. it's not as powerful as php, but the syntax is completely different - it's not a ruby/pyhton/php/ch clone, imho it's able to to a lot with a little.