标签:
数学并不是计算机科学的基础
很多人都错误的认为,计算机科学是数学的一个分支,数学是计算机科学的基础,数学是更加博大精深的科学。这些人以为只要学会了数学,编程的事情全都不在话下,然而事实却并非如此。
事实其实是这样的:
数学是异常糟糕的语言
这并不是危言耸听。如果你深入研究过程序语言的理论,就会发现其实数学家们使用的那些符号,只不过是一种非常糟糕的程序语言。数学的理论有些是有用的,然而数学家门用于描述这些理论所用的语言,却是纷繁复杂,缺乏一致性,可组合性(composability),简单性,可用性。这也就是为什么大部分人看到数学就头痛。这不是他们不够聪明,而是数学语言的“设计”有问题。人们学习数学的时候,其实只有少部分时间在思考它的精髓,而大部分时间是在折腾它的语法。
举一个非常简单的例子。如果你说x-1表示x的-1次方(x的倒数),那么f-1表示什么?f的-1次方,f的倒数?别被数学老师们的教条和借口欺骗啦,他们总是告诉你:“你应该记住这些!” 可是你想过吗:“凭什么!” x-1表示x的-1次方,而f-1,明明是一模一样的形式,表示的却是函数f的反函数。一个是求幂,一个是反函数,风马不及,却写成一个样子。这样的语言设计混淆不堪,却喜欢以“约定俗成”作为借口。
如果你再多看一些数学书,就会发现这只是数学语言几百年累积下来的糟粕的冰山一角。数学书里尽是各种上标下标,带括号的上标下标,x,y,z,a,b,c,f,g,h,各种扭来扭去的希腊字母,希伯来字母…… 斜体,黑体,花体,双影体,……用不同的字体来表示不同的“类型”。很多符号的含义,在不同的子领域里面都不一样。有些人上一门数学课,到最后还没明白那些符号是什么意思。
很多人学习微积分都觉得困难,其实问题不在他们,而在于莱布尼兹(Leibniz)。莱布尼兹设计来描述微积分的语言(∫,dx, dy, ...),从现代语言设计的角度来看,其实非常之糟糕,可以说是一塌糊涂。我不能怪莱布尼兹,他毕竟是几百年前的人了,他不知道我们现在知道的很多东西。然而古人的设计,现在还不考虑改进,反而当成教条灌输给学生,那就是不思进取了。
数学的语言不像程序语言,它的历史太久,没有经过系统的,考虑周全的,统一的设计。各种数学符号的出现,往往是历史上某个数学家有天在黑板上随手画出一些古怪的符号,说这代表什么,那代表什么,…… 然后就定下来了。很多数学家只关心自己那块狭窄的子领域,为自己的理论随便设计出一套符号,完全不管这些是否跟其它子领域的符号相冲突。这就是为什么不同的数学子领域里写出同样的符号,却可以表示完全不同的涵义。在这种意义上,数学的语言跟Perl(一种非常糟糕的程序语言)有些类似。Perl把各种人需要的各种功能,不加选择地加进了语言里面,造成语言繁复不堪,甚至连Perl的创造者自己都不能理解它所有的功能。
数学的证明,使用的其实也是极其不严格的语言——古怪的符号,加上含糊不清,容易误解的人类语言。如果你知道什么是 Curry-Howard Correspondence 就会明白,其实每一个数学证明都不过是一段代码。同样的定理,可以有许多不同版本的证明(代码)。这些证明有的简短优雅,有的却冗长繁复,像面条一样绕来绕去,没法看懂。你经常在数学证明里面看到“未定义的变量”,证明的逻辑也包含着各种隐含知识,思维跳跃,非常难以理解。很多数学证明,从程序的观点来看,连编译都不会通过,就别提运行了。
数学家们往往不在乎证明的优雅性。他们认为只要能证明出定理,你管我的证明简不简单,容不容易看懂呢。你越是看不懂,就越是觉得我高深莫测!这种思潮到了编程的时候就显出弊端了。数学家写代码,往往忽视代码的优雅性,简单性,模块化,可读性,性能,数据结构等重要因素,认为代码只要能算出结果就行。他们把代码当成跟证明一样,一次性的东西,所以他们的代码往往不能满足实际工程的严格要求。
编程是一门艺术
从上面你也许已经明白了,普通程序员使用的编程语言,就算是C++这样毛病众多的语言,其实也已经比数学家使用的语言高明很多。计算机科学并不是数学的一个分支,它在很大程度上是优于数学,高于数学的。有些数学的基本理论可以被计算机科学所用,然而计算机科学并不是数学的一部分。数学在语言方面带有太多的历史遗留糟粕,它其实是泥菩萨过河,自身难保,它根本解决不了编程中遇到的实际问题。
编程真的是一门艺术,因为它符合艺术的各种特征。艺术可以利用科学提供的工具,然而它却不是科学的一部分,它的地位也并不低于科学。和所有的艺术一样,编程能解决科学没法解决的问题,满足人们新的需求,开拓新的世界。所以亲爱的程序员们,别再为自己不懂很多数学而烦恼了。数学并不能帮助你写出好的程序,然而能写出好程序的人,却能更好的理解数学。我建议你们先学编程,再去看数学。
标签:
原文地址:http://www.cnblogs.com/zourui4271/p/4757429.html