作為程式設計師，你會如何跟非程式設計師解釋寫程式不容易這件事？為啥看不見摸不著的程式需要花時間去寫去維護？很多人其實都沒想明白。來看看 Erlang 之父 Joe Armstrong 的感觸。
程式設計為什麼這麼難？
多年前我曾一度認為程式設計很簡單，然而隨著歲月的流逝，我終於意識到程式設計並不是件容易的事。這是因為，我所認為的「究竟什麼是程式設計」和「程式設計師到底是做什麼的」，在感知上已經漸漸地發生了轉變。
定義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 不能搜尋一個拼寫。人生苦短，來不及找尋所有答案。
我猜大概只是有些事情我們永遠不會明白罷了。