我对“什么是程序（Program）”的理解

程序（Program）——分为内在层面和外在层面。内在层面为指令，外在层面为需要解决的问题和环境参数约束。

所以程序就是在某些环境参数的约束下，针对需要解决的问题而编制的一系列指令、数据的集合。

流行的解释：“程序=数据结构+算法"，我觉得作者仅仅看到指令本身，而忽略了指令的最终目的和环境约束。也就是说，“数据结构+算法”只是手段，属于上面所说的内在层面，不是程序的目的。

举个可能不太恰当的例子，先破后立：A君对B君说：“麻烦写一个加法器，能让用户输入两个int类型的参数，然后这个加法器返回结果给用户”。

——“写一个加法器，返回结果给用户”是B君需要解决的问题，“输入两个int类型的参数”是B君的环境约束（用户输入类型是int，个数是2个）。

此时B在干什么？B像一个呆子一样，仿佛听不见，喃喃自语地说着“我应该再做一个数据结构，用某种算法”，写着天书一样的程序，程序上满是数据结构和算法，可是这个对A君有没有用？没用！

A君比喻的就是外在层面，B君比喻的就是内在层面，两者不能割裂。B君写的指令是为了能让A君用，而不是自顾自地写程序——因什么而写（解决的问题）？为什么这么写（环境参数约束）？

环境，根据个人看法分为真实环境、硬件环境、指令环境和文法环境，它们因为需求和被需求的关系而结合。举个例子来解释，一台打印机打印出了一张报纸。真实环境是一张白纸，硬件环境是打印机，指令环境是驱动程序。白纸需要打印机打印，打印机需要驱动程序发出中断信号。函数Function A调用另一个函数Function B，Function A是Function B的指令环境。Function A、Function B定义了两个函数，写法本身是文法环境。

也许在《深入理解计算机系统》中一段话可以用来印证上文：“信息就是位加上下文”。一个“位”本身无意义，必须联系上下文才能显示它的意义。一段指令本身也无意义，联系它需要解决的问题和环境约束才有意义，解决的问题和环境约束就是指令的上下文。

这个对程序的解释，我们也可以引申到日常学习当中去。A君在公司里，每天的编程工作是做网站开发，具体需求无非是展示各种信息——需要解决的问题；工具是ASP.NET，面对的受众范围仅限在本城市，网站性能要求不高，开发进程不能太慢，老板不重视有没有bug，快点做出来赚到钱才要紧——环境参数约束。好，这时候，A君他很好学，买一堆书来看——《设计模式》、《计算机程序设计艺术》、《TCP/IP详解》、《C++ Primer》、《鸟哥的Linux私房菜》。请问，这些对他的开发有用吗？没有用！因为他要开发的程序，主要无非是对数据库进行增删改查而已，又不需注重性能，又不重视bug。所以不需要多么高深、完美的代码。工作平台又是ASP.NET、Windows系统，所以《C++
Primer》、《鸟哥的Linux私房菜》这些对他都没用，写代码用不到。

许多大公司，比如百度、阿里巴巴、腾讯（俗称“BAT”），他们可能要求真正精通一门语言（用C++举例），为何？在我看来，就是因为他们——需要解决的问题很多，环境参数约束很少——项目规模大，受众多，功能丰富，性能要求极高，等等。这些很大程度上主动决定了他们涉及的C++语法非常全面，对C++的理解必须非常深入（保证质量和性能是主要原因）。于是要求精通语言，也就在情理之中了。