为什么选择Scala

如果你是一名Java程序员，并且关注这编程语言方面的发展，比如经常去TIOBE网站了解编程语言流行度排行，那么你应该听说过Scala，如果你还没有开始学习Scala，或者打算下个礼拜开始学的话，请先看看下面这篇文章，看看能不能改变你的想法。下面的内容为Programming In Scala 这本书的节选，到目前为止，国内好像还没引进，你可以从亚马逊上面购买http://booksites.artima.com/programming_in_scala (有国内的朋友翻译了其中的前11章，真是非常感谢)， 

   Scala是为你准备的吗？你必须自己看明白并做决定。除了伸展性之外，我们发现喜欢用Scala编程实际上还有很多理由。最重要的四个将在本节讨论的方面该是：兼容性，简短，高层级抽象和高级的静态类别。

 Scala是兼容的

<!--endfragment-->

   Scala不需要你从Java平台后退两步然后跳到Java语言前面去。它允许你在现存代码中加点儿东西——在你已有的东西上建设——因为它被设计成无缝地与Java实施互操作。Scala程序会被编译为JVM的字节码。它们的执行期性能通常与Java程序一致。Scala代码可以调用Java方法，访问Java字段，继承自Java类和实现Java接口。这些都不需要特别的语法，显式接口描述，或粘接代码。实际上，几乎所有Scala代码都极度依赖于Java库，而经常无须在程序员意识到这点。

   交互式操作的另一个方面是Scala极度重用了Java类型。Scala的Int类型代表了Java的原始整数类型int，Float代表了float，Boolean代表boolean，等等。Scala的数组被映射到Java数组。Scala同样重用了许多标准Java库类型。例如，Scala里的字串文本"abc"是java.lang.String，而抛出的异常必须是java.lang.Throwable的子类。

   Scala不仅重用了Java的类型，还把它们“打扮”得更漂亮。例如，Scala的字串支持类似于toInt和toFloat的方法，可以把字串转换成整数或者浮点数。因此你可以写str.toInt替代Integer.parseInt(str)。如何在不打破互操作性的基础上做到这点呢？Java的String类当然不会有toInt方法。实际上，Scala有一个解决这种高级库设计和互操作性不相和谐的通用方案。Scala可以让你定义隐式转换：implicit conversion，这常常用在类型失配，或者选用不存在的方法时。在上面的例子里，当在字串中寻找toInt方法时，Scala编译器会发现String类里没有这种方法，但它会发现一个把Java的String转换为Scala的RichString类的一个实例的隐式转换，里面定义了这么个方法。于是在执行toInt操作之前，转换被隐式应用。

    Scala代码同样可以由Java代码调用。有时这种情况要更加微妙，因为Scala是一种比Java更丰富的语言，有些Scala更先进的特性在它们能映射到Java前需要先被编码一下。第29章说明了其中的细节。

 Scala是简洁的

<!--endfragment-->

    Scala程序一般都很短。Scala程序员曾报告说与Java比起来代码行数可以减少到1/10。这有可能是个极限的例子。较保守的估计大概标准的Scala程序应该有Java写的同样的程序一半行数左右。更少的行数不仅意味着更少的打字工作，同样意味着更少的话在阅读和理解程序上的努力及更少的出错可能。许多因素在减少代码行上起了作用。

    首先，Scala的语法避免了一些束缚Java程序的固定写法。例如，Scala里的分号是可选的，且通常不写。Scala语法里还有很多其他的地方省略了东西。比方说，比较一下你在Java和Scala里是如何写类及构造函数的。在Java里，带有构造函数的类经常看上去是这个样子：

// 在Java里
class MyClass {
    private int index;
    private String name;
    public MyClass(int index, String name) {
        this.index = index;
        this.name = name;
    }
}

   在Scala里，你会写成这样：

class MyClass(index: Int, name: String)

   根据这段代码，Scala编译器将制造有两个私有成员变量的类，一个名为index的Int类型和一个叫做name的String类型，还有一个用这些变量作为参数获得初始值的构造函数。这个构造函数还将用作为参数传入的值初始化这两个成员变量。一句话，你实际拿到了与罗嗦得多的Java版本同样的功能。Scala类写起来更快，读起来更容易，最重要的是，比Java类更不容易犯错。

