文学编程

高德纳教授提出了文学编程（Literate programming），其主要思想在于，转变思维，程序不再是告诉计算机做什么的指令，而是向人类描述如何让计算机做事情的文字，编程像写文章一样
多年以前我第一次看到这个题目，第一反应就是，这样编程，也许经过严格训练之后，编码人员的工作效率不会降低，甚至可能还会提升，代码交流的难度也会下降，这些都是好处，但是也有缺点，比如，代码的执行效率必然要降低，至少也要增加更加复杂的编译或者解释过程
可能某些特殊的语言能够很好的支持文学编程，而无所谓它是编译的还是解释的。以下为了方便，先以编译说事
如果是编译执行的代码，那么就要有更加强悍的编译器，其设计的复杂程度必然加大，因为它需要更曲折的周转才能变成机器可识别的操作指令流，编译的难度和效率都会降低，比诸如C或者Java这样的语言要复杂和低效，就更别提和汇编这样的低级语言相比了
语言越高级，编译步骤就越复杂，这个很好理解，即旗只认识机器指令，按照信息论的观点，程序员都是按照自然语言的习惯思考问题的，思维要变成机器的指令，需要程式化，具体化，细致化，结构化，其中间步骤的工作量是一定的，需要程序员的编码和编译器的编译两个步骤来完成，如果程序员多做一些事，编码复杂点，那么编译器就可以少做一些事，编译的快一点——最快的当然就是程序员来做编译，直接写机器指令，但是这样的程序员最辛苦，所有的事情都要由程序员来做，而汇编语言用人类可理解的词汇来标记机器指令，这就稍微有些类似自然语言了，于是也便减轻了一些程序员的工作，作为代价，机器就要做一个转换工作，把类似自然语言的词汇转换成机器指令。像C这样的语言，其表达方式更接近人类的语言习惯，也就让程序员可以再轻松一些，但是同时，c的编译过程就远比汇编要来的复杂，不是逐行逐句逐词代换就能解决问题的了——于是有了编译原理这个学科分支
那么文学编程呢？很显然更接近自然语言，程序员理解起来更方便，但是随着而来的就是，编译器会更加复杂，要做的事情更多——我是说，由代码到机器可识别的指令序列，这个过程会更慢。不过其实，这不是问题，我们每一代人，都会做一些若干年前认为很奢侈很浪费的事，而且理所当然的乐此不疲。比如我15年前刚开始接触网络的时候，根本无法想象会有几M大的图片在网络里传播，网络上会有交互动画，甚至直接在线看电影这样耗费流量的事情，所以也许三两年后，编译代码的开销其实根本不是问题，我们会有非常强大的机器来达到我们所需要的速度
当然了，如前所说，编译或者解释都不是问题，不过其实，解释执行的语言可能更麻烦，更低效，虽然开发调试的过程在操作上会好一些，但是，依然是如前所说，速度和效率都不是问题，虽然人类对速度的追求是漫长的进化历史过程中被生存压力留下的深刻烙印，而且是无极限的，永远不知满足的
但是另外的一个问题随之而来，就是，程序员的工作难度降低了，于是培养程序员的标准也便跟着降低了，程序员真正出现两极分化，最有才华的，去做编译器或者解释器，而最没才华的，去写代码……没有中间地带。于是，技术的神圣性也便轻而易举的被解构——这可能是新灾难的开始
其实这也不是问题，任何新一代的语言，都会带来老一代程序员这样的担心，只不过，如果真的自然语言的形式语法和语意一旦进入了编程语言，那么语言到底会怎么样……是不是就是要死了
死的语言，不是没用的语言，而是不能继续发展的语言。就比如Java，非常有用，Java程序员的就业环境也非常好，市场广阔，但是就单从语言本身来讲，我觉得Java已经离死不远了，因为它很难再有发展的余地。当然Java目前还无法胜任文学编程，其实文学编程也和具体的某种语言基本上无关，文学编程是一种思路，完全可以通过framework的方式对任何一种语言进行改造，使其可以胜任文学编程的要求——也许这将会是Java的下一个苟延残喘的方式，总会有些不死心的人还要以各种途径来让某个行将就木的尸体再继续蹦达几天，还美其名曰“1+1>2”。不过如果真的这样……那可就是名副其实的“借尸还魂”了——无论是没有驱壳的灵魂，还是真魂出壳的尸首，总之都是死的
DEK是伟大的，虽然他的TAOCP还没写完。但是伟大不等于永远正确