有人在plurk上PO了一篇文章的連結，PHP 開發迷思 (三) – PHP 很糟糕？，因為我不認同那樣的看法，所以我回覆說php很爛，當你說一個語言很爛時，就要有心理準備有人準備要跟你戰了，果然有人不認同我的說法，當然任何人都可以不認同我所說的，而且好和爛是很主觀的，同時也是是相對的，但是我所說的是有根據的，說php爛不是我一個人的說法，而是已經被說到爛掉的說法，很多比我有經驗多的網頁程式設計師都異口同聲的說PHP很爛，為了解釋為什麼我認為PHP很爛(我在本文指的爛是指語言設計上的眾多嚴重缺陷)，我寫了這篇文章

更新:

我承認這篇寫得有點偏激，也是以前的觀點，也是在發洩以前對PHP的不滿，我沒有寫較新的PHP，所以我收回PHP很爛，改成以前的PHP有很多缺陷，我想表達的是一款語言的很多缺陷，而且是在以前的缺陷，現在PHP確實有改進很多，所以我寫了一篇 如何評估比較程式語言

另外我想表達的一件事是，當有人說你用的程式語言有問題時，為什麼一定要這麼抓狂呢? 如果一個程式語言它的缺陷沒有人罵，大家都愛語言如命，那麼語言的開發者或團隊要如何知道這語言要改進什麼呢? PHP有很多缺陷是事實，然而說出來很多人可能就不高興，然而我選擇用較激烈的字眼是因為他改進實在太慢了，我們可以看到以前的Magic quote、unicode問題等等，至今都仍未解決，要php6才會解決，這些問題不是只有我覺得很糟，而是我發現很多人都跟我一樣覺得這太差了，我每次罵PHP都真的很希望他在下一個版本就把這些鳥問題解決掉，但以我之前的經驗它都讓我失望，所以我怨念很深，這篇文章寫起來也特別偏激，但我想表達的是，我說PHP爛某種程度是希望他變好，那你可能會問，我為什麼不說Python爛，然後哪裡爛，很簡單的原因是我太喜歡Python，當你很喜歡一個東西時你是看不見這東西的缺點，如果有人說Python爛，我覺得很好，我想知道他有哪些缺陷，是我沒看到的

除此之外，對於初學者來說，PHP的低門檻讓他成為吸引新手的蜜罐，而很多人都只知道PHP可以寫網頁，但是不知道其實所有程式語言都能寫網頁，我希望透過罵PHP也能讓更多人知道其實還有更多選擇，但其實這會讓人覺得反感，我在這背後目的是希望其它語言能夠有更多人使用，有競爭才有進步，而對於國內大部份人都只用PHP在刻網頁我也覺得很失望，我同時也希望讓大家知道其實網頁的技術現在已經很先進了，很少有人使用框架等次世代的網頁技術，所以有興趣也可以看一些較新的技術，而不是土法煉鋼

美與醜

當路上走來一個女的，一個人說她很正，另一個人說她很醜，美醜好壞基本上都是主觀的，而且是相對的，如果說走在路上的那個女生是世界上唯一的女生，那麼何從比較她的美醜呢? 我今天說PHP很爛，是基於我的經驗，和看別人的經驗，我有用不同的語言、工具寫過網頁程式，在這樣的情況下，因為經過比較才有辦法知道好壞，有趣的是在Plurk裡的討論有人甚至懷疑我沒寫過PHP，我個人比較喜歡就事論事，不太喜歡用質疑對方的立場來證明自己的說法，當別人懷疑你經歷時，你一樣可以這樣懷疑別人，像是「你們有沒有用非PHP的平台寫過網頁程式?」，「你們有沒有用現代一點的平台像是Django、ROR寫過網頁程式?」，但是這樣會讓問題失焦，到後來變成在檢視對方背景來決定他講這話是否是對的，而沒有去看這些話是否是真的正確或有道理，即使這是一個主觀的問題，而我描述的只是依我經驗和認知所得到的想法，每個人都可以不同意我所說的，但是那些確實是我所經歷過的，我可以說謊「天阿~ PHP好棒，大家快去學」，或是選擇不發言，但是當我說出「PHP很爛」，千真萬確是我的心得

