我的PHP很爛，這點沒什麼好說的，我承認，因為我也不寫PHP了，以前的程式也是N年前寫的，我現在回頭看以前任何寫的一個程式都覺得我寫得很爛，因為我覺得我現在可以把它寫得更好，只是它運作好好的我沒理由去改它，你就算說我Python很爛，C/C++語言很爛，什麼都好，我也不會因此而生氣，請便

你寫什麼和你用什麼是兩回事，你不喜歡寫組語，難道你就不用用組語寫出來的os嗎? 你不喜歡c/c++，難道你就不用用它們寫出來的程式嗎? 不要把使用和寫混為一談

我用PHP寫的wordpress，我不必改他的程式碼，他裡面寫再怎麼髒、再怎麼爛都與我無關，反正我又沒有要維護他

還有，易用性和什麼程式語言寫出來的一點關係都沒有，也不要混為一談，你有聽過C/C++或是Java寫出來的程式可用性比較好這種愚蠢的說法嗎? 我想沒有吧? 我真的完全想不出來一個程式對於使用者來說好不好用，和語言有什麼樣的關係，但是一個語言好不好，對開發它或維護他的人就關係大了….

我想你可能跟本搞不清楚"使用"和"維護、開發"是兩回事吧?

很高兴关注到Python ;-)
这几句禅是大家一致要理解的命题!

1.
我不知道你是不是有誤會，又或著我誤會你想說的，那是指人去讀，不是系統去讀

首先，在寫程式的過程中，其實我們就一直在重覆的讀程式，在debug的過程也是在讀程式，請仔細回想寫程式的過程，真正花在"寫"的時間有多少? 次數又有多少? 相較於讀，讀是不段地發生，你在改bug時眼睛是一直盯著程式碼看，要在裡面找出問題，trace時也是，而寫只有把你想法轉成程式碼打出來的那時才發生，所以程式碼被讀比被寫多，我想答案應該很清楚

這還只是單人寫程式，如果是多人呢? 像是雙人合作的模式，又或著團隊的開發，程式碼不是寫完就沒事了，嚴僅的做法應該是還得被review，程式碼沒review，你怎麼知道團隊中的某個人是否在裡面加了某些料? 又或著他寫的程式真的有符合標準嗎? 在這些過程中都是大量的閱讀

接著，就是維護，當你要改一個人的程式碼時，你不懂他的程式碼是無法修改的，要不看一個人的程式能進行修改，我想情況大概只有那個人的程式都有經過良好的封裝、設計、寫文件等等，以oo的原則來說，open-closed原則來看，真的能做到的話，只要看他對外的介面文件之類的不用動到原本的部份就能修改，但是那樣完美的程式碼不存在，因此多少會有需要修改到原本程式碼的部份，這時如果你讀不懂他的程式，可能只有一個選擇就是重寫

所以，以上這些就是程式碼被讀比被寫來得多的道理

2.
是的，那個程式寫得很不錯，有不少註解，但是也有不少沒有註解的地方，我有說過即使那些是相對客觀的條件，但是也是有主觀的成份，而且其實那樣是可以統計的

如你所說的，我們可以找100個讀外文系的人，100個寫C/C++的人，100個寫Python的人，100寫Perl的人，分別讀兩份perl和python寫的程式然後做選擇題回答這程式的相關問題，例如某段程式是在做什麼的，在這樣的情況下有數據我們就可以更客觀的知道不同人對不同語言可讀性的好壞感覺

我覺得這倒不是喜歡和不喜歡的問題，可讀性好，不管你喜不喜歡都容易讀懂，就像假設一個人討厭國文課他就讀不懂國文嗎? 不見得吧?

好的可讀性應該是要顯而易見，perl對我而言最大的問題不在於它的語法，而是記憶的問題，請問$$ $% $^ $&那麼多種特別的符號你能記下多少種? 因為他和我們用的語言一點關聯、甚至是暗示都沒有，連猜的機會都沒有，需要靠純脆的記憶或是查資料來得知，當你要查的資料越多，這不是表示可讀性比較差嗎? 你讀的過程中一直需要停下來查語法

還有語法太多也是個問題，像<>讀檔、`ls`是執行system的指令，~= /xxx/ 是regular expression的比對，還有很多鎖碎的語法，對我來說，每種功能都是語法，第一次看見這些語法，甚至看了好幾次，我還是得查手冊才知道這是在做什麼的，因為難以記憶，而且語法的手冊特別難查，不像是函式庫是英文字詞，你搜尋也難以搜尋，所以就算同樣是查資料，perl也會比較吃力，因為像你在google搜尋 perl <> 找不到相關的資料….
但我搜尋 perl readline 可以找到

總合以上種種原因我做出perl可讀性較差的判斷，你可能不認同我所說的，那我再舉一個例子，就是我們熟知的ip和domain name

111.168.1.34這樣的數字，對人類一點意義都沒有，你讀了也沒辦法猜出這個網站是在幹麻，也難以記憶，但是domain name就不一樣了，他是有意義的東西組成，除了好記也能猜，像是www.sex.com，這樣再明白也不過了