<!--endfragment-->

   有助于Scala的简洁易懂的另一个因素是它的类型推断。重复的类型信息可以被忽略，因此程序变得更有条理和易读。

   但或许减少代码最关键的是因为已经存在于你的库里而不需要写的代码。Scala给了你许多工具来定义强有力的库让你抓住并提炼出通用的行为。例如，库类的不同方面可以被分成若干特质，而这些有可以被灵活地混合在一起。或者，库方法可以用操作符参数化，从而让你有效地定义那些你自己控制的构造。这些构造组合在一起，就能够让库的定义既是高层级的又能灵活运用。

  Scala是高层级的

    程序员总是在和复杂性纠缠。为了高产出的编程，你必须明白你工作的代码。过度复杂的代码成了很多软件工程崩溃的原因。不幸的是，重要的软件往往有复杂的需求。这种复杂性不可避免；必须（由不受控）转为受控。

<!--endfragment-->

    Scala可以通过让你提升你设计和使用的接口的抽象级别来帮助你管理复杂性。例如，假设你有一个String变量name，你想弄清楚是否String包含一个大写字符。在Java里，你或许这么写：

// 在Java里
boolean nameHasUpperCase = false;
for (int i = 0; i < name.length(); ++i) {
    if (Character.isUpperCase(name.charAt(i))) {
        nameHasUpperCase = true;
        break;
    }
}

   在Scala里，你可以写成：

val nameHasUpperCase = name.exists(_.isUpperCase)

    Java代码把字串看作循环中逐字符步进的低层级实体。Scala代码把同样的字串当作能用论断：predicate查询的字符高层级序列。明显Scala代码更短并且——对训练有素的眼睛来说——比Java代码更容易懂。因此Scala代码在通盘复杂度预算上能极度地变轻。它也更少给你机会犯错。

    论断，_.isUpperCase，是一个Scala里面函数式文本的例子。它描述了带一个字符参量（用下划线字符代表）的函数，并测试其是否为大写字母。

    原则上，这种控制的抽象在Java中也是可能的。为此需要定义一个包含抽象功能的方法的接口。例如，如果你想支持对字串的查询，就应引入一个只有一个方法hasProperty的接口CharacterProperty：

// 在Java里
interface CharacterProperty {
    boolean hasProperty(char ch);
}

    然后你可以在Java里用这个接口格式一个方法exists：它带一个字串和一个CharacterProperty并返回真如果字串中有某个字符符合属性。然后你可以这样调用exists：

// 在Java里
exists(name, new CharacterProperty {
    boolean hasProperty(char ch) {
        return Character.isUpperCase(ch);
    }
});

    然而，所有这些真的感觉很重。重到实际上多数Java程序员都不会惹这个麻烦。他们会宁愿写个循环并漠视他们代码里复杂性的累加。另一方面，Scala里的函数式文本真地很轻量，于是就频繁被使用。随着对Scala的逐步了解，你会发现越来越多定义和使用你自己的控制抽象的机会。你将发现这能帮助避免代码重复并因此保持你的程序简短和清晰。

<!--endfragment-->

Scala是静态类型的

    静态类型系统认定变量和表达式与它们持有和计算的值的种类有关。Scala坚持作为一种具有非常先进的静态类型系统的语言。从Java那样的内嵌类型系统起步，能够让你使用泛型：generics参数化类型，用交集：intersection联合类型和用抽象类型：abstract type隐藏类型的细节。这些为建造和组织你自己的类型打下了坚实的基础，从而能够设计出即安全又能灵活使用的接口。<!--endfragment-->

    如果你喜欢动态语言如Perl，Python，Ruby或Groovy，你或许发现Scala把它的静态类型系统列为其优点之一有些奇怪。毕竟，没有静态类型系统已被引为动态语言的某些主要长处。绝大多数普遍的针对静态类型的论断都认为它们使得程序过度冗长，阻止程序员用他们希望的方式表达自己，并使软件系统动态改变的某些模式成为不可能。然而，这些论断经常针对的不是静态类型的思想，而是指责特定的那些被意识到太冗长或太不灵活的类型系统。例如，Alan Kay，Smalltalk语言的发明者，有一次评论：“我不是针对类型，而是不知道有哪个没有完痛的类型系统，所以我还是喜欢动态类型。”

    我们希望能在书里说服你，Scala的类型系统是远谈不上会变成“完痛”。实际上，它漂亮地说明了两个关于静态类型通常考虑的事情（的解决方案）：通过类型推断避免了赘言和通过模式匹配及一些新的编写和组织类型的办法获得了灵活性。把这些绊脚石搬掉后，静态类型系统的经典优越性将更被赏识。其中最重要的包括程序抽象的可检验属性，安全的重构，以及更好的文档。