我的經驗

我在小學六年級時家裡有了撥接的網路，在那時候開始學習怎麼寫網頁，當時所謂的網頁，也只是到處亂貼一些資料，整畫面閃來閃去的GIF圖檔，都是那時候新手網頁的調調，更誇張一點會加一堆亂七八糟的特效，上傳到免費的空間，我還記得當時申請的空間叫台北酒巴什麼的，當時真的覺得做網頁是件很酷的事情，在我學習寫程式之前其實大多都在做網頁，做破破爛爛的網頁，但是樂在其中，當時覺得程式真是很神奇的東西，有時會載一些用perl寫的cgi程式來架架看，光是架那些留言板或聊天室之類的，就是一件大工程，當時對於行末少一個;就沒辦法執行這件事覺得很驚訝，居然程式只要一個符號錯了就不能跑，那到底要怎麼寫?

當我上國一開始自己學寫VB6.0之後，因為有了VB6.0的程式設計經驗，我終於漸漸瞭解perl的cgi怎麼寫，這之中我記得我也有碰過ASP，因為他語法和VB一樣，但是並沒有太深入，後來因為我父親想弄一個放他文章的網站，於是我就用Perl-CGI幫他寫了一套文章管理系統，自己也順便做了一個個人工作室的網站

Victor工作室

我可以透過後台管理系統來新增消息，或是檔案下載等等，同時我也用Perl-CGI寫了一個留言版系統

Victor工作室 – 留言版 1.1 Beta

可以在這裡下載，在寫了這麼多Perl-CGI的程式後，發現PHP這東西好像漸漸流行起來，越來越多用PHP寫的網站、免費的網頁程式等等，在這之前幾乎都是Perl-CGI的天下，PHP做為後起之秀取而代之，因為他的門檻比Perl還低，同時比起Perl，PHP的程式也好懂許多，所以我也開始學習PHP，PHP絕對是當時最佳選擇之一，當之無愧，在寫的過程中有遇過不少問題，像是許功蓋問題，處理SQL Injection的問題，PHP的自動引號取代問題(Magic quote)，這些是顯著的問題，但有些問題在當時一直感覺不太對勁，但是也說不出個所以然，像是它的形別等等問題，相較於我當時所會的VB，PHP是一款非常不嚴僅的語言，但是我在當時並不覺得它很爛，可能是因為不知道有其它選擇，又或著當時真的沒什麼選擇，所以一邊學PHP，一邊我就把之前寫的文章系統改成用PHP重寫，到今天我父親還在使用這套系統:

金門根本文采工作室

在這之後有很長的時間，寫網頁我也都是用PHP，直到我學會了Python，大約已經是大二以後的事了，在那時我選擇了TurboGears當網頁框架，那時我回首過去，才深深地發現PHP是一款多麼爛的語言，在當時他或許是開路先鋒，讓網頁程式開發的門檻降低到一定的程度，但是在我學習寫TurboGears時他還是一樣的爛，以前我遇過的那些問題大多數都還在，而且學會了Python這種清晰的語言更加地覺得PHP真的很污穢，在那之後我用TurboGears開發了一些網頁，我以前在PHP遇到的鳥問題從來都沒有再碰到過，開發的速度也大大加快，我能夠專注在我所想開發的功能上，而不是整天去處理那些鳥問題，安全性也大大提升，目前那些網頁還在跑的有

Walele創意投票系統 是一個線上投票系統，從決定到開發完成上線只用了一週的課餘時間，用的是TurboGears1

Now.In廣播平台 是一個線上廣播平台，目前還在beta版的階段，用的是TurboGears2

試鏡報名系統 用一個晚上寫出來的試鏡報名系統，可以上傳照片，後面還有一個後台可以看資料

