面向Java开发人员的Scala指南: 构建计算器，第1 部分

摘要 特定于领域的语言已经成为一个热门话题 很多函数性语言之所以受欢迎 主要是因为它们可以用于构建特定于领域的语言 鉴于此 在 面向 Java？ 开发人员的 Scala 指南 系列的第 篇文章中 Ted Neward 着手构建一个简单的计算器 DSL 以此来展示函数性语言的构建 外部 DSL 的强大功能 他研究了 Scala 的一个新的特性 case 类 并重新审视一个功能强大的特性 模式匹配

上个月的文章发表后 我又收到了一些抱怨/评论 说我迄今为止在本系列中所用的示例都没涉及到什么实质性的问题 当然在学习一个新语言的初期使用一些小例子是很合理的 而读者想要看到一些更 现实的 示例 从而了解语言的深层领域和强大功能以及其优势 这也是理所当然的 因此 在这个月的文章中 我们来分两部分练习构建特定于领域的语言（DSL）— 本文以一个小的计算器语言为例

关于本系列

Ted Neward 将和您一起深入探讨 Scala 编程语言 在这个新的 developerWorks 系列 中 您将深入了解 Sacla 并在实践中看到 Scala 的语言功能 进行比较时 Scala 代码和 Java 代码将放在一起展示 但（您将发现）Scala 中的许多内容与您在 Java 编程中发现的任何内容都没有直接关联 而这正是 Scala 的魅力所在！如果用 Java 代码就能够实现的话 又何必再学习 Scala 呢？

特定于领域的语言

可能您无法（或没有时间）承受来自于您的项目经理给您的压力 那么让我直接了当地说吧 特定于领域的语言无非就是尝试（再一次）将一个应用程序的功能放在它该属于的地方 — 用户的手中

通过定义一个新的用户可以理解并直接使用的文本语言 程序员成功摆脱了不停地处理 UI 请求和功能增强的麻烦 而且这样还可以使用户能够自己创建脚本以及其他的工具 用来给他们所构建的应用程序创建新的行为 虽然这个例子可能有点冒险（或许会惹来几封抱怨的电子邮件） 但我还是要说 DSL 的最成功的例子就是 Microsoft® Office Excel 语言 用于表达电子表格单元格的各种计算和内容 甚至有些人认为 SQL 本身就是 DSL 但这次是一个旨在与关系数据库相交互的语言（想象一下如果程序员要通过传统 API read() / write() 调用来从 Oracle 中获取数据的话 那将会是什么样子）

这里构建的 DSL 是一个简单的计算器语言 用于获取并计算数学表达式 其实 这里的目标是要创建一个小型语言 这个语言能够允许用户来输入相对简单的代数表达式 然后这个代码来为它求值并产生结果 为了尽量简单明了 该语言不会支持很多功能完善的计算器所支持的特性 但我不也不想把它的用途限定在教学上 — 该语言一定要具备足够的可扩展性 以使读者无需彻底改变该语言就能够将它用作一个功能更强大的语言的核心 这意味着该语言一定要可以被轻易地扩展 并要尽量保持封装性 用起来不会有任何的阻碍

关于 DSL 的更多信息

DSL 这个主题的涉及面很广 它的丰富性和广泛性不是本文的一个段落可以描述得了的 想要了解更多 DSL 信息的读者可以查阅本文末尾列出的 Martin Fowler 的 正在进展中的图书 特别要注意关于 内部 和 外部 DSL 之间的讨论 Scala 以其灵活的语法和强大的功能而成为最强有力的构建内部和外部 DSL 的语言

换句话说 （最终的）目标是要允许客户机编写代码 以达到如下的目的

清单 计算器 DSL 目标

// This is Java using the Calculator String s = (( * ) + ) double result = tedneward calcdsl Calculator evaluate(s)System out println( We got + result)// Should be

我们不会在一篇文章完成所有的论述 但是我们在本篇文章中可以学习到一部分内容 在下一篇文章完成全部内容

从实现和设计的角度看 可以从构建一个基于字符串的解析器来着手构建某种可以 挑选每个字符并动态计算 的解析器 这的确极具诱惑力 但是这只适用于较简单的语言 而且其扩展性不是很好 如果语言的目标是实现简单的扩展性 那么在深入研究实现之前 让我们先花点时间想一想如何设计语言