可检验属性。静态类型系统可以保证消除某些运行时的错误。例如，可以保证这样的属性：布尔型不会与整数型相加；私有变量不会从类的外部被访问；函数带了正确个数的参数；只有字串可以被加到字串集之中。

    不过当前的静态类型系统还不能查到其他类型的错误。比方说，通常查不到无法终结的函数，数组越界，或除零错误。同样也查不到你的程序不符合式样书（假设有这么一份式样书）。静态类型系统因此被认为不很有用而被忽视。舆论认为既然这种类型系统只能发现简单错误，而单元测试能提供更广泛的覆盖，又为何自寻烦恼呢？我们认为这种论调不对头。尽管静态类型系统确实不能替代单元测试，但是却能减少用来照顾那些确需测试的属性的单元测试的数量。同样，单元测试也不能替代静态类型。总而言之，如Edsger Dijkstra所说，测试只能证明存在错误，而非不存在。因此，静态类型能给的保证或许很简单，但它们是无论多少测试都不能给的真正的保证。

安全的重构。静态类型系统提供了让你具有高度信心改动代码基础的安全网。试想一个对方法加入额外的参数的重构实例。在静态类型语言中，你可以完成修改，重编译你的系统并容易修改所有引起类型错误的代码行。一旦你完成了这些，你确信已经发现了所有需要修改的地方。对其他的简单重构，如改变方法名或把方法从一个类移到另一个，这种确信都有效。所有例子中静态类型检查会提供足够的确认，表明新系统和旧系统可以一样的工作。

文档。静态类型是被编译器检查过正确性的程序文档。不像普通的注释，类型标注永远都不会过期（至少如果包含它的源文件近期刚刚通过编译就不会）。更进一步说，编译器和集成开发环境可以利用类型标注提供更好的上下文帮助。举例来说，集成开发环境可以通过判定选中表达式的静态类型，找到类型的所有成员，并全部显示出来。

    虽然静态类型对程序文档来说通常很有用，当它们弄乱程序时，也会显得很讨厌。标准意义上来说，有用的文档是那些程序的读者不可能很容易地从程序中自己想出来的。在如下的方

 

           def f(x: String) = ...

    知道f的变量应该是String是有用的。另一方面，以下例子中两个标注至少有一个是讨厌的：

           val x: HashMap[Int, String] = new HashMap[Int, String]()

    很明显，x是以Int为键，String为值的HashMap这句话说一遍就够了；没必要同样的句子重复两遍。

    Scala有非常精于此道的类型推断系统，能让你省略几乎所有的通常被认为是讨厌的类型信息。在上例中，以下两个不太讨厌的替代品也能一样工作：

          val x = new HashMap[Int, String]()

          val x: Map[Int, String] = new HashMap()

     Scala里的类型推断可以走的很远。实际上，就算用户代码丝毫没有显式类型也不稀奇。因此，Scala编程经常看上去有点像是动态类型脚本语言写出来的程序。尤其显著表现在作为粘接已写完的库控件的客户应用代码上。而对库控件来说不是这么回事，因为它们常常用到相当精妙的类型去使其适于灵活使用的模式。这很自然。综上，构成可重用控件接口的成员的类型符号应该是显式给出的，因为它们构成了控件和它的使用者间契约的重要部分。

   不过，目前对于Scala来说，最大的问题是缺少一个优秀的IDE，真希望Eclipse 基金会能出手拯救这个局面！

 

 

