我刚刚开始研究即将发布的2.8版本中的Scala集合库重新实现。熟悉2.7版本的库的人会注意到，从使用角度来看，库的变化很小。例如
> List("Paris", "London").map(_.length)
res0: List[Int] List(5, 6)
…两种版本都可以。这个图书馆非常有用：事实上它非常棒。然而，那些以前不熟悉Scala并四处摸索以了解该语言的人现在必须理解方法签名，如：
def map[B, That](f: A => B)(implicit bf: CanBuildFrom[Repr, B, That]): That
对于这样简单的功能，这是一个令人望而生畏的签名，我发现自己很难理解。我并不认为Scala有可能成为下一个Java（或/C/C++/C#）-我不相信它的创造者是瞄准这个市场的-但我认为Scala成为下一代Ruby或Python（即获得大量商业用户）是可行的
这会让人们不去斯卡拉吗？这会不会让斯卡拉在商业界名声扫地，因为它是一种只有专业的博士生才能理解的学术游戏？首席技术官和软件负责人会被吓跑吗？图书馆重新设计是否明智？如果你在商业上使用Scala，你会担心吗？您是否计划立即采用2.8版本，还是等待结果？
Steve Yegge曾攻击Scala（在我看来是错误的），因为他认为Scala的类型系统过于复杂。我担心有人会用这个API来传播FUD（类似于Josh Bloch如何吓得JCP不敢向Java添加闭包）。
注意-我应该清楚，虽然我认为约书亚·布洛赫在拒绝BGGA关闭提案方面有影响力，但我不认为这是因为他诚实地认为该提案代表了错误。
尽管我的妻子和同事一直在告诉我，我并不认为自己是个白痴：我在牛津大学获得了很好的数学学位，我已经在商业编程近12年，在Scala编程大约一年（也是商业编程）。
请注意，煽动性主题标题引用了20世纪80年代初英国一个政党的宣言。这个问题是主观的，但这是一个真实的问题，我已经把它改成了CW，我想就此事发表一些意见。
我完全同意这个问题和马丁的回答：）。即使在Java中，由于额外的噪声，使用泛型读取javadoc也比应该的要困难得多。这在Scala中是复杂的，其中隐式参数被用作问题的示例代码（而隐式参数做了非常有用的集合变形）。
我不认为这是语言本身的问题——我认为这更多是工具问题。虽然我同意Jörg W Mittag所说的，但我认为查看scaladoc（或IDE中某一类型的文档）应该需要尽可能少的脑力来探索方法是什么、它需要什么和它的回报。不需要在一张纸上拼凑出一点代数就可以了：）
当然，IDE需要一种很好的方式来显示任何变量/表达式/类型的所有方法（就像Martin的例子一样，可以内联所有泛型，这样很好，也很容易找到）。我也喜欢马丁默认隐藏隐式的想法。
以scaladoc为例。。。
def map[B, That](f: A => B)(implicit bf: CanBuildFrom[Repr, B, That]): That
当在scaladoc中看到这个时，我希望默认情况下隐藏通用块[B，That]以及隐式参数（如果你用鼠标悬停一个小图标，它们可能会显示）-作为阅读它的额外内容，这通常并不相关。例如，想象一下这看起来像。。。
def map(f: A => B): That
很好，很清楚，很明显。你可能想知道“那”是什么，如果你将鼠标放在上面或单击它，它可以展开[B，That]文本，突出显示“那”。
也许一个小图标可以用于[]声明和（隐式…）块，所以很明显，语句中有一些小部分被折叠了？很难使用令牌，但我会使用。目前。。。
def map.(f: A => B).: That
因此，默认情况下，类型系统的“噪音”被隐藏在人们需要查看的80%的主要内容中-方法名称、参数类型和返回类型，非常简单简洁-如果你真的非常关心，那么就很少有可扩展的链接来查看细节。
大多数人都在阅读scaladoc，以了解他们可以对类型调用什么方法以及可以传递什么参数。
这是另一个例子。。。
def orElse[A1 <: A, B1 >: B](that: PartialFunction[A1, B1]): PartialFunction[A1, B1]
现在，如果我们隐藏泛型声明，则更容易阅读
def orElse(that: PartialFunction[A1, B1]): PartialFunction[A1, B1]
然后，如果人们将注意力停留在A1上，比如说，我们可以显示A1声明为A1＜：A。泛型中的协变和逆变类型也会增加大量噪声，我认为这可以以更容易理解的方式呈现给用户。
我拥有一所廉价的“大众市场”美国大学的本科学位，所以我可以说我处于用户智能（或至少是教育）的中等水平：）我涉足Scala仅几个月，并开发了两三个非平凡的应用程序。
特别是现在IntelliJ发布了他们的优秀IDE，IMHO是目前最好的Scala插件，Scala开发相对轻松：
我发现我可以使用Scala作为一个“没有分号的Java”，也就是说，我编写的代码与我在Java中所做的代码相似，并且从语法简洁（比如通过类型推断获得的简洁）中获益匪浅。异常处理，当我做的时候，更方便。没有getter/setter样板，类定义就不那么冗长了。偶尔我会写一行代码，以实现相当于多行Java代码的功能。在适用的情况下，诸如map、fold、collect、filter等功能方法链的组成既有趣又美观。我很少能从Scala更强大的功能中获益：闭包和部分（或curried）函数、模式匹配。。。那种事。
作为一个新手，我继续努力学习简洁和惯用的语法。没有参数的方法调用不需要括号，除非它们需要括号；match语句中的case需要一个粗箭头（=>），但也有一些地方需要一个细箭头（->）。许多方法都有简短但相当隐晦的名称，如/：或\：-如果我翻了足够多的手册页，我可以完成我的工作，但我的一些代码看起来像Perl或行噪声。具有讽刺意味的是，最流行的语法速记之一在实际操作中缺失了：我一直被Int没有定义++方法这一事实所困扰。
这只是我的看法：我觉得Scala具有C++的强大功能，同时又具有C++的复杂性和可读性。语言的语法复杂性也使得API文档难以阅读。
Scala在很多方面都是经过深思熟虑的。我想很多学者都会喜欢用它编程。然而，它也充满了智慧和陷阱，它比Java有更高的学习曲线，更难阅读。如果我浏览论坛，看到有多少开发人员仍在为Java的精细之处而挣扎，我无法想象Scala会成为主流语言。没有一家公司能够证明派遣开发人员参加为期3周的Scala课程是合理的，因为他们以前只需要一周的Java课程。
