Wednesday, May 4. 2005
Why Not PHP?
Following up on a recent post explaining why PHP works in the Enterprise, I thought it might be equally useful to lay out the common concerns I have heard over the years from programming shops trying to make the case against PHP and for another web development platform.Here are a few off the top of my head:
- PHP coders are sloppy
- PHP doesn’t scale
- PHP runs heavy
- PHP doesn’t have a solid object model
- PHP lacks vendor support
- PHP packages are full of security flaws
- PHP doesn’t handle recursion well
- PHP is open source, and therefore impossible to sell
- PHP can’t handle complex business logic
- PHP is not strongly typed
Clearly, some of these are myths and some are legitimate concerns that require strategy to address. The first “complaint” can be addressed by reading my article in PHP Magazine on “Enterprise PHP Coding Standards.” The second is addressed in my forthcoming article in that same magazine entitled “Farming PHP.” The third issue I am addressing in an article I am still working on about “High Performance PHP.” The less-than-solid object model, limitations on recursion, and other stains on PHP’s reputation are addressed in PHP5, and can be mitigated in PHP4. Others—like the belief that PHP can’t handle complex business logic—are simply myths.
Still other issues, like how to perform a security audit on an existing package before deploying it in the enterprise, constitute fertile ground for discussion, explanation, and strategy. At this point, I’m thinking that between adressing the common complaints against PHP in the Enterprise with solid strategic advice and extolling the virtues of PHP for business-critical applications, I could write a book. Would you buy a copy? For yourself? For your boss? More importantly, how would a resource like this contribute to shifting the perception that PHP is somehow not ready for the enterprise and bring it to the forefront as a viable option—where it belogs?
< Previous Entry | Next Entry >
Comments
Display comments as
(Linear | Threaded)
Would I buy the book? Yes…both for myself and others. I’d be extremely interested to see the case being made for the adoption of PHP for enterprise scale applications. I agree with your stance on most points that you’ve raised (I’ve not worked with PHP 5 to any great degree as of yet, so I can’t really speak to it’s new object model).
PHP has suffered image wise in the past because of some of the very things that make it great…easy accessibility/open source and mass adoption in recent years. Most notable is the idea that PHP coders are sloppy, and do not program to proper standards. While this is true to a certain degree, the same can be said of developers in other languages…proper standards are a result of learned style and direction, not a result of language. I shudder to think of some of the c and c++ code I’ve seen over the years.
If the arguments made in the book are well structured, the proposals well researched, then I’d think such an endeavour would stand a good chance of educating the naysayers regarding php’s elevation to Enterprise solutions. It’s certainly a direction worth exploring. Given the current views of those at the top, however, it would have to be pretty convincing.
With you at the helm, I’ve no doubt it will be.
Keep me apprised.
PHP has suffered image wise in the past because of some of the very things that make it great…easy accessibility/open source and mass adoption in recent years. Most notable is the idea that PHP coders are sloppy, and do not program to proper standards. While this is true to a certain degree, the same can be said of developers in other languages…proper standards are a result of learned style and direction, not a result of language. I shudder to think of some of the c and c++ code I’ve seen over the years.
If the arguments made in the book are well structured, the proposals well researched, then I’d think such an endeavour would stand a good chance of educating the naysayers regarding php’s elevation to Enterprise solutions. It’s certainly a direction worth exploring. Given the current views of those at the top, however, it would have to be pretty convincing.
With you at the helm, I’ve no doubt it will be.
Keep me apprised.
Thanks for you words of encouragement, Amadeus. I agree it’s an ambitious undertaking yet the payoff seems potentially huge to the community. Points well taken that you can poorly implement design methodologies for any language. That said, I think PHP has suffered most (and unnecessarily so) because it has gained so much popularity so quickly.
I would most likely also buy the book. My reason being it is good to have something at your disposal that an employee or a boss could read for futher knowledge when they are wanting to read about it.
Some of these issues and myths I would also like to address for myself. This is a great blog entry by the way.
PHP coders are sloppy
Anyone that has been a consultant or has seen some of the projects that are open sourced can see this. While not all of the coders are sloppy for the main part many programmers have the notion well if it works it is good enough.
While looking at that above phase you can quickly note that the security of these applications is in massive danger. Most of the time when I am looking at applications they are poorly designed with many SQL queries that could be using join statements, the filtering of data is a simple filter and not using a whitelist approach, and the data integrity is horrible.
I find many times that a complete rebuild of applications is needed and many developers if you point out these problems are ignorant and only willing to listen for a few moments before lodging those comments off into the distance.
PHP doesn’t scale
While this is a myth, much of the problem comes with the sloppy programmers from above. They can not see how to make it scale into what they need because they have not really taken the time to understand how to scale an application.
Scaling an application in PHP can be much harder than some other languages, but mostly this is just due to lazy programmers that do not take a look at "ok, how am I going to design this application?".
Much of the scaling can exist in an Object. PHP4 is quite easy for this. Create a logic layer consisting of the business logic into a set of classes. When you need to start scaling specific items extending the class is one of the best options. Then you can focus on the migration in steps instead of a whole.
PHP runs heavy
Depends on how you look at it. This for one is a very big myth. There are ways to make the application run extremely fast with very high performance. This is why implementing file caching and database caching is extremely important. There are also many other steps to tuning and speeding up an application and the php parser itself. But I wont go into those.
PHP doesn’t have a solid object model
PHP5 as you said addresses this, meanwhile php4 provides a nice layer for objects even without that vast amount of luggage that many object models contain.
There are certain things I like about the PHP4 object model that I normally pertain to write objects in unless PHP5 object model is highly needed.
PHP lacks vendor support
My first impression when I saw this was I laughed pretty hard. There are many big companies that are utilizing PHP now days. Zend is being our backbone of PHP and many companies are now utilizing the language.
Take a look a bigblue IBM
PHP packages are full of security flaws
Some of these are security flaws and some of them are features. This as you said is where a security audit is needed (normally internal). For this reason is because of what your company may see as a security risk some other companies may see it as a feature. (This is pertaining to the actual functions that are implemented). Many enterprises need to take a look at this. It also goes with don’t install what you are not going to use. That alone is a good start to making sure the packages are in the best state.
PHP doesn’t handle recursion well
Not exactly sure what you mean by well… I have never actually had a problem with recursion in PHP. This is when you should look at passing the variable by reference instead of a copy and also keeping your local recursion variable scope low. Performance is much better in this way.
PHP is open source, and therefore impossible to sell
Every company would love to save a few bucks here and there. Also by being open source it allows the company to research development quicker in the sense of extensions because there are many that they can look at the source code.
Also when you are looking at this, Zend now offers enterprise php so if they still want to spend a whole lot of money and feel safer… there is a solution
PHP can’t handle complex business logic
that is just funny!
PHP is not strongly typed
I consider this a feature not a why not.
By its being it allows for you to do much more than being restricted by how many other languages handle processing. While it may cause some hardships for people that are normally programming a certain way they can build there own layers and pretty much force there application to use certain control structures that you may have derived.
Its pretty much a preference, not a flaw
Some of these issues and myths I would also like to address for myself. This is a great blog entry by the way.
PHP coders are sloppy
Anyone that has been a consultant or has seen some of the projects that are open sourced can see this. While not all of the coders are sloppy for the main part many programmers have the notion well if it works it is good enough.
While looking at that above phase you can quickly note that the security of these applications is in massive danger. Most of the time when I am looking at applications they are poorly designed with many SQL queries that could be using join statements, the filtering of data is a simple filter and not using a whitelist approach, and the data integrity is horrible.
I find many times that a complete rebuild of applications is needed and many developers if you point out these problems are ignorant and only willing to listen for a few moments before lodging those comments off into the distance.
PHP doesn’t scale
While this is a myth, much of the problem comes with the sloppy programmers from above. They can not see how to make it scale into what they need because they have not really taken the time to understand how to scale an application.
Scaling an application in PHP can be much harder than some other languages, but mostly this is just due to lazy programmers that do not take a look at "ok, how am I going to design this application?".
Much of the scaling can exist in an Object. PHP4 is quite easy for this. Create a logic layer consisting of the business logic into a set of classes. When you need to start scaling specific items extending the class is one of the best options. Then you can focus on the migration in steps instead of a whole.
PHP runs heavy
Depends on how you look at it. This for one is a very big myth. There are ways to make the application run extremely fast with very high performance. This is why implementing file caching and database caching is extremely important. There are also many other steps to tuning and speeding up an application and the php parser itself. But I wont go into those.
PHP doesn’t have a solid object model
PHP5 as you said addresses this, meanwhile php4 provides a nice layer for objects even without that vast amount of luggage that many object models contain.
There are certain things I like about the PHP4 object model that I normally pertain to write objects in unless PHP5 object model is highly needed.
PHP lacks vendor support
My first impression when I saw this was I laughed pretty hard. There are many big companies that are utilizing PHP now days. Zend is being our backbone of PHP and many companies are now utilizing the language.
Take a look a bigblue IBM
PHP packages are full of security flaws
Some of these are security flaws and some of them are features. This as you said is where a security audit is needed (normally internal). For this reason is because of what your company may see as a security risk some other companies may see it as a feature. (This is pertaining to the actual functions that are implemented). Many enterprises need to take a look at this. It also goes with don’t install what you are not going to use. That alone is a good start to making sure the packages are in the best state.
PHP doesn’t handle recursion well
Not exactly sure what you mean by well… I have never actually had a problem with recursion in PHP. This is when you should look at passing the variable by reference instead of a copy and also keeping your local recursion variable scope low. Performance is much better in this way.
PHP is open source, and therefore impossible to sell
Every company would love to save a few bucks here and there. Also by being open source it allows the company to research development quicker in the sense of extensions because there are many that they can look at the source code.
Also when you are looking at this, Zend now offers enterprise php so if they still want to spend a whole lot of money and feel safer… there is a solution
PHP can’t handle complex business logic
that is just funny!PHP is not strongly typed
I consider this a feature not a why not.
By its being it allows for you to do much more than being restricted by how many other languages handle processing. While it may cause some hardships for people that are normally programming a certain way they can build there own layers and pretty much force there application to use certain control structures that you may have derived.
Its pretty much a preference, not a flaw
With regard to PHP code being sloppy - that is down to the programmer, not the language. I believe the only reason PHP suffers this more than most is down to the fact that it is web based (people want to get into this industry) and it’s the easiest to learn, so new programmers start with this.
I remember when I started programming (20 years ago) my code was sloppy as hell, it improves with experience. Hell, I’ve seen Perl code that is spaghetti, C++ code this is plain awful, even the proprietry language here where I work has suffered the same fate.
Blaming the language for sloppy code is plain wrong. This just goes back to the spectrum\commodore64, amiga\atari, directx\opengl, windows\unix argument. Some people have their preference and will knock the competition, regardless of fact.
I remember when I started programming (20 years ago) my code was sloppy as hell, it improves with experience. Hell, I’ve seen Perl code that is spaghetti, C++ code this is plain awful, even the proprietry language here where I work has suffered the same fate.
Blaming the language for sloppy code is plain wrong. This just goes back to the spectrum\commodore64, amiga\atari, directx\opengl, windows\unix argument. Some people have their preference and will knock the competition, regardless of fact.
For me, "Enterprise PHP" combines a number of things. Most are general
software development practices but may have specific application in PHP.
A list would be:
- Source code version control
- Unit testing / Test Driven Development
- Release management
- Pattens based development
- MVC framework
- Multiple tier/layer architecture
- Multiple server architecture
- Some sort of XP methodology for teams
It seems like if you had a handle on all of those as the related to PHP
that you would have a foundation on which to build enterprise web apps
in PHP.
Christopher
software development practices but may have specific application in PHP.
A list would be:
- Source code version control
- Unit testing / Test Driven Development
- Release management
- Pattens based development
- MVC framework
- Multiple tier/layer architecture
- Multiple server architecture
- Some sort of XP methodology for teams
It seems like if you had a handle on all of those as the related to PHP
that you would have a foundation on which to build enterprise web apps
in PHP.
Christopher
I think the reason PHP gets a bad rap is due to the image of sloppy programming, which seems to be a justified image. To me this is due to PHP being the first programming language many people learn, or at least the first one they use for anything outside of a programming class. I know this from experience.. my first PHP apps were (and still are since I haven’t refactored many of them) terrible. I’m still not a great coder, but I’m getting better all the time because I’m trying to learn how to do it right. I’m learning some J2EE and Ruby, along with using frameworks like Mojavi and ORM systems like Propel. These are definitely helping, but the more I learn the more I realize I should have just learned Java first, then learned PHP. My programs are looking more and more like Java anyway. I’m not saying Java is better or worse.. it’s just that it’s more mature and forces the coder to a stricter form, which can be transfered easily to PHP. But starting with embedding some PHP scripts in HTML pages and then trying to scale is the wrong direction to go. However, I must say that I might not have ever learned PHP at all if it would have taken the effort needed to learn a system as complicated as J2EE. PHP was appealing because it was easy to get going quickly. It’s been a rough road, but maybe this easy-to-cross barrier to entry is worth it, despite the drawbacks of the sloppy code that often come with it.
Reader Comments
Thea Swanson on "Road Sign on Interstate 5" Now Available Online
Thank you for writing this poem. It’s necessary. Peace+ Thea
(Read more...)
Katherine on What Marriage Means to Me
Beautiful. Thank you.
(Read more...)
michelle on "Road Sign on Interstate 5" Now Available Online
such a stunner. hey, you are good! xoxo, mich
(Read more...)