【IT168资讯】本文是从 Yes, Virginia, Scala is hard 这篇文章翻译而来。首先要说的是，我是一个 Scala 粉丝，我作为一个 Scala 语言的倡导者差不多有5年历史了。我写了不少 Scala 语言方面的书和文章。我曾在数十个公司里做过 Scala 和 Lift 框架项目的开发。我对很多的 Scala 项目进行过代码审查。

　　我过去以为 Scala 很简单。它过去确实很简单，而且一直很简单，它是治疗 Java 里很多问题的良方。从“有些使用Java 显的异常的困难或不可能的事，使用 Scala 却非常容易”的角度，Scala 是一种非常简单的语言。Scala 处理集合问题超级的容易。业务逻辑的相互独立会使程序变得更容易维护，Scala 相对 Java 来说更方便达到这样的目标。

　　那么，Scala 难在哪里?下面是我能想出的最主要的几条：

　　Scala 想要的东西太多。你可以拿 Scala 像 Java 那样编程。这是一种福气，也是一种诅咒，但我从长远的角度看，更多的是一种诅咒。关于它的面向对象 vs 面向函数的争议太多。对于小的开发团队，这些争议和你所采取的选择关系不大，但当你的团队有相当的人数，你试图教会这些 Java 程序员使用 Scala，而他们又非真心的想学时，这成了相当讨厌的事。Scala 语言的巨大优势会在你使用函数式编程时不言自明的显露出来，但如果你只把自己当成面向对象的程序员，它的优势你是不可能看到的。对于这种情况，较少功能特征/可选性的语言(例如 Java 或 Ruby)就显得容易些。你不用费脑筋去做出选择。

　　集成开发工具对它的支持很弱，而且以后也不会改善。Scala 的 Eclipse 插件很差劲。从此我开始使用 Scala 语言五年来一直很差劲，它总是让人感觉“可以做的更好”，但却一直这样差劲。IntelliJ 对 Scala 的支持还凑合。但在 IDE 里需要使用各种模式的人会找不到一个好用的。Scala 的模式各式各样又互不关联，如果你不讨厌使用 Emacs 或 Vi 或 TextMate 编程，那使用 IntelliJ 开发 Scala 是个不错的选择。如果你期待着一个像 Java IDE 那样的东西，你找不到，而且永远找不到，因为 Scala 的强大能力是不能通过简单的模板表现出来的，你需要提供太多的信息资源给 IDE，它里面的类型安全(TypeSafe)检查的复杂，即使你银行里有3百万美元，也没有公司敢出来担保。

　　Scala 的类型系统异常的强大，但它却让你茫然不知所措。在 ScalaDocs 里，类型符号复杂的让人恐怖。看着flatMap [B, That] (f: (A) ⇒ Traversable[B])(implicit bf: CanBuildFrom[List[A], B, That]) : That，是不是会让你有想逃的感觉?这是一个初学者每天都会用，一天用20次的方法，很恐怖吧。Scala 的文档须要一种调整来隐藏它的复杂度，让人们在实际使用中更容易的获取这 flatMap 的强大能力。类型系统以及相关的文档需要一种更简化的形式，把复杂性隐藏在程序包内，对最终用户要表现出简单的接口。

　　当新程序员来维护老程序员写的 Scala 代码时，需要去理解代码中的风格和模式。Scala 的代码会使业务逻辑直接表现在最外层(而不是循环语句或复杂 IF 语句四处分布)，如果代码中存在风格习惯，业务逻辑就不是那么直接。没有风格也是个问题，但最终，整个团队需要统一接受这样的风格模式。在 Ruby 和 Rails 编程中也是这样，hashmap 替代了所有其它种的编程方法。但在 Rails 里，风格是统一的(尽管没有类型检查)，人们很容易理解，因为它就是这种“方式”。在 Java 里，代码模板由 IDE 生成，程序员养成了很容易发现其中的模式的能力。但在 Scala 中却不是这样，各种风格迥异，每个开发团队里都不相同。

　　我知道有很多的开发团队，在他们的团队组织形式里，采用 Scala 语言会比使用 Java 或 Ruby 或其它语言要合适的多，Twitter 公司就是这样的一个典型例子。他们需要一个简洁的，具有类型检查的，高性能的语言和运行环境。Scala 满足了他们的这些需求。Foursquare 公司以 Scala 的难度作为一种过滤制度。你只有学好了 Scala 语言才能在这个公司立足。

　　但如果你的团队的技术水平很一般，Scala 也许对你们公司来说并不是一个好的选项。Scala 的难度导致很陡的学习曲线，会遭到原有的程序员的反对，形成不了统一的风格。你需要一个强有力的 CTO 或架构师来强迫这种风格，而不是让他们自己从书中学习。

　　那么，如何能看出 Scala 在你们的团队中会是很“简单”还是很“难”呢?

　　如果你的公司在 JavaOne 大会，或 OSCON，Strangle Loop，或 QCon 大会上有出席发言的人：Scala 对于你们来说会很简单

　　如果吃饭时间你们还在讨论如何从一个普通程序员成长成高级程序员：Scala 对你们来说会很难

　　如果需要的话，你可以用 NotePad 编程：容易

　　当看到”Zed Shaw”时，你的程序员面无表情或连说3声“万福玛利亚!”：Scala==难

　　程序员在 Twitter 上关注 Dean Wampler：Scala 简单

　　你的程序员9：15到公司，晚上不看有没有邮件：难

　　现在你们知道了。我完全同意这样的观点：对于水平一般的团队，Scala 很难。并不是它本身很难，而是因为它在水平一般的团队中不会产生那种由技术很好的人组成的团队中产生的短期或长期的益处。

　　一些评论：

　　不错，Scala 的类型系统很强大，由它产生了很多优美的程序代码，例如 Scala 的集合。参考 See http://stackoverflow.com/questions/1722726/is-the-scala-2-8-collections-library-a-case-of-the-longest-suicide-note-in-histo 和 http://www.scala-lang.org/docu/files/collections-api/collections-impl.html。但是，对于 Scala，从一个语言设计者/程序库创造者的角度，和从一个普通程序员的角度，他们的需求是不同的。我个人认为，在开发 Lift 框架时，我认为没有第二种语言能像强大的 Scala 语言那样让我准确的表达。所以，作为一个程序库的开发者，我喜欢 Scala 语言。我还慢慢认识到，Lift 框架对于一般程序员来说似乎太难。作为一个懂得类型标记(signature)的程序库使用者，我喜欢 Scala。但我不是一个普通水平的程序员，大多数并不认为 Scala 很难的程序员都不是普通水平。

　　不错，改进 ScalaDocs，让它有“简单”视角和“架构”视角，这将带来巨大好处。但这些只是个开始，远没有结束。

　　我明确的反对“那好，我们找更好的程序员”的做法。我们可以通过提高我们的程序员的水平来解决“Scala 很难”的问题。但这不是问题的症结。症结在于，Scala 并不够足够的好，没有能力迫使在培训、教育、招聘领域产生变革，迫使广大的一般水平的程序员提高技术来适应 Scala 的难度。

　　我并不怀疑阅读这篇文章或看我的 Twitter 的人都是很有水平的程序员，Paul Snively，你水平这么高，Scala 对你来说是小儿科了。