评论

33 楼 cscript 2009-08-07  

引用

人家几十年前 Lisp 里面就用 fst 和 snd 了，源远流长，给你改成 0 才不妥呢。

源远流长又咋样，能说明一个下标从1开始一个下标从0开始是合理的吗, MIT源远流长的6.001不是被Python取代了吗？再说C语言的历史不比lisp短多少。

32 楼 yiding_he 2009-08-07  

我觉得我们可以以更积极的眼光去看 Scala：

1、语法问题。如果你舍得花时间学 Python、Ruby，那你也可以舍得花时间学 Scala，而且时间肯定比这两个要少，因为有现成的你已经非常熟悉的类库可用；

2、Scala 和 Groovy，一个是静态的，一个是动态的，二者都是 Java 很好的补充。

3、我觉得类型推断是亮点。

31 楼 maddogfyg 2009-08-07  

引用

但他有些地方过头了,比如元组tuple(就是可以放不同类型的元素的list),下标居然从1开始,而且是_1,_2这样,他们的解释是:"因为对于拥有静态类型元组的其他语言，如Haskell和ML，从1开始是传统的设定。"我狂吐血!tnnd你总的和list的访问方式一致吧,起始下标一个是0,一个是1,还让不让人活了,就我而言,以后如果编程时遇到这两种列表中特定位置取值,肯定要多想一想下标的问题,这就超出了语法的问题了,是真正让人感觉无法接受的.

人家几十年前 Lisp 里面就用 fst 和 snd 了，源远流长，给你改成 0 才不妥呢。
tuple 是定长的，访问方式和数组、链表不一样，tuple 如果做成下标取值方式，所有函数的调用性能都会慢一大截 ……
你不满意可以把它转成 Seq 再用下标取值。

你不爽是因为被 java 毒害太久了。

老兄没明白我的重点，我真的不介意他是从0开始还是从1开始，事实上对于所有的语言，我觉得从1开始更自然，更能减轻程序员的负担，毕竟更符合日常思维。我的不满，是他把tuple和list两个非常类似的东西搞得不一致，这加重了程序员的思维负担。你和别的语言差的再多也无所谓，但不要语言中搞这种不一致的思维方式。
我对于语法的异同，基本不太在意，程序语言这点不同不算什么，法语、西班牙语的动词变位那么变态不是还有很多人乐此不疲的去学，但语言的设计必须要尽可能地减少程序员负担，减少可能出现的问题，如果哪位熬夜加班的程序员脑子短路把tuple当作从0开始，我觉得scala语言或者说设计者本身是有责任的。我对于scala是相当看好的，只是希望它能更符合大众程序员的需要。

从另一个角度讲，如果scala是完全的自成一派，我想大家也就不会有这么多怨言了，但它既然继承了java这么多的东西，并希望它能取代java，就应该对广大java程序员负责，减轻转换负担，尤其是这完全没有技术上的难度。

30 楼 cscript 2009-08-07  

引用

对于不愿学习新东西的人来说，所有新特性都是“生僻”的，任何转向都是不容易的。

这句话的前提是错误的，因为scala的很多特性根本就不是新东西。C#、Scala都有数组、模板，但是C#采用的语法和大部分已有的编程语言是相同的，所以我觉得C#比scala简单，scala的数组、模板有什么本质提高的地方吗？

引用

举个例子来说，拿C# 3.0和C# 1.0比较，也可以套用同样的说辞。

这个例子举的不准，新版本C#有模板、类型推理等C# 1.0没有的特性，相对于C# 1.0来说是有意义的创新。但是，C#1.0相对于Java来说，把synchornized改为lock、super改为base的行为就是属于典型的“为了不同而不同”。

29 楼 pure 2009-08-07  

sekiyika 写道

pure 写道

现在的ide感觉真没法用一样，Eclipse和Netbeans的插件都没成功运行过Scala，失望，尽快解决IDE的问题就大有作为了。

NB的插件还是不错的吧，说什么也是dcaoyuan他们搞的，有一些动能确实还没有实现，不过自己稍微修改一下，添加一点Ant脚本也都解决的。个人觉得NB的插件比eclipse好用很多