根据那些基本的编译理论中最精华的部分 您可以得知一个语言处理器（包括解释器和编译器）的基本运算至少由两个阶段组成

●  解析器 用于获取输入的文本并将其转换成 Abstract Syntax Tree（AST）     ●  代码生成器（在编译器的情况下） 用于获取 AST 并从中生成所需字节码 或是求值器（在解释器的情况下） 用于获取 AST 并计算它在 AST 里面所发现的内容

拥有 AST 就能够在某种程度上优化结果树 如果意识到这一点的话 那么上述区别的原因就变得更加显而易见了 对于计算器 我们可能要仔细检查表达式 找出可以截去表达式的整个片段的位置 诸如在乘法表达式中运算数为 的位置（它表明无论其他运算数是多少 运算结果都会是 ）

您要做的第一件事是为计算器语言定义该 AST 幸运的是 Scala 有 case 类 一种提供了丰富数据 使用了非常薄的封装的类 它们所具有的一些特性使它们很适合构建 AST

case 类

在深入到 AST 定义之前 让我先简要概述一下什么是 case 类 case 类是使 scala 程序员得以使用某些假设的默认值来创建一个类的一种便捷机制 例如 当编写如下内容时

清单 对 person 使用 case 类

case class Person(first:String last:String age:Int){}

Scala 编译器不仅仅可以按照我们对它的期望生成预期的构造函数 — Scala 编译器还可以生成常规意义上的 equals（） toString（） 和 hashCode（） 实现 事实上 这种 case 类很普通（即它没有其他的成员） 因此 case 类声明后面的大括号的内容是可选的

清单 世界上最短的类清单

case class Person(first:String last:String age:Int)

这一点通过我们的老朋友 javap 很容易得以验证

清单 神圣的代码生成器 Batman！

C:\Projects\Exploration\Scala>javap PersonCompiled from case scala public class Person extends java lang Object implements scala ScalaObject scala Product java io Serializable{    public Person(java lang String java lang String int)    public java lang Object productElement(int)    public int productArity()    public java lang String productPrefix()    public boolean equals(java lang Object)    public java lang String toString()    public int hashCode()    public int $tag()    public int age()    public java lang String last()    public java lang String first()}

如您所见 伴随 case 类发生了很多传统类通常不会引发的事情 这是因为 case 类是要与 Scala 的模式匹配（在 集合类型 中曾简短分析过）结合使用的

使用 case 类与使用传统类有些不同 这是因为通常它们都不是通过传统的 new 语法构造而成的 事实上 它们通常是通过一种名称与类相同的工厂方法来创建的

清单 没有使用 new 语法？

object App{  def main(args : Array[String]) : Unit =  {    val ted = Person( Ted Neward )  }}

case 类本身可能并不比传统类有趣 或者有多么的与众不同 但是在使用它们时会有一个很重要的差别 与引用等式相比 case 类生成的代码更喜欢按位（biise）等式 因此下面的代码对 Java 程序员来说有些有趣的惊喜

清单 这不是以前的类

object App{  def main(args : Array[String]) : Unit =  {    val ted = Person( Ted Neward )    val ted = Person( Ted Neward )    val amanda = Person( Amanda Laucher )    System out println( ted == amanda: +      (if (ted == amanda) Yes else No ))    System out println( ted == ted: +      (if (ted == ted) Yes else No ))    System out println( ted == ted : +      (if (ted == ted ) Yes else No ))  }}/*C:\Projects\Exploration\Scala>scala Appted == amanda: Noted == ted: Yested == ted : Yes*/

case 类的真正价值体现在模式匹配中 本系列的读者可以回顾一下模式匹配（参见 本系列的第二篇文章 关于 Scala 中的各种控制构造） 模式匹配类似 Java 的 switch/case 只不过它的本领和功能更加强大 模式匹配不仅能够检查匹配构造的值 从而执行值匹配 还可以针对局部通配符（类似局部 默认值 的东西）匹配值 case 还可以包括对测试匹配的保护 来自匹配标准的值还可以绑定于局部变量 甚至符合匹配标准的类型本身也可以进行匹配

