学术技术与工程技术是两码事

忽悠，接着忽悠，让数学建模的人来想想怎么让程序没有bug吧。
并且对现实世界建立模型似乎从来也不是数学专属范畴。
我想您可以继续微笑了。

一个数学建模的大三学生如果认真学过，可以解决目前我们工作中软件核心模块（涉及）算法的95%以上的问题。
这是我在协助该学生完成软件开发作业时“惊见”的。

说的是软件设计，不是算法。

debug也不属于软件设计的范畴

有句很经典的话：Algorithms + Data Structures = Programs

然。
当时那个作业貌似是一个杂货店商品分类，我也是5年经验了，用递归写出来的程序运行了半个小时，后来那个学生把那个题目之前他们老师的课件PPT发给我，是个*****算法，FT，写出来只需要几十秒。东西相当的复杂，以至于我现在都连题都记不清了。

只有吵架才计较对错

我提debug了吗？我提的是bug，设计上的bug。

说的真好，终于有人指出了至少还有数据结构。
不过数据结构这门学问可是和数据结构这门课完全不是一个概念。

你还别说,现在真有一个热门的行当叫做模型验证.去年图林奖的得主Edmund M. Clarke的专攻项目.这个问题忽悠不忽悠,可以去和图灵奖评审委员会较较真.
另外这方面,目前工程化和应用化的做的也不错.Standford的 Dawson Engler 的一篇Paper拿到了OSDI08的Best Paper award .具体的可以看这里.
http://www.usenix.org/events/osdi08/tech/full_papers/cadar/cadar.pdf

KLEE可以为任意source code自动生成覆盖率达90%以上的Test Case。

Dawson自己对这篇paper的评价是：This is one of the very best we've done in the past ten years。当然人家也不是吹牛的.这个人现在是bug finding方面是个超级明星，他的工具为Linux Kernel，OpenBSD，EXT3等等找出了400百多个bug，他还用自己的研究成果startup了一个叫Coverity专做source code static analysis的公司，生意十分红火。

除了现有的算法成果以外,model checking仍然是一个有待深入探索的问题.比如Model checking的关键问题是test case的state explosion,随着程序路径的增加，测试状态呈几何级数增加.怎么降低状态数量,除了现在局部优化算法外最有希望的就是引入代数几何.http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.49.2570.不远的将来的测试工作就不再是依靠人肉苦力的堆积,而是需要专业的几何学家为工程师们设计自动化算法.

所以凡是你现在认为机器不可能做到需要以人类优雅高深的哲学思想解决的事情,都是计算机科学家数学家们现在捞钱的金饭碗.