Yes, Virginia, Scala is hard
http://www.aqee.net/yes-virginia-scala-is-hard/
/*************from：外刊评论网*******************/
首先要说的是，我是一个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的集合。参考Seehttp://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对你来说是小儿科了。
Let me first say that I am a Scala lover and have been a Scala champion for almost 5 years. I've written books and articles on Scala. I've worked with dozens of companies that have launched Scala and Lift projects. I've code reviewed many dozens of Scala projects.
I used to think that Scala was easy. It was, and continues to be, a cure for some of the numerous problems with Java. From the "stuff that's hard or impossible in Java is simple in Scala," Scala is a very easy language. Dealing with collections is super easy in Scala. Isolating business logic making programs much more maintainable is vastly easier in Scala than it is in Java.
So, why is Scala hard? Here's the best list I can come up with:
- Scala tries to be too many things. This means that you can code it like Java which is a curse and a blessing, but I think over the long term, it's a curse. It means there are too many debates about OO vs. FP. These kind of decisions/debates are okay if you're a small team, but they really suck when you're trying to teach Java developers to write Scala when they don't really want to learn. The overwhelming advantages of Scala really manifest themselves when you're coding mostly FP, but it's nearly impossible to get OO developers there unless they really want to get there. In this case, less language features/choices (like Java or Ruby) is easier. It makes for less choices.
- IDE support is weak and always will be. The Eclipse plugin for Scala (or whatever it's called this week) sucks. It has sucked for the 5 years I've been doing Scala and it's always "just about to get better" but it sucks. IntelliJ's Scala support is reasonable for me. But the folks who need patterns in their IDE will not find the Scala support good. For one, the Scala patterns as so diverse and disjunct (OO via mixins all the way to ScalaZ), there will be too many patterns/templates. If you're happy coding in Emacs or Vi or TextMate, Scala is okay and moving to IntelliJ is nice. If you're expecting the hand-holding that you get with Java IDEs, it isn't there and never will be because encompassing Scala's power with simple paradigms is difficult and requires tons of resources that even TypeSafe with $3M in the bank cannot underwrite.
- The Scala type system is tremendously powerful, but it's in your face way too much. In the ScalaDocs, the type signatures are just plain frightening. Look atflatMap [B, That] (f: (A) ⇒ Traversable[B])(implicit bf: CanBuildFrom[List[A], B, That]) : That and tell me that doesn't make you want to run screaming. This is a method that beginners useevery day, 20 times a day and it's way too intimidating. Scala documentation needs a library consumer more that hides the complexity that is going on which in practice makes flatMap simply amazingly powerful. The type system and associated documentation needs a simpler mode that hides the features that trade power and complexity at the library level for simplicity at the end user level.
- Junior developers who are asked to maintain code written by senior developers have to understand the idioms and patterns in the code. While Scala makes putting business logic at the forefront of the code (rather than distributed through a bunch of for loops and complex if statements), depending on the idioms used, decoding that logic is non-obvious. This is a variant of the lack of idioms issue, but at the end of the day, you need a team with a mind-meld to grok some Scala code. This is true in Ruby and Rails as well where hashmaps replace virtually all other programming paradigms. But in Rails-land, the paradigm is uniform (although not type-checked) and well understood because it's "the way." In Java, the patterns are vomited out of the IDE, so developers grow up being able to spot the patterns. That's not true of Scala where the idioms are diverse and team/framework specific.
But if you've got a team that's closer to the mean skill-wise, Scala may not be a win for your company (this depends on management... does it want to use the challenge of Scala as a way of filtering and improving the team?) If you're a center-of-the-mean (COTM) company, then Scala costs you in terms of learning curve, existing developer rejection, lack of patterns. You'll need a strong CTO or architect to enforce the patterns rather than getting them from books and the IDE and the number of COTM companies with strong CTOs or Architects is, well, "limited".
So, how can you figure out if Scala will be "easy" or "hard" for your organization:
- Your company has speakers at JavaOne, OSCON, Strangle Loop, QCon: Scala will be easy
- Lunch-time discussions involve the criteria for moving from a developer to a senior developer: Scala will be hard
- Your developers can write code in NotePad if they have to: Easy
- Your developers stare blankly or say 3 "Hail Marys" when they hear the name "Zed Shaw": Scala == Hard
- Developers all follow Dean Wampler on Twitter: Scala Easy
- Your developers come in at 9:15 and leave before 6 and don't check work email at night: Hard
A couple of notes:
- Yes, Scala's type system is powerful and leads to some beautifully functioning code like Scala's collections. Seehttp://stackoverflow.com/questions/1722726/is-the-scala-2-8-collections-library-a-case-of-the-longest-suicide-note-in-histo andhttp://www.scala-lang.org/docu/files/collections-api/collections-impl.html But there's a difference between what the language/library designers need and what the COTM developer needs. Because there's no separation in Scala, it makes it hard for the COTM developer. Personally, I don't think I could express the ideas in Lift as concisely or as powerfully in any other language, so as a library author, I love Scala. I've also come to realize that Lift is scary for and may be too much for a COTM developer. As a library user who understands type signatures I love Scala. But I'm not at the mean and most of the people who don't see Scala as hard are not at the mean. And the 11 year old kid who writes Scala is not at the mean.
- Yes, improving ScalaDocs to allow the "simple" view and the "architecture" view would be a huge win. But that's a start, not an endpoint.
- I am explicitly rejecting the argument "well, then, find better developers." We could solve the "Scala is hard" problem by working to improve the overall quality of developers (ones who can read a type signature, ones who can express their programs mathematically, etc.), but that misses the point. The point is that Scala is not better enough to force a revolution in training, education, and hiring such that Scala will be able to change the quality of the average developer enough to make Scala not hard for that developer.
- I doubt that anyone who reads this or reads my Twitter stream is an average developer and Paul Snively, you are so not average you shouldn't even try!