有了 case 类 模式匹配具备了更强大的功能 如清单 所示

清单 这也不是以前的 switch

case class Person(first:String last:String age:Int)object App{  def main(args : Array[String]) : Unit =  {    val ted = Person( Ted Neward )    val amanda = Person( Amanda Laucher )    System out println(process(ted))    System out println(process(amanda))  }  def process(p : Person) =  {    Processing + p + reveals that +    (p match    {      case Person(_ _ a) if a >=>        they re certainly old       case Person(_ Neward _) =>        they e from good genes       case Person(first last ageInYears) if ageInYears >=>        first + + last + is + ageInYears + years old       case _ =>        I have no idea what to do with this person     })  }}/*C:\Projects\Exploration\Scala>scala AppProcessing Person(Ted Neward ) reveals that they re certainly old Processing Person(Amanda Laucher ) reveals that Amanda Laucher is years old */

清单 中发生了很多 *** 作 下面就让我们先慢慢了解发生了什么 然后回到计算器 看看如何应用它们

首先 整个 match 表达式被包裹在圆括号中 这并非模式匹配语法的要求 但之所以会这样是因为我把模式匹配表达式的结果根据其前面的前缀串联了起来（切记 函数性语言里面的任何东西都是一个表达式）

其次 第一个 case 表达式里面有两个通配符（带下划线的字符就是通配符） 这意味着该匹配将会为符合匹配的 Person 中那两个字段获取任何值 但是它引入了一个局部变量 a p age 中的值会绑定在这个局部变量上 这个 case 只有在同时提供的起保护作用的表达式（跟在它后边的 if 表达式）成功时才会成功 但只有第一个 Person 会这样 第二个就不会了 第二个 case 表达式在 Person 的 firstName 部分使用了一个通配符 但在 lastName 部分使用常量字符串 Neward 来匹配 在 age 部分使用通配符来匹配

由于第一个 Person 已经通过前面的 case 匹配了 而且第二个 Person 没有姓 Neward 所以该匹配不会为任何一个 Person 而被触发（但是 Person（ Michael Neward ） 会由于第一个 case 中的 guard 子句失败而转到第二个 case）

第三个示例展示了模式匹配的一个常见用途 有时称之为提取 在这个提取过程中 匹配对象 p 中的值为了能够在 case 块内使用而被提取到局部变量中（第一个 最后一个和 ageInYears） 最后的 case 表达式是普通 case 的默认值 它只有在其他 case 表达式均未成功的情况下才会被触发

简要了解了 case 类和模式匹配之后 接下来让我们回到创建计算器 AST 的任务上

计算器 AST

首先 计算器的 AST 一定要有一个公用基类型 因为数学表达式通常都由子表达式组成 通过 + （ * ） 就可以很容易地看到这一点 在这个例子中 子表达式 （ * ） 将会是 + 运算的右侧运算数

事实上 这个表达式提供了三种 AST 类型

●  基表达式    ●  承载常量值的 Number 类型    ●  承载运算和两个运算数的 BinaryOperator

想一下 算数中还允许将一元运算符用作求负运算符（减号） 将值从正数转换为负数 因此我们可以引入下列基本 AST

清单 计算器 AST（src/calc scala）

package tedneward calcdsl{  private[calcdsl] abstract class Expr  private[calcdsl]  case class Number(value : Double) extends Expr  private[calcdsl]  case class UnaryOp(operator : String arg : Expr) extends Expr  private[calcdsl]  case class BinaryOp(operator : String left : Expr right : Expr)   extends Expr}

注意包声明将所有这些内容放在一个包（ tedneward calcdsl）中 以及每一个类前面的访问修饰符声明表明该包可以由该包中的其他成员或子包访问 之所以要注意这个是因为需要拥有一系列可以测试这个代码的 JUnit 测试 计算器的实际客户机并不一定非要看到 AST 因此 要将单元测试编写成 tedneward calcdsl 的一个子包

清单 计算器测试（testsrc/calctest scala）

