為何編程如此之難？Erlang 之父的感觸
【導讀】：作為程序員，你會如何跟非程序員解釋寫程序不容易這件事?為啥看不見摸不著的程序需要花時間去寫去維護?很多人其實都沒想明白。來看看 Erlang 之父 Joe Armstrong 的感觸。
編程為什么這么難?
多年前我曾一度認為編程很簡單，然而隨著歲月的流逝，我終于意識到編程并不是件容易的事。這是因為，我所認為的「究竟什么是編程」和「程序員到底是做什么的」，在感知上已經漸漸地發生了轉變。
定義1：所謂程序就是一種把輸入轉化為輸出的東西，程序員就是寫程序的人，編程就是寫程序的這個行為;
現在讓我們給我對程序的這個定義加一些約束吧。
定義2： 所謂程序就是在遵從下列約束的條件下，把一些輸入轉化為輸出的東西。
- 程序輸出是優美的;
- 程序輸入是優美的;
- 程序本身也是優美的;
- 程序輸入有著完好并正確的文檔;
- 程序本身也是有著完好并正確的文檔;
- 程序是經過良好測試過并驗證是正確的;
- 正在解決的問題是十分明確的;
- 整個問題本身也是十分明確的;
加上這些約束后，編程就變得非常困難了?，F在對于一個特定的問題，上述一部分約束是可以放松的。幾個典型的設想是：
不必持續維護的程序
我們經常僅僅為了得到輸出結果而寫程序。 這種情況下，程序的輸入和程序本身以后是不需要維護的，因此這些不必詮釋地特別優美和充分。
我的 Erlang 這本書就是這樣的一個例子。一旦書出版了，為了寫書而使用的程序以及輸入部分就不必在維護了。程序結果看起來很優美，但是輸入部分只是一堆混亂的 xml 文件，為了寫書而用到的一些測試代碼也永遠不必保留了。
書的勘誤表和為了后續重版的一些必要訂正只是涉及到了輸入部分的輕微修改，即使程序的輸入部分并沒有很完善的整理記錄過，這也是很容易操作的。
必須要維護的程序
對于那些從頭到尾都要進行維護的程序來說就是這種。程序的輸入和程序本身都必須詮釋地特別優美，文檔和注釋完整而優雅。
我不久之前和一位開發 Web 應用程序的計算機咨詢師聊天。他說一旦程序的輸出看起來沒問題了(即網站看起來不錯，程序似乎也可以運行了)，客戶就會認為項目已經完成了，項目經理就會把他分配到下一個項目上去。
在下一個項目啟動之前，不僅網站要看起來不錯，而且編寫的代碼也應該是整理有序并且有案可循的。但是人們沒有空閑時間這么做，也無法理解這個觀點。而這類項目就是在將來需要一直被維護的。
還有什么因素讓編程困難?
還有其他三個因素讓編程變得困難：
- 修復本不應該出問題的程序
- 沒時間學習
- 編程的惡劣環境
這三個問題全是「時間的小偷」，讓我們具體來看看：
修復本不該出問題的程序
為了解決某個特定的問題，我經常會使用既不是我寫的，我也不是很理解的軟件。最好的情況是，這個我不得不用的程序有一份描述精確的使用說明。 但是往往這個程序要么沒有描述文件要么就是描述文件是錯誤的。
那么， 當文件寫著：『做XYZ后，就會發生PQR』，而你做了『XYZ』后，『PQR』卻沒發生的時候，你該怎么辦呢?如果你很幸運，寫這個程序的人就在你旁邊，那么你就能直接過去問搞定這些問題。不是這樣的話，你要么用Google碰碰運氣，要么就直接挖出源代碼找答案吧。
用Google這個「大賭場」找怎么修復bug，真的是讓人極度沮喪的事兒。我簡單 Google 搜索一下，然后會發現一些記錄，某個可憐不幸的家伙也遇到了和我正好一樣的問題。我喜出望外，顫抖著用手指輸入可以除掉詛咒的魔法指令…..然后…..啥也沒有改變。問題依然存在。
為啥這修復工作對其他人有效對我沒用呢。難道有個邪惡的神監視著我，還是我處于宇宙中暫時不符合物理規律的局部區域?我們兩個機器的初始狀態不同，因此在一種狀態內修復一個機器bug的方法未必能修復另一種狀態下機器的bug。
正像有時候我想用 smalltalk 編程，我們都用一模一樣的程序映像開始著手-Smalltalk 的程序員必須活在這種情況不會發生的理想的天堂里，但是一旦有一天，甚至他們自己的程序可能不得不和其他程序對話的時候，好玩兒的事就開始了。修復被破壞的東西帶來的沮喪是雙重的，即便你已經趕走了bug，你也真的并不知道這是不是你要修復的最后一個問題，也不知道你所做的改變帶來的實際影響。
順便說一句，這類問題耗費了我大部分的時間， 粗率估算一下大概占用60-70%。我曾經用了超過一星期的時間試圖讓一個壞了的LDAP服務器工作，我的老板禁止我執行我自己的LDAP服務器，然而和這個用 C 編碼歸檔混亂的壞了的 LDAP 服務器斗爭了一周后，我記憶模糊了一些，也忘記了老板說的話，意外地在午餐休息的時候用 Erlang 在 scratch 里成功地運行了服務器。
老實說，這并不是一個完整的LDAP服務器，但是我也不需要一個完整的LDAP服務器。我只想運行一些命令而已，這其實是很容易修復的。 現在我對執行陳舊又變態的協議沒有什么樂趣，而通常情況下最快的進行方式是在scratch里重新實現他們。
解決問題而不是學習
我懶，我就是個懶蟲。當我想在LaTeX里放入一個圖表的時候，我不想先讀一遍391頁的操作手冊?，F在我猜你肯定會指責我的懶惰和不健全的品德。我也知道我想應該先讀一下這份優秀的手冊，但是我想十分鐘內在文檔中放入一個圖表，那么讀完391頁的手冊是不可能的。解決這類問題時，我會選擇更快的解決方法—但是長期來看這樣損失慘重。
制作文檔這事兒，我一直猶豫是使用TeX/LaTeX，XSLT-FO還是我自己的 Erlguten。
大約每三年我都有一次強烈的欲望把自己所有的文檔直接在postscript中寫一遍，然而之后我只是做個深呼吸后等這個想法慢慢消失。
我猜 Giambattista Bondoni 在 1818 年發明他的手工印刷的時候，并沒有特別關心排版一頁紙是否要花費幾個星期。但是現在我們讓機器做這些無聊又危險的事兒，我們就有了更多的時間卻沒有時間把事兒做對了。
我問我老板他是否需要一個炫酷的幻燈片做下次的講座，他說需要并要求我在明天之前交給他。這使我沒時間正確地學Tex(我估計幾年可以完成這個事兒)，也沒時間實現我自己的排版語言(大概要用5年時間)，也沒時間在postscript里直接寫(大概要一周左右)—這樣我估計我還是用PowerPoint吧。
編程的惡劣環境
如果你讀到了這里，你就會理解我說編程真的很難的話了。原因是工作場所就是設計來讓編程更難的。我們開放的工作場所，提供了破壞我們聚精會神的吵鬧環境，打擾我們的手機和讓我們分心的因特網。
幸運的是，我們可以去不會打擾我們的地方。那就是睡覺。很多編程問題都是在睡覺的時候解決的。
有兩個辦法，第一你把問題上傳到你的大腦里然后睡覺，第二天起床后一些問題就解決了。很簡單。
第二，你把問題在睡前放到網上或者推特上。第二天就會有人發給你解決辦法了。成為一個好的程序員是需要很長時間的，你需要學習很多的知識也需要知道當你卡殼的時候去問誰。
令人驚訝的事實
當我完成這篇文章的時候，我想檢查下內容的拼寫。 emacs的ispell模式罷工了。這個我一直用于拼寫檢查的程序，現在無法搜索到一個拼寫。
我的emacs拼寫檢查器在這臺機器上忠實的工作了好幾年了。就在我抱怨花費半生時間修復本不應該出問題的程序的時候，我的emacs拼寫檢查器壞掉了。
我不信邪神，也不信我現在打字的起居室沙發的左邊角落不遵循物理定侓。盡管有些間接的證據似乎在反駁我。
我不知道我的拼寫檢查器壞掉的原因—一切看起來都沒問題，我沒有改變任何東西。哦從我上次檢查文本拼寫后，我只安裝了新版的Erlang安裝了Julia，并寫了一些講座筆記而已。
幸運的是，在Google賭場里工作了11分鐘后，第二個如何修復我的問題的建議起效了。 然而我還是不懂為什么 emacs 不能搜索一個拼寫。人生苦短，來不及找尋所有答案。
我猜大概只是有些事情我們永遠不會明白罷了。