现在可以用了，还不错。

28 楼 night_stalker 2009-08-07  

maddogfyg 写道

Martin Odersky研究编程语言20多年,接触研究过非常多种语言,scala也不是他第一个发明的,因此scala的语法来源非常广,这不能说是scala的问题,我总觉得程序员不应该将语法作为一种语言好坏的理由.
很多scala中的"不同",也是有其意义的,比如[]改成(),是因为"与Java比Scala很少有特例。数组和Scala里其他的类一样只是类的实现。当你在一个或多个值或变量外使用括号时，Scala会把它转换成对名为apply的方法调用。于是greetStrings(i)转换成greetStrings.apply(i)。所以Scala里访问数组的元素也只不过是跟其它的一样的方法调用。"当然,其实他们还是可以做成[],但有这个理由,起码是有情可原的.

使用 () 还有一个原因是要把 [] 用于泛型。
泛型用 <> 时，大于号和小于号的多义性会给语法解析（尤其是支持操作符重载的语言）带来一大堆问题。
（最典型的就是 VC6 里面模板嵌套一定要加个空格）

引用

但他有些地方过头了,比如元组tuple(就是可以放不同类型的元素的list),下标居然从1开始,而且是_1,_2这样,他们的解释是:"因为对于拥有静态类型元组的其他语言，如Haskell和ML，从1开始是传统的设定。"我狂吐血!tnnd你总的和list的访问方式一致吧,起始下标一个是0,一个是1,还让不让人活了,就我而言,以后如果编程时遇到这两种列表中特定位置取值,肯定要多想一想下标的问题,这就超出了语法的问题了,是真正让人感觉无法接受的.

人家几十年前 Lisp 里面就用 fst 和 snd 了，源远流长，给你改成 0 才不妥呢。
tuple 是定长的，访问方式和数组、链表不一样，tuple 如果做成下标取值方式，所有函数的调用性能都会慢一大截 ……
你不满意可以把它转成 Seq 再用下标取值。

你不爽是因为被 java 毒害太久了。

27 楼 hax 2009-08-07  

icanfly 写道

我觉得曾经有一篇文章说得非常好。大家可以看下，其中一句非常经典：为什么事情非要为了不同而不同？
一语点中scala的生辟语法。这使得从JAVA转向过来变得非常不容易。

拜托你先说明一下，scala哪点是“为了不同而不同”

对于不愿学习新东西的人来说，所有新特性都是“生僻”的，任何转向都是不容易的。


举个例子来说，拿C# 3.0和C# 1.0比较，也可以套用同样的说辞。

26 楼 hax 2009-08-07  

cscript 写道

文章花了很大的篇幅说明静态类型的好处，但是静态类型的好处并不是scala独有的，效率、可检验属性、安全重构等等特性，哪家静态类型语言没有啊？都21世纪了，还把这些当成自己的特色。至于类型推理、匿名函数，新版的C#、C++都有这些特性，又不是scala的专利。

有人对scala的评价如下，我觉的很有道理：
C# 3.0 has a lot of the features that Scala has and they are much more palatable than the way Scala implements them. Why come up with a non-mainstream syntax for existing feature?

简单的说，这些语法糖大家都能想到，干嘛故意搞的和主流语法不一样？

你跟java程序员推销C#和C++？

你的问题很奇怪，按照你的理论，有了ruby，其他动态语言，比如groovy、javascript也可以歇菜了。

25 楼 hax 2009-08-07  

prowl 写道

和groovy相比又好在哪?

静态类型。

24 楼 vwpolo 2009-08-07  

其实我觉得现在Scala的语言挺优美的，设计的很合理，当然如果你还是以看Java的习惯来对待Scala，难免会有不同意见，我觉得Scala在语法简洁性和易读性还是平衡的很好，毕竟，语法不应该成为你学习语言的障碍

23 楼 cscript 2009-08-07  

引用

