Scala很难
本文是从 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的难度。
首先要说的是，我是一个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对你来说是小儿科了。
本文转自外刊IT评论网