我承認我寫的網頁程式其實不多，但是從我第一個寫的網頁到今天已經有十年以上，我看見網路的發展，網頁開發工具的演進，PHP在以前我不會說他爛，因為他是開路先鋒，沒有他網頁程式設計可能難以上手，但是這麼多年來他有在改進，但是改進實在太慢，問題還是一大堆，再加上他改進的方式都是疊床架屋，而不是正視問題並解決它，再者相較於現代的網頁開發工具，PHP真的是太落伍了，先天不良，後天失調，所以今天我才說PHP很爛，即使PHP有了不少網頁框架，還是擺脫不他那語言本身就一堆問題的原罪，他之所以會大流行，回首當時，不外乎就是當時正好缺少一個低門檻的網頁開發工具、平台，PHP來得正是時候，所以大紅大紫，但是即使再怎麼流行也不能抹掉PHP語言設計很爛的這個事實

其它人的看法

我知道我說的可能很多人不認同，又或著不相信，但如果是大部份有接觸過現代網頁開發平台，很有經驗的網頁開發者都異口同聲的說php sucks呢? 在Google搜尋 『php sucks』，可以找到一大堆的網頁，他們都在說PHP很爛，我在此引用幾篇他們寫的

I’m sorry, but PHP sucks.

這篇文章清楚地條列出PHP哪裡爛，會遇到哪些麻煩的問題，像是字元支援的問題、不相容的問題、它莫名奇妙的形別系統等等

PHP Sucks, But It Doesn’t Matter

這篇文章引用其它人的說法，和他自己的經驗來說明PHP很爛，他這麼說道

I’ve written both VB and PHP code, and in my opinion the comparison is grossly unfair to Visual Basic. Does PHP suck? Of course it sucks. Did you read any of the links in Tim’s blog entry? It’s a galactic supernova of incomprehensibly colossal, mind-bendingly awful suck. If you sit down to program in PHP and have even an ounce of programming talent in your entire body, there’s no possible way to draw any other conclusion. It’s inescapable.

大略翻譯是:

PHP很爛? 當然它很爛，你有讀Tim部落格裡引用的每個連結嗎? 它真的是宇宙超級霹靂無敵的爛，就算你有一身寫PHP的才能，也沒辦法下任何其它的結論，這是事實

On PHP

這篇文章整理了一整一大堆資深的網頁程式開發人員，對於PHP的看法，大略挑幾句來翻譯

Adam Kalsey:

If you want some support on your foray into PHP, please let me know. I’d love to lend a hand. ¶

It’s easy to write bad code in PHP. Or in Perl. Or in C. Or Java. I think two things contribute to the perception that PHP code is crap. First of all, when you write spaghetti PHP, it still works just fine. So unless you’re a professional programmer or maintaining lots of code, you probably don’t care that the code is crap.

Secondly, since PHP is easy to learn, is ubiquitous, and there’s lots of PHP examples on the web, it’s easy for a non-pro to pick up PHP and start monkeying with it. They learn bad habits and then publish their code and teach others bad habits. Some of the most popular open source PHP applications ever are really poorly coded. Gallery and Wordpress come to mind.

A hammer can be used to build a beautiful structure or a mis-shapen birdhouse. And it’s easy to flatten your thumb. With so many amateur PHP developers out there, it’s not surprising there’s a lot of flat-thumb code in the wild.

大略翻譯:

如果你想學PHP，請讓我知道，我很樂意幫助你

PHP非常容易寫出很爛的程式碼，對Perl、C和Java來說也一樣，我想有兩件事情讓人對於PHP程式碼覺得很糟糕，首先，當你寫出了垃圾程式，它一樣運作的很好，除非你是專業的程式設計師，或是維護大量的程式碼，不然你根本不在意那程式碼是些垃圾。

第二，因為PHP很容易學，很普及，在網路上有很多PHP的範例，很容易就有非專業的人用PHP來亂搞，他們學習糟糕的習慣，然後發表他們的程式教其他人這些壞習慣，很多流行的Open source PHP程式也寫得非常爛，說到這裡就想到Gallery和Wordpress

它是一把可以建造漂亮結構或是歪曲鳥籠的槌子，還有它很容易敲爛你的姆指，有這麼多業餘的PHP開發者，所以在外面有這麼多爛程式也不令人意外

