13-14 修改语句拗口问题 (#631)

* 1

* 2

* 没有第三种形式吧?

* 修改语句拗口问题

* 修改语句拗口问题 2

* 修改语句拗口问题 3

* 修改语句拗口问题 4

* 修改语句拗口问题 5

* 修改语句拗口问题 6

* 修改语句拗口问题 7

* 修改语句拗口问题 8

* 修改语句拗口问题 9

* 拗口问题

* 修改语句拗口问题 10

* 修改语句拗口问题 11

* 修改语句拗口问题 12

* 修改语句拗口问题 13

* 修改语句拗口问题 14

* 修改语句拗口问题 14

* 修改语句拗口问题 15

* 修改语句拗口问题 16

* 修改语句拗口问题 17

* 十三章修改语句拗口问题

* 13-14 修改语句拗口问题

* 13-14 修改语句拗口问题 2

* 13-14 修改语句拗口问题 3

* 13-14 修改语句拗口问题 4

* Update 13-Functional-Programming.md

Co-authored-by: Joe <736777445@qq.com>

Author: andyphone

docs/book/11-Inner-Classes.md

@@ -1411,7 +1411,7 @@ Anonymous inner 8
 Anonymous inner 9
 ```
 
-**Counter** 返回的是序列中的下一个值。我们分别使用局部内部类和匿名内部类实现了这个功能，它们具有相同的行为和能力，既然局部内部类的名字在方法外是不可见的，那为什么我们仍然使用局部内部类而不是匿名内部类呢？唯一的理由是，我们需要一个已命名的构造器，或者需要重载构造器，而匿名内部类只能用于实例初始化。
+**Counter** 返回的是序列中的下一个值。我们分别使用局部内部类和匿名内部类实现了这个功能，它们具有相同的行为和能力，既然局部内部类的名字在方法外是不可见的，那为什么我们仍然使用局部内部类而不是匿名内部类呢？唯一的理由是，我们需要一个已命名的构造器，或者需要重载构造器，而匿名内部类只能使用实例初始化。
 
 所以使用局部内部类而不使用匿名内部类的另一个理由就是，需要不止一个该内部类的对象。
 

docs/book/13-Functional-Programming.md

@@ -1429,9 +1429,9 @@ Hup Hey
 
 **[1]** 这一连串的箭头很巧妙。*注意*，在函数接口声明中，第二个参数是另一个函数。
 
-**[2]** 柯里化的目的是能够通过提供一个参数来创建一个新函数，所以现在有了一个“带参函数”和剩下的 “自由函数”（free argumnet） 。实际上，你从一个双参数函数开始，最后得到一个单参数函数。
+**[2]** 柯里化的目的是能够通过提供单个参数来创建一个新函数，所以现在有了一个“带参函数”和剩下的 “自由函数”（free argument） 。实际上，你从一个双参数函数开始，最后得到一个单参数函数。
 
-我们可以通过添加级别来柯里化一个三参数函数：
+我们可以通过继续添加层级来柯里化一个三参数函数：
 
 ```java
 // functional/Curry3Args.java
@@ -1460,7 +1460,7 @@ public class Curry3Args {
 Hi Ho Hup
 ```
 
-对于每个级别的箭头级联（Arrow-cascading），你都要在类型声明中包裹另一层 **Function**。
+对于每一级的箭头级联（Arrow-cascading），你都会在类型声明周围包裹另一个 **Function** 。
 
 处理基本类型和装箱时，请使用适当的函数式接口：
 
@@ -1491,17 +1491,17 @@ public class CurriedIntAdd {
 ## 纯函数式编程
 
 
-即使没有函数式支持，像 C 这样的基础语言，也可以按照一定的原则编写纯函数式程序。Java 8 让函数式编程更简单，不过我们要确保一切是 `final` 的，同时你的所有方法和函数没有副作用。因为 Java 在本质上并非是不可变语言，所以编译器对我们犯的错误将无能为力。
+只要多加练习，用没有函数式支持的语言也可以写出纯函数式程序（即使是 C 这样的原始语言）。Java 8 让函数式编程更简单，不过我们要确保一切是 `final` 的，同时你的所有方法和函数没有副作用。因为 Java 在本质上并非是不可变语言，所以编译器对我们犯的错误将无能为力。
 
-这种情况下，我们可以借助第三方工具[^9]，但使用 Scala 或 Clojure 这样的语言可能更简单。因为它们从一开始就是为保持不变性而设计的。你可以采用这些语言来编写你的 Java 项目的一部分。如果必须要用纯函数式编写，则可以用 Scala（需要遵循一些规则） 或 Clojure （遵循的规则更少）。虽然 Java 支持[并发编程](./24-Concurrent-Programming.md)，但如果这是你项目的核心部分，你应该考虑在项目部分功能中使用 `Scala` 或 `Clojure` 之类的语言。
+这种情况下，我们可以借助第三方工具[^9]，但使用 Scala 或 Clojure 这样的语言可能更简单。因为它们从一开始就是为保持不变性而设计的。你可以采用这些语言来编写你的 Java 项目的一部分。如果必须要用纯函数式编写，则可以用 Scala（需要一些练习） 或 Clojure （仅需更少的练习）。虽然 Java 支持[并发编程](./24-Concurrent-Programming.md)，但如果这是你项目的核心部分，你应该考虑在项目部分功能中使用 `Scala` 或 `Clojure` 之类的语言。
 
 <!-- Summary -->
 ## 本章小结
 
 
-Lambda 表达式和方法引用并没有将 Java 转换成函数式语言，而是提供了对函数式编程的支持。这对 Java 来说是一个巨大的改进。因为这允许你编写更简洁明了，易于理解的代码。在下一章中，你会看到它们在流式编程中的应用。相信你会像我一样，喜欢上流式编程。
+Lambda 表达式和方法引用并没有将 Java 转换成函数式语言，而是提供了对函数式编程的支持。这对 Java 来说是一个巨大的改进。因为这允许你编写更简洁明了，易于理解的代码。在下一章中，你会看到它们在 *流式编程(streams)* 中的应用。相信你会像我一样，喜欢上流式编程。
 
-这些特性满足了很多羡慕Clojure、Scala 这类更函数化语言的程序员，并且阻止了Java程序员转向那些更函数化的语言（就算不能阻止，起码提供了更好的选择）。
+这些特性满足了很大一部分的、羡慕Clojure 和 Scala 这类更函数化语言的Java程序员。阻止了他们投奔向那些语言（或者至少让他们在投奔之前做好准备）。
 
 但是，Lambdas 和方法引用远非完美，我们永远要为 Java 设计者早期的草率决定付出代价。特别是没有泛型 Lambda，所以 Lambda 在 Java 中并非一等公民。虽然我不否认 Java 8 的巨大改进，但这意味着和许多 Java 特性一样，它终究还是会让人感觉沮丧和鸡肋。
 
@@ -1516,7 +1516,7 @@ Lambda 表达式和方法引用并没有将 Java 转换成函数式语言，而
 [^5]: 我还没有验证过这种说法。
 [^6]: 当你理解了[并发编程](./24-Concurrent-Programming.md)章节的内容，你就能明白为什么更改共享变量 “不是线程安全的” 的了。
 [^7]: 接口能够支持方法的原因是它们是 Java 8 默认方法，你将在下一章中了解到。
-[^8]: 一些语言，如 Python，允许像调用其他函数一样调用组合函数。但这是 Java，所以我们做做可为之事。
+[^8]: 一些语言，如 Python，允许像调用其他函数一样调用组合函数。但这是 Java，所以我们要量力而行。
 [^9]: 例如，[Immutables](https://immutables.github.io/) 和 [Mutability Detector](https://mutabilitydetector.github.io/MutabilityDetector/)。