Perl的情況就像是一堆功能全是ip數字，難以記憶和猜想、理解，它把太多功能做成語法了，我認為那些本來都應該做成函式庫的，所以造成難以閱讀

3.
我想表達的是，Perl的寫法那樣並不能從寫的東西看出任何暗示，因為他放太多功能到語法上面了，$|是什麼意思在查手冊前不知道，但是如果是函數名稱就很容易猜，如果他有良好命名的話，當然，你會說，perl也能定義那樣的函數，問題是perl沒有，而大部份的perl程式都大量依賴$| $% $^那類特別變數的操作來完成某些目的，所以如果perl和python同時不寫註解，絕對會是perl比較難以理解，因為python沒像perl那樣多的語法，它只有完備的核心語法的功能，該是library的東西就是library，而perl對我來說，我覺得他太貪心了，把一堆東西都做成語法，暗示、字詞的意義全被拿掉了，只剩符號，無從猜起和難以記憶，那是我那段想表達的

4.
關於這點，我把哲學放在主觀的分類裡，就是這個原因，後面雖然我說我比較喜歡Python的哲學，但是不代表Python的哲學就比較好，因為即然是哲學和思想，本來就難以有對錯好壞之分，要看每個人的想法是否和那個一至

我也同意你說的Perl語言本身沒有太大缺陷，我上一篇文章裡面就有人有提到，eq和==是分別的判斷運算子，因此可以分清楚程式設計師的用意，perl以語言的設計層面很完善，只是和Python的哲學不同，當這部份來到哲學層面的話，除非能證明對方的哲學是錯的或是有問題的，否則也只能陷於無限的爭論

所以對於Perl的哲學雖然我不喜歡，但是我沒說他錯，那是不同的想法

1. 「程式被讀比被寫還多次」?!
程式只有系統在執行時會去讀，寫得人繼續寫他的程式。那讀比寫還多的原因是什麼? 維護又是要維護什麼?

2. 「可讀性很明顯地Python優於Perl」該由誰來評斷? 寫 Perl 的人? 寫 Python 的人? 讀中文系的人? 讀外文系的人? 其它人?
碰巧我就是用 Perl 在寫程式的，Perl 的程式中運用了很多符號，這是 Perl 的特點，可以加快寫程式的速度，喜歡的人就會喜歡，不喜歡的人就不喜歡，要讀得懂當然要先熟悉 Perl，我想任何語言皆同。
你舉的例子我反而覺得 Perl 寫得很好，重點是「註解」寫得很清楚，這才是最重要的。你不也是看著他的註解才寫出程式的?!

3. 拿 Perl 的 "$| = 1;" 跟 Python 的 "disableBuffering()" 來比較也怪怪的!
你既不懂 "$| = 1;" 的原意是什麼，而 Python 也沒有 "disableBuffering()"，那你到底在比較什麼?
原 Perl 的作者如果願意，也可以定義一個函式叫 disableBuffering() 內容就只有一行 "$| = 1;" 不是嗎?

4. 批評 Perl 的人常說「一百個人可能就會寫出一百種不同的程式」?!事實並不會這樣，Perl 只是某些語法可以簡化、倒裝句…允許有不同的寫法而已，懂 Perl 的人還是看得懂。
而 Perl 這語言本身沒有什麼太大的缺陷，純粹是你不喜歡而已，Python 的「嚴謹度」或 Perl 的「自由度」，我覺得是沒什麼好比的。而「There’s more than one way to do it」，真實的世界就是這樣。

我會這樣認為，做為低門檻的程式語言，理應當盡力避免容易爁用的特性

goto的問題是源自於以前的程式語言，很多都是用goto在寫的，寫出所謂義大利麵程式，一個程式任何地方都可能是進入點，任何地方都可能是離開點，那樣會使得程式難以除錯，和維護，所以後來有人證明了，單一入口和單一出口的結構化程式設計可以完全取代goto

基本上你這個例子完全沒有使用goto的必要，可讀性和可寫性並沒有因此而改善多少，你需要的是好的風格排版，讓那個if看起來更清楚

真正會需比較需要goto的情況是多層迴圈，要從裡面跳出來如果不用goto就需要較多變數和判斷，但是有人這麼認為，當你的迴圈層數多到一定程度時就表示你該重構了，甚至有人認為迴圈最多不應該超過兩層，我個人認為到了三層程式就開是難以理解，四層就太超過了

即然我們不需要這麼多層的迴圈，那麼為什麼我們需要goto? 增加語法是好是壞，如果PHP只是為了討好其它語言的使用者，像是C/C++，而認為該加goto，那麼我會認為這實在很糟糕，PHP很多決定都只是為了討好不同族群的使用者，把他們拉進來後，然後呢? 我想PHP少了一個設計的哲學思想，或許是我不知道，有沒有人可以告訴我PHP背後的哲學和思想是什麼?