Dominic Mitchell
(略) Every time I’ve looked at PHP, I’ve been unable to find out how they use placeholders in code that talks to the database. Yes, every database adaptor provides a quote function, but nobody uses it (consistently). And people wonder why PHP code is always full of security holes.

It’s a real shame, as I can see that there’s a lot to like in PHP. But it really needs to clean its act up to appeal to people coming from other programming languages, instead of just people coming from dreamweaver.

I actually heard David Heinemeier Hansson (sp?) talking about rails the other day. One of the key points he made is that it should be easy to do the right thing. That’s why Rails hits a sweet spot for me. But when you look at PHP, yes, it’s easy to code, but it’s not easy to do the right thing. That’s where it falls down.

大略翻譯:

每次我看PHP的程式，都沒辦法找到他們怎樣在程式碼中用placeholders來和資料庫溝通，是的，所有資料庫介面都有提供過慮(quote 就是取代掉特殊符號)的函數，但是沒有人去用它 (一致的)，然後人們就很困惑為什麼PHP老是一堆安全性的漏洞

真的很丟臉，我看見很多人喜歡PHP，但是它需要向上提升才能吸引更多其它程式語言的開發者來使用，而不是那些從Dreamweaver跳槽過來的使用者

我前些天聽見David Heinemeier Hansson談到Rails (Ruby On Rails)，其中有個重點是他很容易把事情做對，那就是為什麼Rails能夠贏得我的歡心，但是反觀PHP，是的，他很容易寫，但是他不容易把事情做對，這就是他失敗的地方

What I don’t like about PHP

這裡面也提到並列出PHP的一些經典缺陷，像是namespace (雖然5.3版新增了，但是詭異的是用反斜線來做區分)，遞迴問題，Magic quote問題等等

PHP has two advantages: it’s very easy and it’s widely supported by webhosting companies. But that doesn’t make it a good language.

For very small projects, it can be a nice programming language. But for larger and more complex projects, PHP can show its weakness. When you search long enough, you’ll find solutions (work arounds) 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 an 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 might also consider C#/ASP.Net or Java/JSP as a better solution. And if you want really good (distributed) performance, you can look at some initiatives which have been popping up the last couple of years. Just to mention a couple of them: Nginx, Couch DB and Node.js. They all blow existing systems away.

大略翻譯

PHP有兩個優點，它非常容易使用，還有廣範地被webhosting公司支援，但是這並沒有使他成為一個好的語言

對所有的小專案來說，它可以是一個好的程式語言，但是對於大而且複雜的專案來說，PHP就顯得很弱，在你搜尋夠久時，你會發現部份這些提到的問題的解決方案，即然這些解決方案是已知的，為什麼這些問題沒有被解決? 還有為什麼這些修正沒有在手冊裡提到?

當一個open source的語言非常流行是一件好事，不幸的是他不是一個優良的語言，我希望所有問題都能一口氣被解決(在PHP6?)，這樣我們就會有一個好的open source語言

直到現在，當你開始一個大於五個script檔案的專案時，你可能會考慮C#/ASP.Net 或 Java/JSP做為更好的解決方案，還有如果你真的想要好的(分散式)效能，你可以看某些這幾年創新的解決方案，例如Nginx, Couch DB還有Node.js，他們會趕走現存的系統。

Experiences of Using PHP in Large Websites

這篇很詳細地從語言的層面說明PHP語言設計上到底有哪些缺陷

Furthermore, PHP suffers from a related issue: the language was accreted, rather than ever having been designed. Most programming languages that have achieved genuine long-lasting popularity have been the work of at most a small team of gifted language designers. These designers have worked as much on deciding what to leave out of their languages as on what to put in. PHP’s creator, Rasmus Lerdorf, adopted a deliberate policy of letting others contribute freely to the development of the PHP implementation — and thus implicitly to that of the language itself. Where languages like C, C++, or Perl have had a Ritchie, Stroustrup, or Wall directing their evolution, Lerdorf does not seem to have applied the same sorts of controls to PHP. The result in some cases is that PHP lacks any sort of coherent world view. This in turn only increases the complexity for those trying to actually build working solutions with PHP.