但他有些地方过头了,比如元组tuple(就是可以放不同类型的元素的list),下标居然从1开始,而且是_1,_2这样,他们的解释是:"因为对于拥有静态类型元组的其他语言，如Haskell和ML，从1开始是传统的设定。"我狂吐血!tnnd你总的和list的访问方式一致吧,起始下标一个是0, 一个是1,还让不让人活了

如果能够做出真正有意义的创新，语法怪异点也就忍了，没本事却要硬装着与众不同，还企图取代这个那个，groovy就比它务实多了。

22 楼 maddogfyg 2009-08-07  

cscript 写道

文章花了很大的篇幅说明静态类型的好处，但是静态类型的好处并不是scala独有的，效率、可检验属性、安全重构等等特性，哪家静态类型语言没有啊？都21世纪了，还把这些当成自己的特色。至于类型推理、匿名函数，新版的C#、C++都有这些特性，又不是scala的专利。

有人对scala的评价如下，我觉的很有道理：
C# 3.0 has a lot of the features that Scala has and they are much more palatable than the way Scala implements them. Why come up with a non-mainstream syntax for existing feature?

简单的说，这些语法糖大家都能想到，干嘛故意搞的和主流语法不一样？

Martin Odersky研究编程语言20多年,接触研究过非常多种语言,scala也不是他第一个发明的,因此scala的语法来源非常广,这不能说是scala的问题,我总觉得程序员不应该将语法作为一种语言好坏的理由.
很多scala中的"不同",也是有其意义的,比如[]改成(),是因为"与Java比Scala很少有特例。数组和Scala里其他的类一样只是类的实现。当你在一个或多个值或变量外使用括号时，Scala会把它转换成对名为apply的方法调用。于是greetStrings(i)转换成greetStrings.apply(i)。所以Scala里访问数组的元素也只不过是跟其它的一样的方法调用。"当然,其实他们还是可以做成[],但有这个理由,起码是有情可原的.
但他有些地方过头了,比如元组tuple(就是可以放不同类型的元素的list),下标居然从1开始,而且是_1,_2这样,他们的解释是:"因为对于拥有静态类型元组的其他语言，如Haskell和ML，从1开始是传统的设定。"我狂吐血!tnnd你总的和list的访问方式一致吧,起始下标一个是0,一个是1,还让不让人活了,就我而言,以后如果编程时遇到这两种列表中特定位置取值,肯定要多想一想下标的问题,这就超出了语法的问题了,是真正让人感觉无法接受的.

21 楼 fyting 2009-08-06  

F#?
字数字数

20 楼 sekiyika 2009-08-06  

pure 写道

现在的ide感觉真没法用一样，Eclipse和Netbeans的插件都没成功运行过Scala，失望，尽快解决IDE的问题就大有作为了。

NB的插件还是不错的吧，说什么也是dcaoyuan他们搞的，有一些动能确实还没有实现，不过自己稍微修改一下，添加一点Ant脚本也都解决的。个人觉得NB的插件比eclipse好用很多

19 楼 lixjluck 2009-08-06  

学学scala，拓宽一下自己的技术视野
程序原来还可以这样写。

18 楼 night_stalker 2009-08-06  

代码虽然还不如 ruby 那么简洁易读，但已经比 java 好上一些数量级了。

Nown-Oriented Thinking 写道

For the lack of a nail,
    throw new HorseshoeNailNotFoundException("no nails!");

For the lack of a horseshoe,
    EquestrianDoctor.getLocalInstance().getHorseDispatcher().shoot();

For the lack of a horse,
    RidersGuild.getRiderNotificationSubscriberList().getBroadcaster().run(
      new BroadcastMessage(StableFactory.getNullHorseInstance()));

For the lack of a rider,
    MessageDeliverySubsystem.getLogger().logDeliveryFailure(
      MessageFactory.getAbstractMessageInstance(
        new MessageMedium(MessageType.VERBAL),
        new MessageTransport(MessageTransportType.MOUNTED_RIDER),
        new MessageSessionDestination(BattleManager.getRoutingInfo(
                                        BattleLocation.NEAREST))),
      MessageFailureReasonCode.UNKNOWN_RIDER_FAILURE);

