重寫Reddit
英文原文：Rewriting Reddit
2012 年注：本文首發于 2005 年。發布之后，Django 上線了一個 RemovingTheMagic 項目，提出了我的一些質疑（盡管我本人發現它仍然不可用），web.py 促進了 FriendFeed 的 tornado.web 和 Google 的 gae.webapp 以及其它項目（盡管如此我仍然喜歡 web.py），本文引起了 Reddit 流量的永久井噴，仍然沒有真正地停止增長。
</blockquote>在 reddit.com 過去的一周里，我們用 Python 代替 Lisp 重寫了網站。這周我們做了很多工作（透露：我們使用了我開發的 web.py 類庫）。其他人熟悉 Lisp（整個站點用它編寫），他們喜歡 Python（他們用它重寫了整個站點），然而他們決定，在這個項目中喜歡 Python 多一些。Python 版本的網站需要更少的代碼，運行更快、代碼更容易閱讀和維護。
根據在 reddit 博客上的評論，比 Lisp 更好的東東的想法，表面上對一些人是不可思議的。Lisp 愛好者們很快著手盡量找到變換語言背后的真正原因。
有人認為這里面一定有不同尋常的干預，由于“貌似沒有切換到低等語言的其它原因。”又有人覺得其它事情必須在發生著：“這會是……一個謊言？扔 掉競爭力？貌似 Paul Graham 沒有在他的文章里暗示這個策略呀……”還有人附和道：“我認為這是惡作劇。”也有人提出，作者只是想更多地“走捷徑、hack 和偽裝手法。”
當然，它們都是極端的情況。其它人猜測一定有來自外部的壓力。“我猜，要么是類庫，要么是雇傭新員工。”有人總結到：“一些投資商想要任何程序員都能維護的產品。我希望他給你支付了好多錢。”
Lisp 新聞組 comp.lang.lisp 對于這次切換感到失望，他們為了表明自己是多么地正確，最近正計劃把 reddit 寫成 Lisp 的一個競爭者。
這些說法當中，稍微中肯的提到 Lisp 的價值在于能夠創建新的語言結構， 這對于簡單的 web 應用程序而言，是不必要的，因為結構已經被建好了。不過，這也不是真實的。web.py 完全從零起步，用到了各種“新的語言結構”（linguistic constructs）——甚至更好——這些結構具有語法，讓它們具有合理的可讀性。當然，Python 不是 Perl 6，因此你不能增加任意語法，不過你經常能夠找到把事情搞定的聰明方法。
另一方面，Python 有它自己的問題。最大的問題在于它有很多 web 應用程序框架，但是都不太好。Python 愛好者只是注意到了第一句，而明顯忽視了第二句，因為當我告訴他們我正在用自己的類庫時，通常的反應是“我認為 Python 不需要另一個 web 應用程序框架”。是的，Python 需要更少的 web 應用程序框架，但是它也需要不是太糟糕的框架。
貌似最有前途的框架就是 Django 了，我們最初的確想用它重寫 reddit。做為有經驗的 Python 程序員，我盡量幫助其他人解脫出來。
從外面看 Django 貌似優秀：良好外觀的網站、極具才能和天賦的開發者，表面過剩的、優秀功能。開發者和社區是非常有幫助的，也對補丁和建議作出響應。所有正確的目標都在他們的哲學文檔和 FAQ 得以支持。然而不幸的是，它們好像完全沒有達到自己的期望。
Django 聲稱它是“松耦合”的，卻要求你的代碼符合 Django 的風格。Django 堅持你的代碼執行本身，或是通過命令行工具，或是借助正確的環境變量和 Python 路徑做特定的服務器處理程序調用。當你開始項目時，Django 默認為代碼生成了嵌套四層的文件夾，而你能夠移動一些文件，我在搞清楚移動哪一個以及如何移動上遇到了麻煩。
Django 的哲學是“明確優于隱式”，但是它卻有各種魔法。你在一個文件創建的數據庫模型，神奇地出現在有著不同名字的 Django 模塊內部的某個地方。當模型功能被調用時，新東東被添到了它的變量里，舊的數據被移除了。（我被告知，他們目前正在修復這兩個問題。）
Django 的另一個目標是“較少的代碼”，至少對你而言。但是 Django 卻充滿了代碼。在 Django 里有 10 個不同的文件夾、而每個文件夾內部又有一些文件夾。當你根據 Django 教程開始實際地建立網站時，你已經導入了 django.core.meta, django.models.polls，django.conf.urls.defaults.*，django.utils.httpwrappers.HttpResponse 和 django.core.extensions.render_to_response。任何人應當記住它們，不是明確的，尤其是好像沒有原理或如何命名 的指導原則。上面的三個模塊被開始的腳本自動插入了，但是你仍然需要為你想使用的每個函數記住這些名字。
不過，Django 最重要的問題在于，它的開發者貌似未能設計出得體的 API。他們肯定是有能力的 Python 程序員——他們的代碼用到了各種奇怪的手法。他們肯定能寫出可運行的代碼——它們有各種有趣的功能。但是，他們好像不能把代碼構造成其他人可用的方式。
他們的 API 是丑陋的，定期地丟失重要功能：數據庫 API 通過計算下劃線來構造查詢，但是沒有專門的語法來處理 JOIN，模板系統需要 4 個大括號包圍每個變量，卻不能做任意種類的計算，表單 API 需要 15 行來處理表單，卻不能自動生成模板。
我盡力修復這些問題了——Django 社區相當支持——但是任務讓我退縮了。我只是精神上做不到，更不要說不得不為我自己的創業去實際開發自己的應用程序的、時間限制。
因此，Lisp 和 Django 是不足的，我們帶著 web.py 離開了。我想說，web.py 認識到了這些錯誤，在設計的時候就避免了它們，不過真相是，web.py 在出現這些問題之前已經被編寫了，并設法避免了它們。
我寫 web.py 的方式是簡單的：我想象著事情應該如何運行，然后我讓它們成為現實。有時候讓它運行需要很多代碼。有時候它只需要一點兒代碼。但是不管怎樣，這些事實對于用戶是不可見的——它們只需要完美的 API。
那么應該如何運行呢？第一個原則是，代碼應該清晰簡單。如果你想輸出文本，你就調用 web.output。如果你想得到表單輸入，你就調用 web.input。沒有特別難記的東東。
第二個原則，web.py 應該適合你的代碼，而不是其它方式。web.py 里的每個函數都是完全獨立的，你想用哪個就用哪個。你可以把文件隨意放在任何地方，web.py 樂于定位到它。如果你想把一塊代碼做為 web 應用程序運行，你可以調用 web.run，你不要把代碼放在不可思議的地方，讓 web.py 運行。
第三個原則是，web.py 默認應該做 web 所認為的正確的事情。這意味著正確地區分 GET 和 POST。它代表了簡單、同一性會跳轉到標準鏈接。它代表了含有正確 HTTP 頭的、可讀的 HTML。
我所擔心的是，有太多你需要的原則。它們對我來說，好像非常簡單和明顯，甚至我樂意篡改它們，但是其它 Python 的 web 應用程序框架卻沒有和它比肩的。（如果你知道有，請告訴我，我樂于收回上面的話。我想不是這樣的。）在此之前，貌似我被迫做了一件本不愿意做的、可怕的事 情：向世界又提交了一個 Python web 應用程序框架。
來自: www.labazhou.net<span id="shareA4" class="fl"> </span>本文由用戶 jopen 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！