|
|
原文：http://www.bitstorm.org/edwin/en/php-sucks/
Why PHP sucks (for large systems)
Edwin Martin <edwin@bitstorm.org>.
Published: August 6, 2004, Last update October 9, 2004.
I have been developing in PHP for four years now. PHP is very easy to program in. But PHP also has some serious weaknesses.
Below I give some reasons why PHP is not suited for anything larger than a small hobby website.
1. Bad recursion support
Recursion is the mechanism in which a function calls itself. This is a powerful feature which can make something complex something simple. An example of a function using recursion is quicksort. Unfortunately, PHP is not good at recursion. Zeev, one or the developers of PHP, says this: " HP 4.0 (Zend) uses the stack for intensive data, rather than using the heap. That means that its tolerance recursive functions is significantly lower than that of other languages." See bug 1901. This is a poor excuse. Every programming language should provide good recursion support.
2. Many PHP-modules are not thread safe
A couple of years ago, Apache released version 2.0 of its web server. This version supports multithreaded mode, in which one piece of software can run multiple times simultaneously. The makers of PHP say that the core of PHP is thread safe, only the non-core modules often aren't. But nine out of ten times, you do want to use such a module in your PHP-script, making your script unsuitable for Apache's multithreaded mode. The bad multithreaded mode support of PHP is often seen as the reason Apache 2 still didn't caught on.
Read the discussion about this on Slashdot: Sites Rejecting Apache 2?.
3. PHP is crippled for commercial reasons
The performance of PHP can be increased to 500% by using caching [benchmarks]. So why is caching not
build into PHP? Because Zend, the maker of PHP is selling its own Zend Accelerator and of course, they don't want to cannibalize on there own commercial products.
But there is an alternative: APC.
4. No namespaces
Suppose someone creates a PHP-module that can read files. One of the functions in this module is called read. And someone else's module can read web pages and also contains a function read. Then it is impossible to use these modules together because PHP will not know which read function you want.
An easy solution to this is namespaces. It was a suggested feature for PHP 5, but unfortunately it didn't make it. Now, without namespaces, every function has to be prefixed with the module name, to prevent name collisions. This leads to terrible long function names like xsl_xsltprocessor_transform_to_xml which makes code harder to write and read.
5. Non-standard date format characters
Many programmers are familiar with the date format characters known from UNIX and the C programming language. Other programming languages adopted this standard, but strangely enough, PHP has its own, completely incompatible date format characters. While in C, "%j" stands for the day of the year, in PHP this stands for the day of the month. To make things even more confusing: the function strftime and the date_format of Smarty, a PHP templating engine, do use the C/UNIX format characters.
6. Confusing licenses
You might think PHP is free and all PHP-modules in the manual are free too. Wrong. For example, if you want to generate a PDF-file from PHP you will find two modules in the manual: PDF or ClibPDF. But both come with commercial licenses. So for every module you use, you have to make sure you agree with its license.
7. Inconsequent function naming convention
Some function names consist of more than one word. There are three conventions for combining these words:
1. Glued together: getnumberoffiles
2. Separated with underscores: get_number_of_files
3. Camel case: getNumberOfFiles
Most Languages chooses one of these variants. PHP uses all of them.
For example, it you want to convert special characters to HTML entities, you use the function htmlentities (Words glued together). If you want to do the opposite, you use its little brother function html_entity_decode. For some reason the words are now separated by underscores. Why is this bad? You know there is a function named strpad. Or was it str_pad? Every time you have to look up what the notation is or wait for an error to occur. Functions are case insensitive, so for PHP there is no difference between rawurldecode and RawUrlDecode. This is bad too, because both are used and because they look different, they will confuse the reader.
8. Magic quotes hell
Magic quotes prevents PHP-scripts from SQL injection attacks. That's okay. But for some reason, you can turn this off in the php.ini configuration file. So if you want to write a portable script, you always have to check whether magic quotes is turned on or off. So a "feature" to make programming easier, actually makes it more complex.
Conclusion
For very small projects, it can be a nice programming language. But for larger and more complex projects, PHP will show its weakness. When you search long enough, you'll find solutions to some of the mentioned problems. So when a solution is known, why isn't it fixed? And why are the fixes not mentioned in the manual?
It's good that a open source language is very populair. Unfortunately, it's not a great language. I hope all problems will be solved once (in PHP 6?) and we will have an open source language that's open source and good.
Until then, when you start a project larger than five scripted pages, you'll better consider C#/ASP.Net or Java/JSP or maybe even Python as a better solution.
After I wrote this page, some people informed me about other, similar pages:
* Experiences of Using PHP in Large Websites
* "HP in contrast to Perl"
* I hate PHP
* PHP: A love and hate relationship
* PHP Annoyances |
|
IP卡
狗仔卡
发表于 2005-5-31 13:53:11
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
显身卡
发表于 2005-6-1 23:02:34