校订 第13章函数式编程-前言部分 issue #24

docs/book/13-Functional-Programming.md

@@ -5,29 +5,31 @@
 
 
 
-函数式编程语言操纵代码片段就像操作数据一样容易。 虽然 Java 不是函数式语言，但 Java 8 Lambda 表达式和方法引用 (Method References) 允许您以函数式编程。在计算机时代的早期，内存是稀缺和珍贵的。几乎每个人都用汇编语言编程。 人们对编译器有所了解，但仅仅想到编译生成的代码肯定会比手工编码多了很多字节。
+> 函数式编程语言操纵代码片段就像操作数据一样容易。 虽然 Java 不是函数式语言，但 Java 8 Lambda 表达式和方法引用 (Method References) 允许你以函数式编程。
 
-通常，只是为了使程序适合有限的内存，程序员通过修改内存中的代码来保存代码空间，以便在程序执行时执行不同的操作。这种技术被称为自修改代码 （self-modifying code,），只要程序足够小，少数人可以维护所有棘手和神秘的汇编代码，你就可以让它运行起来。
+在计算机时代早期，内存是稀缺和昂贵的。几乎每个人都用汇编语言编程。人们对编译器有所了解，但仅仅想到编译生成的代码肯定会比手工编码多了很多字节。
 
-内存变得更便宜，处理器变得更快。 C语言出现并被大多数汇编语言程序员认为是“高级”。其他人发现C可以使他们显着提高生产力。 使用C，创建自修改代码仍然不是那么难。
+通常，只是为了使程序适合有限的内存，程序员通过修改内存中的代码来保存代码空间，以便在程序执行时执行不同的操作。这种技术被称为**自修改代码** （self-modifying code）。只要程序足够小，少数人可以维护所有棘手和神秘的汇编代码，你就可以让它运行起来。
 
-随着硬件越来越便宜，程序的规模和复杂性都在增长。 只是让程序工作变得困难。 我们想方设法使代码更加一致和易懂。 自我修改代码，以其最纯粹的形式，结果是一个非常糟糕的主意，因为它很难确定它在做什么。 它也很难测试，因为你是测试输出，转换中的一些代码，修改的过程吗？诸如此类。
+随着内存和处理器变得更便宜、更快。C 语言出现并被大多数汇编程序员认为更“高级”。人们发现使用 C 可以显著提高生产力。同时，创建自修改代码仍然不难。
 
-然而，使用代码以某种方式操纵其他代码的想法仍然很有趣，只要有一些方法可以使它更安全。从代码创建，维护和可靠性的角度来看，这个想法非常引人注目。 如果不是从头开始编写大量代码，而是从可以理解，经过充分测试和可靠的现有小块开始。 然后将它们组合在一起以创建新代码。 这不会让我们更有效率，同时创造更强大的代码吗？
+随着硬件越来越便宜，程序的规模和复杂性都在增长。这一切只是让程序工作变得困难。我们想方设法使代码更加一致和易懂。使用纯粹的自修改代码造成的结果就是：我们很难确定程序在做什么。它也难以测试：除非你想一点点测试输出，代码转换和修改等等过程？
 
-这就是函数式编程（FP）的意义所在。 通过合并现有代码来生成新功能而不是从头开始编写所有内容，您可以更快地获得更可靠的代码。 至少在某些情况下，这个理论似乎很有用。 在路上，函数式语言产生了很好的语法，一些非函数式语言已经习惯了。
+然而，使用代码以某种方式操纵其他代码的想法也很有趣，只要能保证它更安全。从代码创建，维护和可靠性的角度来看，这个想法非常吸引人。我们不用从头开始编写大量代码，而是从易于理解、充分测试及可靠的现有小块开始，最后将它们组合在一起以创建新代码。难道这不会让我们更有效率，同时创造更健壮的代码吗？
+
+这就是**函数式编程**（FP）的意义所在。通过合并现有代码来生成新功能而不是从头开始编写所有内容，我们可以更快地获得更可靠的代码。至少在某些情况下，这套理论似乎很有用。在这一过程中，一些非函数式语言已经习惯了使用函数式编程产生的优雅的语法。
 
 你也可以这样想：
 
-OO (object oriented) 是抽象数据，FP (functional programming) 是抽象行为。
+OO（object oriented，面向对象）是抽象数据，FP（functional programming，函数式编程）是抽象行为。
 
-纯粹的函数式语言在安全性方面更进一步。 它强加了额外的约束，即所有数据必须是不可变的：设置一次，永不改变。 将值传递给函数，该函数然后生成新值但从不修改自身外部的任何东西（包括其参数或该函数范围之外的元素）。 当强制执行此操作时，您知道任何错误都不是由所谓的副作用引起的，因为该函数仅创建并返回结果，而不是其他任何错误。
+纯粹的函数式语言在安全性方面更进一步。它强加了额外的约束，即所有数据必须是不可变的：设置一次，永不改变。将值传递给函数，该函数然后生成新值但从不修改自身外部的任何东西（包括其参数或该函数范围之外的元素）。当强制执行此操作时，你知道任何错误都不是由所谓的副作用引起的，因为该函数仅创建并返回结果，而不是其他任何错误。
 
-更好的是，“不可变对象和无副作用”范例解决了并发编程中最基本和最棘手的问题之一（当程序的某些部分同时在多个处理器上运行时）。 这是可变共享状态的问题，这意味着代码的不同部分（在不同的处理器上运行）可以尝试同时修改同一块内存（谁赢了？没人知道）。 如果函数永远不会修改现有值但只生成新值，则不会对内存产生争用，这是纯函数式语言的定义。 因此，经常提出纯函数式语言作为并行编程的解决方案（还有其他可行的解决方案）。
+更好的是，“不可变对象和无副作用”范例解决了并发编程中最基本和最棘手的问题之一（当程序的某些部分同时在多个处理器上运行时）。这是可变共享状态的问题，这意味着代码的不同部分（在不同的处理器上运行）可以尝试同时修改同一块内存（谁赢了？没人知道）。如果函数永远不会修改现有值但只生成新值，则不会对内存产生争用，这是纯函数式语言的定义。 因此，经常提出纯函数式语言作为并行编程的解决方案（还有其他可行的解决方案）。
 
-那么，请注意，函数式语言背后有很多动机，这意味着描述它们可能会有些混乱。 它通常取决于观点。 原因是“它是并行编程”，“代码可靠性”和“代码创建和库重用” 。[^1] 还要记住FP （functional programming）的参数 ( 特别是程序员将更快地创建更强大的代码 ) 至少仍然存在部分假设。 我们已经看到了一些好的结果，[^2]但我们没说纯函数式语言是解决编程问题的最佳方法。
+需要提醒大家的是，函数式语言背后有很多动机，这意味着描述它们可能会有些混淆。它通常取决于各种观点：“为并行编程”，“代码可靠性”和“代码创建和库复用”。[^1] 同时，函数式编程的参数能帮助程序员创建更快更健壮的代码 —— 部分仍然只是假设。虽然已有一些好的范例，[^2]但我们还不能证明纯函数式语言就是解决编程问题的最佳方法。
 
-FP的想法值得融入非FP语言。 例如，这种情况发生在Python语言中。 Java 8在FP中添加了自己的功能，我们将在此章探讨。
+FP 思想值得融入非 FP 语言，如 Python。Java 8 也从中吸收并支持了 FP。我们将在此章探讨。
 
 
 <!-- Old vs. New -->