數學是一種思考方式
這幾天有個讀者來來去去給我寫了幾封 email ，問起我的觀點：數學和編程是什麼關係？學編程需要多深的數學基礎？到底需要掌握哪些數學知識，對編程能力的提高有幫助。
這個還真不好說。
如果說起課堂上我們學到的知識。除了初等代數，在編程中我還真沒碰到多少依賴數學技能來解決的問題。當年我學 C 語言的時候很小，甚至不知道數學中函數這個概念，還不一樣把 C 語言學完了。雖然過了些年，我才把數學中的函數和程序中的函數聯繫起來。
做 3d 遊戲編程，大學裏的線性代數可能還用的到一點。至少得知道矩陣運算吧。但是大部分程序員並不需要接觸這些東西。除此之外，如果說程序員必須精通微積分才能編程，那絕對是鬼扯。
如果對用編程的手段解決各種問題感興趣，或許相關領域的數學知識有些用。比如我時常由於興趣，做一些數據統計分析工作，這時概率統計的知識就少不了。但是解決問題，編程和數學一樣，都只是工具。他們的地位是平等的，並非編程的技能依賴數學技能。
那麼，學習數學有用嗎？當然有必要。因爲數學是一種思考方式，編程需要這樣的思考方式。
我有個朋友，十年前認識他的時候，他說他在學佛。有一個問題沒弄明白：佛說，不要執着。那麼執着於不要執着是不是一種執着。
過了好些年，他還沒弄明白這個問題。
學佛怎可以執着於這樣的語言邏輯呢？光讀佛經是沒有用的，道理有時候需要頓悟。數學也如此。
學習數學絕對不是無休止的解題訓練，我們需要悟到其中的思考方法。那種邏輯嚴密的推理，對完美境界的構建。發現理論上的缺陷，並對其分析，重新構作。當然，這個過程，又需要我們做大量的練習，藉此領悟其中的道理。
編程也一樣，不斷的編寫代碼本身並不能直接提高編程能力。我們需要的是對問題的洞察力，構建系統的能力，理解機器運行時來龍去脈的能力，等等。而這些能力又是在不斷編程實踐中頓悟出來的。
編程和數學一樣，是絕對嚴謹的。程序有特定的輸入，經過特定的流程，一定有特定的輸出。對於程序中的 bug ，我們不能抱有神祕論。它們不會沒來由的出現，沒來由的消逝。這就跟數學證明一樣，邏輯或概念的缺陷不會隨着時間消失，總等待後人來修補。
另一方面，在數學中，直覺也是很重要的。直覺可以幫助我們快速理解問題，解決問題。對數學瞭解的越多，數學的直覺就越準。很多數學知識，不需要太多研究學習，靠直覺就可以理解了。程序寫多了的人通常也會有這種感覺 :D
只是有時候，數學中有些命題很直觀，但是證明過程卻非常繁雜。
比如拓撲學中的若當曲線定理：平面上一條簡單閉曲線 C 恰好可以把平面分成兩個區域，一個是內部，一個是外部。換句話說，平面上的點被分爲了兩類：在曲線外部的點集 A，和在曲線內部的點集 B 。在同一點集中的任意兩點都可以用一條不與 C 相交的曲線相連，而連接一對不屬於同一點集的兩點的連線必然和 C 相交。
這個定理看起來很直觀，顯然是對的。但是一般人很難做出嚴格的數學證明，甚至很難看懂其證明。
現代編程我們經常會遇到類似的東西。尤其在現在系統越來越複雜的情況下，一段很簡單的應用程序代碼，你可以很顯然的知道它能做什麼，但是很少有人可以完全解釋清楚它是怎樣一步步做到的。比如一段很簡單的 Windows 程序代碼就是這樣。只有擁有追根問底的數學精神，纔會刨進操作系統底層，去搞明白系統到底怎樣工作。這些不是一日之功，甚至不是三五年就夠了的。而許多庸庸碌碌的程序員，滿足於拖兩個控件，粘合一下代碼。最終只會感嘆，程序只能寫到三十歲。要我說，平庸資質如我，三十歲能入門就不錯啦。
數學的發展歷史中，又包含了許多人無窮的創造力。光靠邏輯推理來一步步解決問題顯然是不夠的。很多數學問題的解決，都起源於某種直覺，某種創造性構建，甚至把許多表面不相關的東西牽連在一起思考。然後再通過邏輯嚴密的推導過程來完善它。
例如，費馬大定理的最終證明。首先找到了關於費馬方程的解所在的費馬曲線和橢圓曲線的聯繫，然後構造出一種特殊的橢圓曲線，當且僅當費馬大定理不成立時，該曲線才存在。最後，通過證明這種曲線有一些極端奇怪和不可信的性質，決定了曲線不可能存在，從而反證了費馬大定理成立。這之中雖然用到了許多前沿的高深數學理論成果才得以證明，但整個思路框架之巧妙，也是讓人佩服之至。
編程也是如此，我們首先需要對各種編程方法，編程語言的特性得心應手；而後，編程絕對不是簡單的堆砌代碼，它需要我們巧妙的構建系統，在合適的地方用合適的方式來解決問題。最終還需要讓每個部分都嚴格正確。
最後，對於那位朋友的問題，我只能給出我的個人建議。學習編程的確需要學習數學。但學習數學，不必列出書目，一本本去啃那些枯燥的教科書。只需要從數學史讀起，弄清人類是怎樣一步步理解數學的，學習其中的思想，最後用自己的興趣去研究其中感到有趣的部分。