posted by shiningray on april 3rd, 2006

edwin martin <[email protected]>.

翻譯：shiningray @ nirvana studio

我在過去的四年里一直致力于php應用的開發。php確實十分容易編寫。但是php也有一些十分嚴重的缺陷。

下面我會給出我的理由，為什么php不適合于比小型業余網站更大的網站。

1. 對遞歸的不良支持
遞歸是一種函數調用自身的機制。這是一種強大的特性可以把某些復雜的東西變得很簡單。有一個使用遞歸的例子是快速排序（quicksort）。不幸的是，php并不擅長遞歸。zeev，一個php開發人員，說道：“php 4.0（zend）對密集數據使用了棧方式，而不是使用堆方式。也就是說它能容忍的遞歸函數的數量限制和其他語言比起來明顯少。”見bug 1901。這是一個很不好的借口。每一個編程語言都應該提供良好的遞歸支持。

2. 許多php模塊都不是線程安全的
在幾年前，apache發布了web服務器的2.0版。這個版本支持多線程模式，在這個模式下，軟件一個一部分可以同時運行多個。php的發明者說php的核心是線程安全的，但是非核心模塊不一定是。但是十次有九次，你想要在php腳本中使用這種模塊，但這又使你的腳本不能合適apache的多線程模式。這也是為什么php小組不推薦在apache 2 的多線程模式下運行php。不良的多線程模式支持使php常被認為是apache 2依然不流行的原因之一。

請閱讀這篇討論： slashdot: sites rejecting apache 2?.

3. php 由于商業原因而不健全
通過使用緩存，php的性能可以陡增500%[見基準測試]。那么為什么緩存沒有被構建在php中呢？因為zend——php的制造者，它在銷售自己的zend accelerator，所以當然，他們不想拋棄自己的商業產品這塊肥肉。

但是有另一個可選擇的： apc. （zend后來推出zend optimizer，免費的加速器——譯者）

4. 沒有命名空間
設想某個人制作了一個php模塊用來閱讀文件。模塊中一個函數叫做read。然后另一個人的模塊可以讀取網頁的，同樣包含一個函數read。然后我們就無法同時使用這兩個模塊了，因為php不知道你要用哪個函數。

但是有一個很簡單的解決方法，那就是命名空間。曾經有人建議php5加入這個特性，但不幸得是他沒有這么做?，F在，沒有命名空間，每個函數都必須加上模塊名作為前綴，來避免名稱沖突。這導致了函數名恐怖得長，例如xsl_xsltprocessor_transform_to_xml讓代碼難于書寫和理解。

5. 不標準的日期格式字符
很多程序員對 日期格式字符 都很熟悉，它是從unix和c語言中來的。其他一些編程語言采用了這個標準，但是很奇怪的，php有它自己的一套完全不兼容的日期格式字符。在c中，“%j”表示一年中的當天，在php中他表示一個月中的當天。然而使事情更混亂的是：smarty （一個很流行的php模版引擎）的 strftime 函數和 date_format 函數，卻使用了c/unix的格式化字符。

6. 混亂的許可證
你也許認為php是免費的，所有的在手冊中提到的php模塊也是免費的。錯了！例如，如果你想在php中生成pdf文件，你會在手冊中發現兩個模塊：pdf 和 clibpdf。但是這兩個都是有商業許可證的。所以，你所使用的每個模塊，你都要確保你同意他的許可證。

7. 不一致的函數命名規則
有些函數名稱是有多個單詞組成的。一般有三種單詞組合的習慣：

直接拼接：getnumberoffiles
用下劃線分開：get_number_of_files
駱駝法則：getnumberoffiles
大部分語言選擇其中一中。但是php都用到了。

例如，你想要把一些特殊字符轉換成html實體，你會使用函數htmlentities （直接拼接單詞）。如果你要使用相反的功能，你要用到它的小弟弟html_entity_decode。由于某些特殊的原因，這個函數名是由下劃線分隔單詞。怎么能這樣呢？你知道有一個函數叫strpad?；蛘咚莝tr_pad？每次你都要查看一下到底這個符號是什么或者直接等他出現一個錯誤。函數是不分大小寫的，所以對于php來說rawurldecode 和rawurldecode之間沒有什么區別。這也很糟糕，因為兩個都使用到了同時他們看上去還不一樣，混淆了閱讀者。

8. 魔法引用的地獄
魔法引用（magic quote）可以保護php腳本免受sql注入攻擊。這很好。但是出于某些原因，你可以在php.ini中關閉這個配置。所以你如果要寫出一個有彈性的腳本，你總要檢查魔法引用是開啟還是關閉。這樣一個“特性”應該讓編程更簡單，而事實上變得更復雜了。

9. 缺少標準框架
一個成長中的網站沒有一個整體框架，最終會變成維護的噩夢。一個框架可以讓很多工作變得簡單?，F在最流行的框架模型時mvc-模型，在其中表現層、業務邏輯和數據庫訪問都分離開了。

很多php網站不使用mvc-模型。他們甚至沒有一個框架。甚至現在有一些php框架同時你都可以自己寫一個，關于php的文章和手冊沒有提高框架的一個字。同時jsp-開發人員使用像struts的框架、asp開發人員使用.net，看起來好像這些概念都廣泛被php開發人員所了解。這就說明了php實際上到底是多專業。

總結
 
什么問題?

對于非常小的項目，它可以是一個十分符合人意的編程語言。但是對于較大的和更為復雜的項目，php就顯出他的薄弱了。當你不斷地摸索之后，你會發現我提到的某些問題的解決方案。所以，當解決方案已知之后，為什么不能修正他呢？另外為什么這些修補不在手冊中提到呢？

一個開源的語言十分流行是一件好事。但不幸得是，它不是一個偉大的語言。我希望所有的問題能有一天得到解決（也許在php6？），然后我們就將擁有一個開源語言，他既開源，又好用。

到現在，當你要啟動一個多于5個腳本頁面的項目的時候，你最好考慮c#/asp.net 或者 java/jsp或者也許python同樣是一個更好的選擇。