Wow… via Patrick Mueller @ IBM I found a post on techrepublic stating that ‘PHP is doomed’. Patricks’ response is done pretty well, but I thought I’d add a few observations as well.

The original poster’s point that PHP is doomed stems from a lack of threading model in PHP. While I’d say that PHP might benefit on the whole from having a threading system in place, it would also require a radical shift in architecture, which would ultimately limit where it can be effectively deployed (I think it would be limited from a practical sense to only Apache 2 running on certain architectures).

Some of the responses to Justin (the original poster) argued that threads aren’t necessary, and that not all developers understand threads. He counters that developers who don’t understand threads will be unemployed in a few years. Personally, I find that a big stretch, and if it’s true, most of the developers I know wouldn’t be employed then. Yet they’re still managing to provide business value to their employers, clients and customers.

Some of you who know me have heard this, but I’ll repeat it here for posterity. I worked in a company with a small PHP team and a large Java team. Some of the Java team had been working on an upgraded system to provide cross platform authentication services. This was to be exposed as a SOAP service. There was about a 15 page spec, and this had apparently been in the works for months before I got there. It didn’t affect me, so I didn’t know about it, until the day it DID affect me. I was told my project had to work with that project, but there was nothing to test against. I was told by that team that it wouldn’t be ready to test against for another 3 months minimum. So, I took the spec and wrote a SOAP server in PHP to implement what was documented. It took about 3 days, and during that time I had a Java developer write a sample Java client to test against it, so we had Java and PHP clients and a PHP server in under a week, functional according to the specs.
Politically, I was like a bull in a china shop, but was also really just trying to get things done so my project could progress. I presented this to the players involved as something we could use as an interim solution while the Java one was finalized. Other projects that needed the SOAP server could use it as well, letting everyone progress, and perhaps taking a little pressure off the Java team (or maybe putting more on?)

I got a couple major putdowns of the system, most of which centered on these two main points:

‘It uses MySQL – that’s a toy!’ – there was incredibly simple SQL which was using generated data objects and an abstraction layer – porting and testing to another platform (MSSQL) would probably have taken 2-3 days.

‘PHP doesn’t have threads!’ – that was it. That was the primary stated reason why we couldn’t use it. Turns out later there were many other smaller – yet bigger – reasons which were completely non-technical, which was all the more frustrating, because there was no need to throw out ‘PHP has no threads!’ as an excuse. There was a functioning and tested system which was already working, but somehow because it didn’t have threads in it it didn’t count. I *never* understood that.

Having seen some of the other code they were in the middle of, and some Java code from others I’ve worked with, I’d say that many (perhaps most) Java developers have no real, or very limited, understanding of the true impact of how threads work, interact with each other and the system, and the things to guard against. As an aside, I’ve complained about Java app GUIs for years – you can usually tell when you’re using a Java GUI because everything is so slow. Go read up on Java defenders’ counters to those complaints – “people writing the apps don’t understand GUI threading!”. I read that gem years ago, and have seen it come up again and again. If it’s so difficult, why don’t any of the IDEs out there help you write properly threaded GUI code? It can’t be that every single person goes out of their way to write code by hand. Most people use some sort of IDE – commercial or otherwise – yet almost all Java apps seem to suffer this fate.

I’ve seen numerous issues affect Java apps, and many (probably 40% of the ones I can think of in the past few years) involved a misuse or misunderstanding of threading. I’m not sure that .NET is any better, as the same issues would likely affect a developer, but certainly Microsoft had the benefit of watching the missteps of Java developers for years and could help .NET developers avoid many of the potential pitfalls threading can bring. Early classic ASP employed a default threading model for the session management which kept sessions bound to a particular CPU, such that heavily hit sites could not use multi-processor servers efficiently. And that was something that there really wasn’t much of a workaround for, save for writing your own session handling code full stop.

Had to rant about this a bit. PHP is certainly not a perfect platform for web app development, but lack of a threading model is not, for most (or nearly all) situations, even an issue. I think part of the original poster’s point was that a main server would spawn threads to hit various web services, then assemble the data, and complete the request. As Patrick points out, this type of model brings up more questions than it answers, and forces the developer to have a much deeper understanding of threading and system architecture in general. Most businesses will be better served by having development staff spend more time on documentation and having a deeper understanding existing and future business logic rather than becoming fluent with threading models.

