《函数式编程思维》试读：1.3　把控制权让渡给语言/运行时

在计算机科学短短的发展历史上，有时候会从技术主流分出一些枝杈，有源于实务界的，也有源于学术界的。例如在20 世纪90 年代个人电脑大发展的时期，第四代编程 语言（4GL）也出现了爆发式的流行，涌现了dBASE、Clipper、FoxPro、Paradox 等不可胜数的新语言。这些语言的卖点之一是比C、Pascal 等第三代语言（3GL）更高层次的抽象。 换言之，4GL 下的一行命令，3GL 可能要用很多行才写得出来，因为4GL 自带了更丰富的编程环境。像从磁盘读取流行的数据库格式这样的功能，4GL 天生就具备，并不需要使用者特意去实现。 函数式编程也是这样一根横生出来的枝杈，是学术界那些乐于为新思路和新范式寻找 表达手段的计算机科学家们的发明。分出来的枝杈偶尔会重新汇入主流，函数式编程当前正好是这种情况。函数式语言不仅在Java 虚拟机（JVM）平台上迅速地崭露头角，例如最有代表性的Scala 和Clojure 语言，.NET 平台也不例外，F# 已经是堂堂正正的平台一员。那么，为什么所有的平台都在拥抱函数式编程呢？ 20 世纪80 年代早期，我还在上大学的时候，用的编程环境叫作Pecan Pascal。Pecan Pascal的独门绝技是可以在Apple ][ 和IBM PC 上运行相同的Pascal 代码。为了做到这一点，Pecan 的工程师祭出了神秘的“字节码”（bytecode）。在编译的时候，开发者写下的Pascal源代码会被编译成这种在“虚拟机”上执行的“字节码”，而“虚拟机”在每一种运行平台上都有专门的原生实现。Pecan Pascal 用起来让人痛不欲生。就算最简单的编程习题，编译出来的代码都慢得无法忍受。当时的硬件水平还没有准备好迎接这样的挑战。 Pecan Pascal 被淘汰了，但它的架构我们都很熟悉。十年之后Sun 发布了采用同样设 计的Java，在20 世纪90 年代中期的硬件环境下勉力取得了成功。Java 还带来了其他一些救开发者于水火的特性，自动垃圾收集即是其中之一。我从此再也不想碰那些没有垃圾收集的语言。亲身经历告诉我，最好还是把时间花在更高层次的抽象上，多考虑怎样解决复杂的业务场景，少去费心复杂的底层运作。我为Java 纾解了人工管理内存的痛苦而欣喜，同时期冀在别的方面也能找到这样的利器。 人生苦短，远离malloc。随着时间的推移，开发者们越来越多地把乏味单调的任务托付给语言和运行时。对于我日常编写的应用程序类型来说，失去对内存的直接控制没什么可惋惜的，放弃这些反而让我能够专注于更重要的问题。Java 接管内存分配减轻了我们的负担，函数式编程语言让我们用高阶抽象从容取代基本的控制结构，也有着同样的意义。将琐碎的细节交托给运行时，令繁冗的实现化作轻巧，这样的例子本书中比比皆是。