程式設計為什麼這麼難？
多年前我曾一度認為程式設計很簡單，然而隨著歲月的流逝，我終於意識到程式設計並不是件容易的事。這是因為，我所認為的「究竟什麼是程式設計」和「程式設計師到底是做什麼的」，在感知上已經漸漸地發生了轉變。
定義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 不能搜尋乙個拼寫。人生苦短，來不及找尋所有答案。
我猜大概只是有些事情我們永遠不會明白罷了。
為何程式設計如此之難？Erlang 之父的感觸
多年前我曾一度認為程式設計很簡單，然而隨著歲月的流逝，我終於意識到程式設計並不是件容易的事。這是因為，我所認為的 究竟什麼是程式設計 和 程式設計師到底是做什麼的 在感知上已經漸漸地發生了轉變。定義1 所謂程式就是一種把輸入轉化為輸出的東西，程式設計師就是寫程式的人，程式設計就是寫程式的這個行為 現...
提高質量為何如此之難
提高質量為何如此之難 precision cribbage 的故事說明，符合需求 並非是質量全部含義 除非你接受的是某種關於需求的非傳統定義。這個故事同時也說明，基於錯誤的數量來定義質量也是不全面的 這方面的例子有 所謂質量，就是指沒有任何錯誤。雖然實際上這類定義不堪一駁，但是許多年來它們一直是人們...
雜湊表查詢為何如此之快
雜湊是在記錄的儲存位置和它的關鍵字之間建立乙個確定的對應關係f，使得每個關鍵字key對應乙個儲存位置f key 建立了關鍵字與儲存位置的對映關係，公式如下 設所有可能出現的關鍵字集合記為u 簡稱全集 實際發生 即實際儲存 的關鍵字集合記為k k 比 u 小得多 雜湊方法是使用函式f將u對映到表t 0...