大略翻譯:

除此之外，PHP受苦於相關的問題: 這語言是拼湊出來而不是被設計出來的，大部份有名望的程式語言都是由小部份天才語言設計者所組成的團隊的作品，這些設計師做了很多語言的某些特性是否該保留或新增的決定，而PHP的建立者，Rasmus Lerdorf採用討論的機制讓其他人自由地開發PHP的實作，也就是PHP語言的本身，像C, C++或Perl有Ritchie, Stroustrup, or Wall等人指導他們的演進，Lerdorf似乎沒有對PHP採用同樣的控制，做為結果就是PHP缺少了一貫的世界觀，這只使得要在PHP上建立解決方案變得更加複雜

從這段我們可以瞭解，PHP的設計的決定很多在亂搞一通，它原本的作者也對程式語言的設計沒有才能

A similar problem crops up with relational operators. PHP’s simple variables can contain either a number or a string. PHP converts between numbers and strings whenever necessary, so that the programmer need not worry about the underlying type.

That’s the theory, anyway; in practice, this makes it extremely difficult to compare two values of different types for equality. The standard PHP equality-testing operator is spelled ==:

$n1 = 0;      $n2 = 10;
$s1 = ‘foo’;  $s2 = ‘bar’;

$n1 == $n2;  // Numeric comparison, returns false
$s1 == $s2;  // String comparison, returns false
$n1 == $s1;  // Good question
$s1 == $n1;  // Is this any different?

The problem is that, when the values are weakly typed, and there is only one equality-testing operator, the language cannot determine the programmer’s intention. PHP has a variety of kludges to deal with this:

* Some programmers recommend using !strcmp($n1, $s1) to force a string interpretation.
* You can cast one or both sides to the intended type.
* PHP 4 has a === operator. It works the same way as ==, except that it additionally requires both sides to have the same type. This sounds initially like the perfect solution — just use === wherever you would otherwise have used ==. Unfortunately, you lose the convenience of being able to treat numbers and strings interchangeably: it is no longer the case that 3 === 『3″.

Perl has similar rules for its scalar variables: they can contain either a number or a string, and the language freely converts as necessary. However, Perl allows the programmer to express the intent: it offers both a numeric-equality operator == and a string-equality operator eq. PHP explicitly rejects this approach. The manual for PHP 2 says “Once you start having separate operators for each type you start making the language much more complex. You can’t use == for strings, you now would use eq. I don’t see the point, especially for something like PHP where most of the scripts will be rather simple and in most cases written by non-programmers who want a language with a basic logical syntax that doesn’t have too high a learning curve.” Unfortunately, in cases like this, the complexity is rather like an air bubble under freshly hung wallpaper: pushing it from one place to another will only leave more mess on the wall.

大略翻譯:

一個類似的問題在關係運算子出現，PHP的簡單變數可以包含數字或字串，PHP在需要時轉形成數字或字串，所以程式設計師不需要擔心底層的形別

這只是理論，一般來說，這使比較兩個不同形別不同值是否相等變得極度的困難，標準的PHP相等測試運算為 ==:

$n1 = 0;      $n2 = 10;
$s1 = ‘foo’;  $s2 = ‘bar’;

$n1 == $n2;  // Numeric comparison, returns false
$s1 == $s2;  // String comparison, returns false
$n1 == $s1;  // Good question
$s1 == $n1;  // Is this any different?

問題在於，當值是weakly type，且只有一種相檔測式運算子，語言與法判斷程式設計師的意圖，PHP有很多暫時的解決方案:

* 有些程式設計師建議使用 !strcmp($n1, $s1)來強迫解釋成字串
* 你可以轉型兩邊成為想要的型別
* PHP4有一個 === 運算子，它運作和==一樣，除了他需要兩邊是同樣的類型，聽起來好像是完美的解決方案 – 只使用 ===在你使用 ==的地方，不幸的是你失去了數字和字串相容的方便性，再也不能使用 3 === 『3″