For the lack of a message,
    ((BattleNotificationSender)
      BattleResourceMediator.getMediatorInstance().getResource(
        BattleParticipant.PROXY_PARTICIPANT,
        BattleResource.BATTLE_NOTIFICATION_SENDER)).sendNotification(
          ((BattleNotificationBuilder)
            (BattleResourceMediator.getMediatorInstance().getResource(
            BattleOrganizer.getBattleParticipant(Battle.Participant.GOOD_GUYS),
            BattleResource.BATTLE_NOTIFICATION_BUILDER))).buildNotification(
              BattleOrganizer.getBattleState(BattleResult.BATTLE_LOST),
              BattleManager.getChainOfCommand().getCommandChainNotifier()));

For the lack of a battle,
    try {
        synchronized(BattleInformationRouterLock.getLockInstance()) {
          BattleInformationRouterLock.getLockInstance().wait();
        }
    } catch (InterruptedException ix) {
      if (BattleSessionManager.getBattleStatus(
           BattleResource.getLocalizedBattleResource(Locale.getDefault()),
           BattleContext.createContext(
             Kingdom.getMasterBattleCoordinatorInstance(
               new TweedleBeetlePuddlePaddleBattle()).populate(
                 RegionManager.getArmpitProvince(Armpit.LEFTMOST)))) ==
          BattleStatus.LOST) {
        if (LOGGER.isLoggable(Level.TOTALLY_SCREWED)) {
          LOGGER.logScrewage(BattleLogger.createBattleLogMessage(
            BattleStatusFormatter.format(BattleStatus.LOST_WAR,
                                         Locale.getDefault())));
        }
      }
    }

For the lack of a war,
    new ServiceExecutionJoinPoint(
      DistributedQueryAnalyzer.forwardQueryResult(
        NotificationSchemaManager.getAbstractSchemaMapper(
          new PublishSubscribeNotificationSchema()).getSchemaProxy().
            executePublishSubscribeQueryPlan(
              NotificationSchema.ALERT,
              new NotificationSchemaPriority(SchemaPriority.MAX_PRIORITY),
              new PublisherMessage(MessageFactory.getAbstractMessage(
                MessageType.WRITTEN,
                new MessageTransport(MessageTransportType.WOUNDED_SURVIVOR),
                new MessageSessionDestination(
                  DestinationManager.getNullDestinationForQueryPlan()))),
              DistributedWarMachine.getPartyRoleManager().getRegisteredParties(
                PartyRoleManager.PARTY_KING ||
                PartyRoleManager.PARTY_GENERAL ||
                PartyRoleManager.PARTY_AMBASSADOR)).getQueryResult(),
        PriorityMessageDispatcher.getPriorityDispatchInstance())).
      waitForService();

All for the lack of a horseshoe nail.

17 楼 cscript 2009-08-06  

文章花了很大的篇幅说明静态类型的好处，但是静态类型的好处并不是scala独有的，效率、可检验属性、安全重构等等特性，哪家静态类型语言没有啊？都21世纪了，还把这些当成自己的特色。至于类型推理、匿名函数，新版的C#、C++都有这些特性，又不是scala的专利。

有人对scala的评价如下，我觉的很有道理：
C# 3.0 has a lot of the features that Scala has and they are much more palatable than the way Scala implements them. Why come up with a non-mainstream syntax for existing feature?

简单的说，这些语法糖大家都能想到，干嘛故意搞的和主流语法不一样？

16 楼 prowl 2009-08-06  

和groovy相比又好在哪?

15 楼 bonny 2009-08-06  

楼主举那些好处都不重要，这些好处java带来的是语法和代码更难理解，只怕不是什么好现象。
况且这些语法糖的实际功能，java也可能完成，不过是代码数量的差别——这种差别并不是数量级的，但是可读性差别就大了。

actor应该是最大的好处。

所以，多数场合还是java的好。

scala我已经学几个星期了，仔细考虑过合适的应用场景，并没看起来那么美。groovy好处还是多一点（如同robin说的，并不纯粹，异常等很难理解），groovy适合做脚本和黏合剂，测试等方便而不重要的地方。

14 楼 accphc 2009-08-06  

飘过～～，