从数学恐慌症中恢复

现在贴有“计算机”、“软件”标签的知识太多，让人无所适从。

几年前我很关注那些冠以“xx沉思录”、“xx之道”之类的东西，很快就觉得疲劳而没有收获，在工作实践和理论研究中都收效不大，很遗憾既没有“沉思”也没有得“道”。

后来就听说算法才是“王道”。但是究竟什么知识可以归为算法呢，应该怎么学呢？稍微看一点算法，就知道算法是与数学紧密结合在一起的

，而且许多“problem”本身就有漂亮的数学解。

当然还有人说“problem solving”才是王道。（据说AI被搞臭了后就才被改名为problem solving）problem solving比“算法”这个词更宽泛。甚至也可以说去成都小吃吃小笼包都算problem solving——解决了肚子饿的问题，^_^。problem solving是目的，而不是手段。

然后有很多人认为数学是王道，including me。嗯，数学比算法更宽泛。工作了几年有一些困惑，比如如何证明、验证或保证程序的正确性，怎么描述程序语言的语义和语用等等，想读读书，这促使我辞职去读研究生。然后系统地上了许多数学课。说起来有点头大：从小学到研究生我们上了好多数学课，一年不落。从初等代数到抽象代数，从平面/立体/解析几何到计算几何微分几何，还学了数学分析、概率论、矩阵论、数值分析。软件理论的基础的基础是离散数学，于是又读集合论、数理逻辑、图论、数论、形式语言与自动机理论、计算理论，甚至还买了拓扑学读了几天。我们学了这么多数学，怎么感觉在coding时派不上用场呢。数学不介意存在主义，而我们关心直觉主义逻辑，我们关心如何把解构造出来。That's the point。

写程序是在做证明题。从工程化开发角度讲我们把对软件的需求形式化后分割成了许多论题或定理形成设计，通常未经过系统训练的人不会去严格证明这些论题或定理，而是凭直觉猜测其正确性。而形式化开发方法就辅助设计师完成论题的证明，插一句，模型检测是从相反的方向检查软件是否具有预期的属性，而判断程序的正确性是不可判定问题，于是这个问题就被抛给了工业界，要用工程化的办法解决。老生常谈，数学的一个功能是训练了我们在做证明时思维的严密性。如果沉浸在数学的海洋里很可能就再也出不来了，数学的分支很细很浩瀚，如果以数学为王道，作为我们学习软件的基础，我们会一辈子打数学基础而不能自拔。我们上了许多课、看了许多书、做了许多题，可是，我们甚至不理解递归（因为数学书里没教啊），于是要学递归论？我们还不会回溯，不会动态规划。咋办，再学一门应用数学：运筹学？里面涉及规划论、排队论、博弈论……。无穷无尽……，忽而又听knuth他老爷子早在40年前就发现这问题了，于是他才开了一门课叫做具体数学，哇，佩服的五体投地，赶快把CMath买回来，又发现具体数学是程序设计艺术的先修课，那程序设计艺术该牛成什么样啊！把TAOCP 1-4买回来，垛在CMath上发现总共有半米厚！晕倒。
stop, stop. 我觉得数学的第二个功能是开阔了视野，或者洞察力。计算机软件的数学外壳并不太厚。许多学科或论文都喜欢披上数学的外衣，同构于一个数学模型或概念。我们可能只需要根据概念找到相关的书读一读，就会发现作者的思路并不复杂。所以，我想对于学软件的来说，数学的学习可以是由需求驱动的。
那么什么是软件的王道呢？我觉得应该是思考，thinking。找本算法小书（算法引论很不错，里面证明算法的正确性很干净），学学几个常用的算法和解小规模NP问题的暴力算法就ok了。
对于具体的问题，用多种手段分析，深入的思考。让数学还是作为数学家和数学爱好者的王道吧，我们应该关心的是如何solving problem ，这个念头可以很好的缓解我的数学焦虑症。

做重复的事情（比如开会、编码、测试、试/实验）久了会停止思考，有人说应该读那些可以引导我们思考的书，所以这个problem的一个

solution就是做一些漂亮、干净的数学题，比如图论有很多闪烁着智慧的问题，还有knuth的CMath、TAOCP的题非常好。做这些题的目的绝不是为了直接映射到编码中，而是促使我们不要停止系统的思考和分析。

以上说的是算法相关的。软件的基础理论与具体应用离得稍远些，我对其了解的不多，越是未知的领域越容易令人好奇，我可能会把看语言理

论，语义语用的书作为第二爱好吧。