Perl有一個類似的規則給他的純量變數，他們可以包含一個數字或字串，語言可以自由的在需要的時候轉形，僅管如此Perl允許程式設計師表答他的意圖: 他提供了數字相等運算子 == 還有字串相等運算子 eq，PHP明確地拒絕這個方法，PHP2的手冊說到 『當你開始有兩種不同的運算子給不同的形別時，你開始讓語言變得更複雜，你無法對字串使用==，你要使用eq，我不瞭解這用意在哪裡，特別是對像PHP這種將會非常簡單的語言，且在大部份情況下，PHP都是由非程式設計師來寫，他們只是想寫基本邏輯語法而且不想要一個太高的學習曲線『，不幸的是，像這樣的情況，複雜的情況就像一個在璧紙後面隆起的泡泡，把它從這裡移到納裡只會把牆弄得更遭。

又一個業餘語言設計者在PHP所犯下的設計錯誤，而且程式語言也都設計在於討好初學者，而不是更嚴僅

說了PHP這麼多壞話，這還只是冰山一角，任何有上過資工系』程式語言』課程的人都能發現PHP這程式語言一堆不合理的設計/實作，但是PHP也不是完全不可取，在寫小形專案時他就很不錯，這文章寫得真的很不錯，他列出了一個檢查表，讓你檢查什麼情況適合使用PHP

We have identified a number of problems that arise when attempting to use PHP on large websites. However, we do not claim that PHP should never be used, only that these issues make its use inadvisable in certain circumstances. The following checklist suggests questions that should be considered before making a decision to use PHP for a given project.

*How much control will you have over the deployment platform? PHP’s one-size-fits-all approach to the php.ini file makes it hard to share servers with sites that were developed with different settings.
*How many people will work on the site, now and in the future? PHP as a language lacks the features necessary to promote effective teamwork; the bigger your team, the greater the problems you’ll have.
*How big will the site be, in terms of numbers of distinct pages? This is related to the previous item: the bigger the site, the greater your need will be for language features that promote teamwork.
*How long will the site be expected to last? The longer it lasts, the more likely it is that significant design changes will be needed. If you use PHP in the obvious manner, major design changes are difficult. If you extend PHP with a templating system, whether ad hoc or carefully enforced, using PHP buys you little if anything.

*How experienced are the developers; and how complex will the site need to be? Experienced developers will find themselves hindered rather than helped by the language’s simplicity. Inexperienced developers will find the simplicity a significant boon — but if you have inexperienced developers trying to develop a complicated dynamic site, you will soon run into other problems.

大略翻譯:

我們確認了不少用PHP寫大型網站會遇到的問題，但是我們不宣稱PHP永遠不該被使用，只是那些問題造成在現在的情況下不宜使用，但是下面這個檢查表建議了一些可以在決定使用PHP來開發專案前需要考量的問題

* 你對於你部署用的平台有多少控制權? PHP的設定檔php.ini的一次設定影響全部的方式使得要針對不同網站使用不同設定變得很困難

* 有多少人開發這個網站? 現在? 還有未來? PHP是一個缺乏必要特性來增進有效團隊合作的語言，當你的團隊越大，你會遇到越多問題

* 你的網站會有多大? 有幾個不同的頁面? 這關係到前一個項目，網站越大，你需要的語言特性就要越好來提升團隊的合作

* 你的網站會運行多久? 你的網站運行越久，越有可能需要進行設計上的重大改變，如果你使用PHP是因為明顯的意圖，主要的設計改變將會非常困難，如果你用樣版系統延伸PHP，不管是臨時或是特製的，使用PHP都沒帶來什麼好處

* 你有多少身為開發者的經驗; 還有網站將會有多複雜? 有經驗的開發者會發現他們因為語言的簡單受到阻礙而非幫助，沒經驗的開發者會發現簡單是一個重要的好處，但如果你有沒經驗的開發者來試圖開發一個複雜的動態網站，你很快會遇到其它問題

該文章作的結論是