package tedneward calcdsl test{  class CalcTest  {    import junit _ Assert _        @Test def ASTTest =    {      val n = Number( )      assertEquals( n value)    }        @Test def equalityTest =    {      val binop = BinaryOp( + Number( ) Number( ))            assertEquals(Number( ) binop left)      assertEquals(Number( ) binop right)      assertEquals( + binop operator)    }  }}

到目前为止还不错 我们已经有了 AST

再想一想 我们用了四行 Scala 代码构建了一个类型分层结构 表示一个具有任意深度的数学表达式集合（当然这些数学表达式很简单 但仍然很有用） 与 Scala 能够使对象编程更简单 更具表达力相比 这不算什么（不用担心 真正强大的功能还在后面）

接下来 我们需要一个求值函数 它将会获取 AST 并求出它的数字值 有了模式匹配的强大功能 编写这样的函数简直轻而易举

清单 计算器（src/calc scala）

package tedneward calcdsl{  //   object Calc  {    def evaluate(e : Expr) : Double =    {      e match {        case Number(x) =>x        case UnaryOp( x) =>(evaluate(x))        case BinaryOp( + x x ) =>(evaluate(x ) + evaluate(x ))        case BinaryOp( x x ) =>(evaluate(x ) evaluate(x ))        case BinaryOp( * x x ) =>(evaluate(x ) * evaluate(x ))        case BinaryOp( / x x ) =>(evaluate(x ) / evaluate(x ))      }    }  }}

注意 evaluate（） 返回了一个 Double 它意味着模式匹配中的每一个 case 都必须被求值成一个 Double 值 这个并不难 数字仅仅返回它们的包含的值 但对于剩余的 case（有两种运算符） 我们还必须在执行必要运算（求负 加法 减法等）前计算运算数 正如常在函数性语言中所看到的 会使用到递归 所以我们只需要在执行整体运算前对每一个运算数调用 evaluate（） 就可以了

大多数忠实于面向对象的编程人员会认为在各种运算符本身以外 执行运算的想法根本就是错误的 — 这个想法显然大大违背了封装和多态性的原则 坦白说 这个甚至不值得讨论 这很显然违背 了封装原则 至少在传统意义上是这样的

在这里我们需要考虑的一个更大的问题是 我们到底从哪里封装代码？要记住 AST 类在包外是不可见的 还有就是客户机（最终）只会传入它们想求值的表达式的一个字符串表示 只有单元测试在直接与 AST case 类合作

但这并不是说所有的封装都没有用了或过时了 事实上恰好相反 它试图说服我们在对象领域所熟悉的方法之外 还有很多其他的设计方法也很奏效 不要忘了 Scala 兼具对象和函数性 有时候 Expr 需要在自身及其子类上附加其他行为（例如 实现良好输出的 toString 方法） 在这种情况下可以很轻松地将这些方法添加到 Expr 函数性和面向对象的结合提供了另一种选择 无论是函数性编程人员还是对象编程人员 都不会忽略到另一半的设计方法 并且会考虑如何结合两者来达到一些有趣的效果

从设计的角度看 有些其他的选择是有问题的 例如 使用字符串来承载运算符就有可能出现小的输入错误 最终会导致结果不正确 在生产代码中 可能会使用（也许必须使用）枚举而非字符串 使用字符串的话就意味着我们可能潜在地 开放 了运算符 允许调用出更复杂的函数（诸如 abs sin cos tan 等）乃至用户定义的函数 这些函数是基于枚举的方法很难支持的

对所有设计和实现的来说 都不存在一个适当的决策方法 只能承担后果 后果自负

但是这里可以使用一个有趣的小技巧 某些数学表达式可以简化 因而（潜在地）优化了表达式的求值（因此展示了 AST 的有用性）

●  任何加上 的运算数都可以被简化成非零运算数     ●  任何乘以 的运算数都可以被简化成非零运算数     ●  任何乘以 的运算数都可以被简化成零

不止这些 因此我们引入了一个在求值前执行的步骤 叫做 simplify（） 使用它执行这些具体的简化工作

清单 计算器（src/calc scala）

    def simplify(e : Expr) : Expr =    {      e match {        // Double negation returns the original value        case UnaryOp( UnaryOp( x)) =>x        // Positive returns the original value        case UnaryOp( + x) =>x        // Multiplying x by returns the original value        case BinaryOp( * x Number( )) =>x        // Multiplying by x returns the original value        case BinaryOp( * Number( ) x) =>x        // Multiplying x by returns zero        case BinaryOp( * x Number( )) =>Number( )        // Multiplying by x returns zero        case BinaryOp( * Number( ) x) =>Number( )        // Dividing x by returns the original value        case BinaryOp( / x Number( )) =>x        // Adding x to returns the original value        case BinaryOp( + x Number( )) =>x        // Adding to x returns the original value        case BinaryOp( + Number( ) x) =>x        // Anything else cannot (yet) be simplified        case _ =>e      }    }

还是要注意如何使用模式匹配的常量匹配和变量绑定特性 从而使得编写这些表达式可以易如反掌 对 evaluate（） 惟一一个更改的地方就是包含了在求值前先简化的调用

清单 计算器（src/calc scala）

    def evaluate(e : Expr) : Double =    {      simplify(e) match {        case Number(x) =>x        case UnaryOp( x) =>(evaluate(x))        case BinaryOp( + x x ) =>(evaluate(x ) + evaluate(x ))        case BinaryOp( x x ) =>(evaluate(x ) evaluate(x ))        case BinaryOp( * x x ) =>(evaluate(x ) * evaluate(x ))        case BinaryOp( / x x ) =>(evaluate(x ) / evaluate(x ))      }    }

还可以再进一步简化 注意一下 它是如何实现只简化树的最底层的？如果我们有一个包含 BinaryOp（ * Number（ ） Number（ ）） 和 Number（ ） 的 BinaryOp 的话 那么内部的 BinaryOp 就可以被简化成 Number（ ） 但外部的 BinaryOp 也会如此 这是因为此时外部 BinaryOp 的其中一个运算数是零

我突然犯了作家的职业病了 所以我想将它留予读者来定义 其实是想增加点趣味性罢了 如果读者愿意将他们的实现发给我的话 我将会把它放在下一篇文章的代码分析中 将会有两个测试单元来测试这种情况 并会立刻失败 您的任务（如果您选择接受它的话）是使这些测试 — 以及其他任何测试 只要该测试采取了任意程度的 BinaryOp 和 UnaryOp 嵌套 — 通过

结束语

显然我还没有说完 还有分析的工作要做 但是计算器 AST 已经成形 我们无需作出大的变动就可以添加其他的运算 运行 AST 也无需大量的代码（按照 Gang of Four 的 Visitor 模式） 而且我们已经有了一些执行计算本身的工作代码（如果客户机愿意为我们构建用于求值的代码的话）

lishixinzhi/Article/program/Java/hx/201311/25735

Scala的特性

1.面向对象特性

Scala是一种纯面向对象的语言，每一个值都是对象。对象的数据类型以及行为由类和特征（Trait）描述。类抽象机制的扩展有两种途径。一种途径是子类继承，另一种途径是灵活的混入（Mixin）机制。这两种途径能避免多重继承的种种问题。

2.函数式编程

Scala也是一种函数式语言，其函数也能当成值来使用。Scala提供了轻量级的语法用以定义匿名函数，支持高阶函数，允许嵌套多层函数，并支持柯里化。Scala的CaseClass及其内置的模式匹配相当于函数式编程语言中常用的代数类型（AlgebraicType）。

更进一步，程序员可以利用Scala的模式匹配，编写类似正则表达式的代码处理XML数据。在这些情形中，顺序容器的推导式（comprehension）功能对编写公式化查询非常有用。

由于JVM不支持尾部递归，Scala也不能完全支持尾部递归优化。不过，在简单的情况下，Scala编译器可以把尾部递归优化成循环。

4.静态类型

Scala是具备类型系统，通过编译时的检查，保证代码的安全性和一致性。类型系统具体支持以下特性：

泛型类，型变注释（VarianceAnnotation），类型继承结构的上限和下限，把类别和抽象类型作为对象成员，复合类型，引用自己时显式指定类型，视图，多态方法。

5.扩展性

Scala的设计承认一个事实，即在实践中，某个领域特定的应用程序开发往往需要特定于该领域的语言扩展。Scala提供了许多独特的语言机制，可以以库的形式轻易无缝添加新的语言结构：

任何方法可用作前缀或后缀 *** 作符，可以根据预期类型自动构造闭包。联合使用以上两个特性，使你可以定义新的语句而无须扩展语法也无须使用宏之类的元编程特性。

5.使用Scala的框架

Lift是一个开源的Web应用框架，旨在提供类似RubyonRails的东西。因为Lift使用了Scala，所以Lift应用程序可以使用所有的Java库和Web容器。

scala语言主要应用领域

cala运行于JVM之上，并且它可以访问任何的java类库并且与java框架进行互 *** 作，scala也大量重用了java类型和类库。

大数据的开发语言是Scala的原因：

1：大数据的本身是计算数据，而Scala即有面向对象组织项目工程的能力，又有计算数据的功能。

2：现在大数据事实上的计算标准框架Spark，它是用Scala开发的，因为计算数据，Scala它是函数式编程，它实现算法非常简洁优雅。

例：kafka，它是一个消息中间件，如果外部数据要流进大数据中心，我们一般都要用kafka作适配器，那如果大数据中心的数据流到外部，也是用kafka（如Spark计算的数据要交给HBASE或MySql，期间我们都会用kafka），很多的大数据组件都是用的Scala编写的，所以，如果你想成为一个较高级的大数据开发高手，你一定要掌握Scala。

以前在这个版块也答过关于Scala的问题，但那更多的是知识普及，而没有谈Scala是什么，做什么，以及有怎样的特点。

Scala可怕的地方在于人人都能对它说上一二，但是不一定每个人都能明白。查看这个版块的帖子，有人把它当做Java的延伸版（一个UPenn宾大的学生Justin Kim ——此人目前在沃顿混得风生水起，当着我的面说Scala是在JVM上的脚本语言），有人把它当做JVM上的C++，有人觉得这是面对对象语言和函数语言的简单混合，有人觉得这就是Haskell，而且也还不如Haskell强。对Scala的偏见（或者是错误的见地）达到了很高的地步，Martin Odersky马丁·奥德斯基（Scala的发明者，EPFL教授）在今年夏天的Scala Day旧金山大会上发出了这张著名的玩笑照片：

gt

这个图片上的翻译是：“Scala唯一的作用是将人引向Haskell”（原谅我没法完全直译）。马丁·奥德斯基以此作为一个笑话，说他该把Scala改一下名字，叫做Hascalator，还请人设计了一个Logo。

不同的语言有不同的特点，同时也带来不同的优势。如果不能理解Scala的特点，就不可能知道如何运用Scala，以及发挥其最大的优势。一些语言有很显而易见的优势，也很容易理解，比如Python，Python的哲学（Zen of Python PEP 20 -- The Zen of Python），我很早的时候曾经觉得有道理，尤其是One way to do it（一种方法做一件事情），理由是对任何任务，虽然可以采用很多方法，但总有最好的一种方法，通过在语言或者哲学层面这样定义后，能简化程序员的任务，从而达到提高效率的方法。但经过一段时间的思考后，我突然发现Python其实并不是“一种方法做一件事”的哲学，而是“一种方法做一百万件事情”的哲学：极其有限的数据结构（只有四个: List, Tuple, Dictionary, Sets），以及不能查看时间复杂度的访问方法，比如鼓励人们使用for x in list。

这种处理方式能达到Python最初的打算：发明一种每个人都能使用的简易语言，但是对于追求速度和效率的程序员而言，这几乎是略带噩梦性质的。当然，这不是说Python很慢，通过各种优化（比如NumPy/SciPy中的），以及Cython这样的将Python直接翻译为C/C++语言又重新通过C_Module方式读回Python环境的编译器，性能可以得到不少提升，但是仍旧，Python并不追求快。

再举一个语言的例子：Java。Java的特性或者优势何在？Java的第一个优势在于它是第一个系统提供模块化（module）设计的语言（在此之前有Smalltalk存在，该货是OOP的鼻祖）。在Java之前，炒程序员鱿鱼是很困难的事情，那些C/C++程序员，以及而且尤其是那些Lisp程序员，一旦炒掉他们，新来的人没有十天半个月，甚至半年，是不可能搞懂前任人士的代码的。每个人的代码有自己的逻辑，自己的思路，写上个数万行任谁来看都头疼。这也是为什么Paul Graham保罗·格雷厄姆（写了《黑客与画家》）讲他给雅虎做了一个用Lisp写成的在线商店的案例，在他离开后，雅虎根本没法维护他写的代码，因为数万行Lisp没人能弄得很清楚。

Java的模块化，给企业、大公司带来了第一道曙光，模块化之后，这些公司不再给程序员一整个任务，而是一大块任务的一小块。接口一定义，虚拟类一定义，换谁上都可以，管你是保罗·格雷厄姆这样的明星程序员，还是一个新来的大学生，程序员不听话就直接开除，反正模块化之后，开除程序员的成本大大降低，这也是为什么谷歌、甲骨文（这货最后收购了Java）一类的公司大规模的推崇Java，还一度提出了模块化人事管理的理念（把人当模块化的积木一样随时移进移出）。

过度企业化后，这延展出了Java的第二个特性，束缚手脚。保罗·格雷厄姆在《黑客与画家》中写道，Java属于B&D（捆绑与束缚）类型的语言。为何束缚手脚？因为要让新手和明星程序员写出类似质量的代码，尽可能的抹消人的才华对程序的影响。不同于C/C++，老手和新手写出的Java代码不会有上百倍的耗时差距。但同样也导致了Java的一个弱点——不容易优化。很多优化Java代码的程序员必须要对JVM（虚拟机）进行优化，实际上增大了很多任务难度。

通过Python和Java这两个语言的优缺点，返回来看Scala，就能瞬间明白Scala的定位了。

首先，Scala不把程序员当傻子。当马丁·奥德斯基宣布Scala 2.12将要简化语法，推出Scala "Don Giovanni"项目的时候，在视频中说的很清楚：“Scala现在是为聪明人创造的，以后也是为聪明人服务的。”所以不同于Python让程序员用一种方法做所有事情，Scala提供一整套工具，让程序员自由选择，无论是mutable数据结构，immutable数据结构，并行（parallel）数据结构。然后在这些选择中，Scala再针对他们进行算法层面的特殊优化。Scala相信程序员的聪明才智，让程序员自行选择合适的结构，以针对变化万千的任务需求，这点是Scala做得极好的地方。

再者，有人会说immutable数据结构占用内存，或者速度很慢。这是真的，但这不是Scala的错，而是这些结构就是这样定义的。这里讲的是Scala集合的运行速度，是一个来自Goldman Sachs的程序员讲他们为Java写的集合库（GSCollection）速度和内存消耗，但同时比较了gs-collection（goldmansachs/gs-collections · GitHub），Java，和Scala库的速度。最后Scala的可变集合mutable原生库完爆Java，和gs-collection基本持平。

Scala的第二个优势，相较于Java而言，则是相信程序员的优化能力。在Scala with Style讲话中（），马丁·奥德斯基说：“很多程序员会告诉我，他们一般会重构他们的Scala代码两三次，甚至三四次。”这听起来似乎非常的没有效率，但Scala就是这样的语言，每一次重构，代码的性能或者是可读性都会有极高的提升。

之前就有人提到过，Scala新手和老手写出来的代码完全会呈现两种不同的风格，甚至新人根本不能读懂有经验的Scala程序员所写的代码，有人于是戏称：“太好了，这样的话我们部门的实习生就不能乱碰我写的代码啦！”但其实不仅风格不同，执行效率差距也一定是巨大的。Scala提供一整套工具，但是要明白什么时候用拿一种工具，哪些算法能够随意调用，哪些算法不能，这一定要依靠经验、研究和学习以及对源代码的理解才能得知。最简单的例子，Scala的foreach()方法是高度优化过了的（尤其针对Range结构和Vector结构），但是fold()就不一定了。或者当受到诱惑想用zipWithIndex()的时候，一定要明白这是两次循环，最好改用Vector(...).indices.foreach()的方法，或者用.view来推迟执行。

像这样的地方还有很多。所以在这个层面上来讲，简直和C++非常的相似。从另外一个层面来讲，不仅仅是要理解语言层面的优化，Scala作为一个社区而言，是非常追求运行速度的。Ruby社区就完全不同了，Ruby曾经是推特的主要语言。推特的团队找到了Ruby团队，说，你们能不能让Ruby运行的快一点，我们有这个这个和这个建议。Ruby直接把这些建议拒绝了，因为它们会增加语言复杂度，让Ruby不能继续做一个“fun”（好玩）的语言。而Python直接就立志做一个“Simple”（简单）的语言了。于是推特只好将后台换做Scala和Java的结合。有一位在推特工作的知乎友人在我的一个回答下留言说推特换用Scala后，TypeSafe（Scala的母公司）还送去了一个蛋糕。

为了追求速度，Scala社区是绝对不会管所谓的“简单”或者是“好玩”，怎样有效率就怎样弄。与其专注于JVM的改进，Scala社区大部分在编译器上下功夫，比如很著名的Miniboxing（Miniboxing），这是一个编译器增进器。Miniboxing做的是什么呢？只做一件事：防止auto-boxing和auto-unboxing。所有的泛型，尤其是原生类泛型（Primitive Types），诸如Int、Double等等，在进行各种 *** 作的时候会自动取出和装回它们所属的类中去——这个我解释的不太好，但是可以看这里（Java 自动装箱与拆箱(Autoboxing and unboxing)）。

Miniboxing这样的插件可以让所有的原生类泛型再也不用自动装拆箱，从而将Scala的运行速度提升1.5倍到22倍（）。当然这样的东西可不是白来的，这是马丁·奥德斯基的PhD博士学生做的一个研究项目，然后为OOPSLA写了一篇论文（），所以怪不得这玩意Scala可以有，但其他语言想要有都没有。

另一个Scala的很大优势就是所谓的Macro——宏。宏本身作为元编程而言，其实和运行速度是没有什么太大关系的，反而，因为对反射（Reflect）的利用，可能会影响到速度。但Scala社区对宏的理解显然和最初的设计理念有偏差。因为Scala本身是没有传统意义的循环的（for-loop），所以很多时候循环必须利用while或者foreach。但是部分追求效率的Scala程序员们利用宏为Scala写了一个传统循环，叫做cfor，被收录在Spire（non/spire · GitHub）数学计算库中。cfor的写法如下：

import spire.syntax.cfor._// print numbers 1 through 10cfor(0)(_ <10, _ + 1) { i =>

println(i)}

而这玩意运行效率如何呢？文章中做了一次测评，将cfor和zip写的一个算法作比较——在公布结果之前，我想说的是，zip并不是一个高度优化的方法，所以本身就慢很多，cfor用了26.1毫秒运行，zip方法用了7.4 秒运行，这几乎是284倍的速度差距。

通过这两点，Scala的一个优势就很明显了——多样化。当需要写简单的代码，像Python一样当脚本语言使用时，Scala提供大量的原生方法和数据结构，可以很轻松的写出比较复杂的 *** 作。但当需要速度的时候，又可以通过重构来获取数十倍或者上百倍的速度提升。通过Miniboxing一类的编译器增强器，Scala在某些 *** 作的速度是必定超过Java的。

Scala的第二个优势就是——一帮勤劳勇敢的PhD博士生。二十一世纪的程序语言和二十世纪的程序语言已经不能比拟了。那个年代的普通人（甚至是学生）还能任意发明一下语言，稍微把编译器优化几次就能上得了厅堂（比如那一大堆Lisp方言），到了这个年代，编译技术已经达到了很复杂的程度（虚拟机技术也是如此），优化和语义理解，程序语言的定义与延展，再也不是随便任何人都能搞定的工作了。作为编程语言方面的教授，马丁·奥德斯基不断的将最前沿的学术界成果转移到Scala这个语言中，还让他的博士学生发展出新的，让语言运行得更快的方法，这些都是其他语言，尤其是Python、Ruby、甚至是Go都没有的优势。

当然，说了这么多，总会有人说了，Scala如果像C++一样难，又追求速度的话，为什么不直接去学C++，原因很简单——现在有很多在JVM上面写成的软件啊！大家又不是Haskell程序员，压根不打算一切自己写呐。

---