為何程式設計如此之難？Erlang 之父的感觸

程式設計為什麼這麼難？

多年前我曾一度認為程式設計很簡單，然而随着歲月的流逝，我終于意識到程式設計并不是件容易的事。這是因為，我所認為的「究竟什麼是程式設計」和「程式員到底是做什麼的」，在感覺上已經漸漸地發生了轉變。

定義1：所謂程式就是一種把輸入轉化為輸出的東西，程式員就是寫程式的人，程式設計就是寫程式的這個行為；

現在讓我們給我對程式的這個定義加一些限制吧。

定義2： 所謂程式就是在遵從下列限制的條件下，把一些輸入轉化為輸出的東西。

程式輸出是優美的；

程式輸入是優美的；

程式本身也是優美的；

程式輸入有着完好并正确的文檔；

程式本身也是有着完好并正确的文檔；

程式是經過良好測試過并驗證是正确的；

正在解決的問題是十分明确的；

整個問題本身也是十分明确的；

加上這些限制後，程式設計就變得非常困難了。現在對于一個特定的問題，上述一部分限制是可以放松的。幾個典型的設想是：

不必持續維護的程式

我們經常僅僅為了得到輸出結果而寫程式。 這種情況下，程式的輸入和程式本身以後是不需要維護的，是以這些不必诠釋地特别優美和充分。

我的 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頁的操作手冊。現在我猜你肯定會指責我的懶惰和不健全的品德。我也知道我想應該先讀一下這份優秀的手冊，但是我想十分鐘内在文檔中放入一個圖表，那麼讀完391頁的手冊是不可能的。解決這類問題時，我會選擇更快的解決方法—但是長期來看這樣損失慘重。

制作文檔這事兒，我一直猶豫是使用tex/latex，xslt-fo還是我自己的 erlguten。

大約每三年我都有一次強烈的欲望把自己所有的文檔直接在postscript中寫一遍，然而之後我隻是做個深呼吸後等這個想法慢慢消失。

我猜 giambattista bondoni 在 1818 年發明他的手工印刷的時候，并沒有特别關心排版一頁紙是否要花費幾個星期。但是現在我們讓機器做這些無聊又危險的事兒，我們就有了更多的時間卻沒有時間把事兒做對了。

我問我老闆他是否需要一個炫酷的幻燈片做下次的講座，他說需要并要求我在明天之前交給他。這使我沒時間正确地學tex（我估計幾年可以完成這個事兒），也沒時間實作我自己的排版語言（大概要用5年時間），也沒時間在postscript裡直接寫（大概要一周左右）—這樣我估計我還是用powerpoint吧。

如果你讀到了這裡，你就會了解我說程式設計真的很難的話了。原因是工作場所就是設計來讓程式設計更難的。我們開放的工作場所，提供了破壞我們聚精會神的吵鬧環境，打擾我們的手機和讓我們分心的網際網路。

幸運的是，我們可以去不會打擾我們的地方。那就是睡覺。很多程式設計問題都是在睡覺的時候解決的。

有兩個辦法，第一你把問題上傳到你的大腦裡然後睡覺，第二天起床後一些問題就解決了。很簡單。

第二，你把問題在睡前放到網上或者推特上。第二天就會有人發給你解決辦法了。成為一個好的程式員是需要很長時間的，你需要學習很多的知識也需要知道當你卡殼的時候去問誰。

令人驚訝的事實

當我完成這篇文章的時候，我想檢查下内容的拼寫。 emacs的ispell模式罷工了。這個我一直用于拼寫檢查的程式，現在無法搜尋到一個拼寫。

我的emacs拼寫檢查器在這台機器上忠實的工作了好幾年了。就在我抱怨花費半生時間修複本不應該出問題的程式的時候，我的emacs拼寫檢查器壞掉了。

我不信邪神，也不信我現在打字的起房間沙發的左邊角落不遵循實體定侓。盡管有些間接的證據似乎在反駁我。

我不知道我的拼寫檢查器壞掉的原因—一切看起來都沒問題，我沒有改變任何東西。哦從我上次檢查文本拼寫後，我隻安裝了新版的erlang安裝了julia，并寫了一些講座筆記而已。

幸運的是，在google賭場裡工作了11分鐘後，第二個如何修複我的問題的建議起效了。 然而我還是不懂為什麼 emacs 不能搜尋一個拼寫。人生苦短，來不及找尋所有答案。

我猜大概隻是有些事情我們永遠不會明白罷了。