Wow… via Patrick Mueller @ IBM I found a post on techrepublic stating that ‘PHP is doomed’. Patricks’ response is done pretty well, but I thought I’d add a few observations as well.

The original poster’s point that PHP is doomed stems from a lack of threading model in PHP. While I’d say that PHP might benefit on the whole from having a threading system in place, it would also require a radical shift in architecture, which would ultimately limit where it can be effectively deployed (I think it would be limited from a practical sense to only Apache 2 running on certain architectures).

Some of the responses to Justin (the original poster) argued that threads aren’t necessary, and that not all developers understand threads. He counters that developers who don’t understand threads will be unemployed in a few years. Personally, I find that a big stretch, and if it’s true, most of the developers I know wouldn’t be employed then. Yet they’re still managing to provide business value to their employers, clients and customers.

Some of you who know me have heard this, but I’ll repeat it here for posterity. I worked in a company with a small PHP team and a large Java team. Some of the Java team had been working on an upgraded system to provide cross platform authentication services. This was to be exposed as a SOAP service. There was about a 15 page spec, and this had apparently been in the works for months before I got there. It didn’t affect me, so I didn’t know about it, until the day it DID affect me. I was told my project had to work with that project, but there was nothing to test against. I was told by that team that it wouldn’t be ready to test against for another 3 months minimum. So, I took the spec and wrote a SOAP server in PHP to implement what was documented. It took about 3 days, and during that time I had a Java developer write a sample Java client to test against it, so we had Java and PHP clients and a PHP server in under a week, functional according to the specs.
Politically, I was like a bull in a china shop, but was also really just trying to get things done so my project could progress. I presented this to the players involved as something we could use as an interim solution while the Java one was finalized. Other projects that needed the SOAP server could use it as well, letting everyone progress, and perhaps taking a little pressure off the Java team (or maybe putting more on?)

I got a couple major putdowns of the system, most of which centered on these two main points:

‘It uses MySQL – that’s a toy!’ – there was incredibly simple SQL which was using generated data objects and an abstraction layer – porting and testing to another platform (MSSQL) would probably have taken 2-3 days.

‘PHP doesn’t have threads!’ – that was it. That was the primary stated reason why we couldn’t use it. Turns out later there were many other smaller – yet bigger – reasons which were completely non-technical, which was all the more frustrating, because there was no need to throw out ‘PHP has no threads!’ as an excuse. There was a functioning and tested system which was already working, but somehow because it didn’t have threads in it it didn’t count. I *never* understood that.

Having seen some of the other code they were in the middle of, and some Java code from others I’ve worked with, I’d say that many (perhaps most) Java developers have no real, or very limited, understanding of the true impact of how threads work, interact with each other and the system, and the things to guard against. As an aside, I’ve complained about Java app GUIs for years – you can usually tell when you’re using a Java GUI because everything is so slow. Go read up on Java defenders’ counters to those complaints – “people writing the apps don’t understand GUI threading!”. I read that gem years ago, and have seen it come up again and again. If it’s so difficult, why don’t any of the IDEs out there help you write properly threaded GUI code? It can’t be that every single person goes out of their way to write code by hand. Most people use some sort of IDE – commercial or otherwise – yet almost all Java apps seem to suffer this fate.

I’ve seen numerous issues affect Java apps, and many (probably 40% of the ones I can think of in the past few years) involved a misuse or misunderstanding of threading. I’m not sure that .NET is any better, as the same issues would likely affect a developer, but certainly Microsoft had the benefit of watching the missteps of Java developers for years and could help .NET developers avoid many of the potential pitfalls threading can bring. Early classic ASP employed a default threading model for the session management which kept sessions bound to a particular CPU, such that heavily hit sites could not use multi-processor servers efficiently. And that was something that there really wasn’t much of a workaround for, save for writing your own session handling code full stop.

Had to rant about this a bit. PHP is certainly not a perfect platform for web app development, but lack of a threading model is not, for most (or nearly all) situations, even an issue. I think part of the original poster’s point was that a main server would spawn threads to hit various web services, then assemble the data, and complete the request. As Patrick points out, this type of model brings up more questions than it answers, and forces the developer to have a much deeper understanding of threading and system architecture in general. Most businesses will be better served by having development staff spend more time on documentation and having a deeper understanding existing and future business logic rather than becoming fluent with threading models.