PHP is a convenient language for rapidly prototyping simple dynamic websites. Websites thus built can in many cases be deployed indefinitely, without spending time and money on refactoring code in a different language. PHP’s simplicity makes it a good language for inexperienced programmers, such as those moving from a pure page-design rôle to a site development one.

For more experienced developers, though, the language’s simplicity rapidly turns into complexity, slowing down the development process. These developers are the ones who have the skills needed to build large and/or complex websites; using PHP for such sites therefore tends to be a net loss. This tendency is reinforced by PHP’s lack of the linguistic features needed to promote working on large software projects. If your project is at all large or complex, it may be better to look elsewhere when choosing an implementation language.

In cases where PHP has been determined to be inappropriate, what language should be used? There is considerable choice here; few languages are as bad as PHP for doing serious development work. The author and his colleagues have had good results with Perl, and believe that languages such as C++, Java, and Python should serve equally well.

大略翻譯:

PHP是一個用於快速開發簡單動態網站原形的語言，在沒有花錢和時間重構成不同的語言前，網站在很多情況下都不能被明確地部署，PHP的簡單使它成為一個給沒有經驗的程式設計者的好語言，像是一個單純從事頁面設計開發的人

對更多有經驗的開發者而言，語言的簡單很快的變成了複雜，減慢了開發的進度，這些開發者是有能力開發建置大形的複雜網站; 使用PHP在這樣的網站會傾向於成為平白的損失，這些傾向是來自於PHP缺乏對提升大形專案開發工作的語言特性，如果你的專案是大且複雜的，在選擇實做的語言之前最好去找其它的選擇

當PHP被認為不適合時，該使用什麼語言? 有很多選擇; 對於開發重要專案，很少有像PHP這麼糟糕的語言，作者和他的同事用Perl有好的結果，且相信像C++、Java還有Python可以有同樣好的結果

雖然從設計哲學看來我不喜歡Perl的哲學:

There’s more than one way to do it

而比較喜歡Python的

There should be one– and preferably only one –obvious way to do it.

但是做為一個程式語言，Perl的設計絕對比PHP好上太多了，PHP真的是拼湊出來的

PHP的問題

你可以在上面這些文章中發現，現在是2010年了，以現今的眼光來看，PHP確實是爛到暴炸了，有人反對我所說的，是說程式是人寫的，所以程式的好壞是在人而不是在程式語言本身，而且也有很多人有提到PHP可以寫出很棒的程式，這我也很認同，但是如同這些人也有提到的，要寫出優良的PHP程式非常困難，為什麼? 因為他有太多缺陷了，是的，不可否認他的門檻真的很低，但是那些缺陷就像是地雷一樣，而它的門檻就像是雷區的鐵絲網，讓大部份人可以跳進雷區來玩，不懂那些瑣碎的語言缺陷，很容易就被滿地的地雷炸飛，只有少數的人能夠熟知地雷的位置，在這雷區中行走自如，那是非常困難的事，換言之，PHP的學習曲線一開始是很平緩的，大部份人都可以快速上手寫出簡單的程式，但是當要寫的東西越來越複雜，要懂的東西就不是一般的多和瑣碎，因為那些問題都來自語言的設計不良，不瞭解就很容易誤用或濫用，所以到後來的學習曲線會很抖，而就算你懂也會那些問題，還有另一個疑問，為什麼要堅持用這個破爛而不知進步的爛語言? 而不改用一個更優良的語言或開發平台呢?

今天我會說他爛，有很大部份原因是因為我想讓大家瞭解，其實除了PHP以外還有很多網頁開發的平台，而和這些現代的網頁開發平台相較之下，單純用PHP開發網頁真的是宇宙超級霹靂無敵爛，拿框架比語言是很不公平，但是就算是比較語言本身，PHP一樣還是很爛，但是他也有他的優點，就是他非常流行，所以教學、資源、範例、現成的程式等等，都很豐富，而且門檻很低，進入地獄的低門檻，這樣的優勢能夠持續多久? PHP這麼流行，加上我們從上面看到引用的文章就知道，PHP改進的商討是笑話，一堆業餘的程式語言設計師在一起做出爛決定，很難做出痛改前非的重大且正確的改變，君不見PHP做出多少讓開發者罵到臭頭的爛決定，被罵了多少個版本才改回來，除非PHP真的改掉他那些壞毛病，不然如果想走向專業的話，我不建議學習PHP，但如果只是業餘和興趣，PHP真的是很不錯的玩具

說他爛的同時，我也希望他能夠變得更好，但是以我過往的經驗，PHP所謂的改善，總是讓人失望加憤怒，以最有名的例子Magic quote來說，我有一次發現我的PHP程式出問題，才知道原來是新版本的PHP會自動幫你escape引號，他的出發點是好意防止SQL Injection，但是欠缺深思熟慮，他這樣做使得既有的程式碼，正確地以mysql_escape之類函數來escape特殊符號的程式，需要特地寫workaround來解決此問題，再加上這樣的特性是可以設定改變的，所以你得花更多一點心力去判斷它是否有啟動Magic quote，這是在懲罰程式設計師，討好初學者，我不知道為什麼PHP社群會做出這樣令人傻眼的更新，不可否認地這樣做確實是救到了很多不懂得過慮 SQL Injection的新手，討好了新手，打了老手巴掌，但是卻開啟了更多問題，這類的改進方式，我記得在PHP的改進過程中遇過不少，都是令人傻眼的』改善』

替代的方案

現在其實已經有太多新的網頁技術可以使用，不管是哪一個，都比直接寫PHP來得好，但是缺點就是入門門檻比較高，目前資源比較少，又或著在國外資源很多，但是國內中文資源很少，如果要走向專業的話，絕對值得投資，以下列出一些我所知道的解決方案

TurboGears

集合各種Python最好的函式庫而成的網頁框架，可以說是集大成，它的特性是組件之間的藕合很鬆，所以可以換置組件，我個人就是使用TurboGears，他有一個有驚人的視訊影片，由TurboGears的作者親自示範如何在20分鐘裡寫出一個Wiki程式，有興趣可以下載來看看

20分鐘寫Wiki影片

知名的Open source網站Sourceforge.com就是用TurboGears2寫的，可以參考這篇文章

TurboGears on Sourceforge

Django

不同於TurboGears的集大成，Django所有組件都是量身打造的，因此他的藕合度比較高，但是因為原本就是商業用途，所以有較多的實際商用經驗

Ruby On Rails

基於Ruby語言的網頁框架，因為我不懂Ruby，所以不太熟這款框架，但我知道網路上有高手在24小時之內在八八風災期間寫出物資需求回報的網頁程式，開發效率也相當好

使用PHP的框架

有人說PHP也有優秀的框架，而且用框架比語言很不公平，所以我加了這條，使用PHP的框架能提升一定程度的生產力，雖然他減清了某些負擔，但是少有框架是完全不用寫程式的，當你需要自己寫PHP的程式部份時還是得面對語言缺陷，以下是知名的PHP網頁框架

Symfony

Zend framework

CakePHP

成功的例子

當然你聽到這些莫生的名詞，可能會懷疑這樣的東西真的可行嗎? 就像我當初的疑問一樣，但是現在已經有越來越多的網站往這些新世代的網頁以這些新的技術為基礎，或是舊的網站改用新的技術重新寫過，舉幾個我所知道以Python為語言的網站有這些

Plurk

Youtube

Sourceforge

Reddit

Justin.tv (用的是Twisted)

最後

我知道我講的這些可能聽起來很刺耳，但是確實是我所見所聞，你可以不認同我所說的，反駁我所說的，只要是理性的討論都歡迎並且尊重，請勿進行人身攻擊，還有我想知道有沒有用過現代的網頁技術，回頭去看PHP覺得是很好的，我也希望能瞭解這樣的想法

更新:

• 2010/1/7 強調PHP爛在語言設計，拿掉一些太偏頗的比較(語言和框架)，和增加另兩個網站連結，以及PHP的框架，還有增加PHP腦殘設計決定和checklist的翻譯

• Previous Entry: 以嵌入式系統實作擴增實境導航系統
• Next Entry: 如何評估比較程式語言