我不知道该怎么告诉你，但我有剑桥大学的博士学位，我用的是2.8。

更严重的是，我几乎没有花时间使用2.7（它不会与我正在使用的Java库互操作），一个多月前才开始使用Scala。我对Haskell有一些经验（不多），但只是忽略了你担心的东西，并寻找与我的Java经验相匹配的方法（我以Java为生）。

所以：我是一个“新用户”，我并没有被推迟——事实上，它的工作方式与Java类似，这给了我足够的信心，可以忽略我不理解的部分。

（然而，我之所以选择Scala，部分原因是想看看是否要在工作中推动它，我现在还不打算这么做。让文档变得不那么吓人肯定会有所帮助，但让我惊讶的是，它仍在不断变化和开发中（公平地说，最让我吃惊的是它是多么棒，但变化紧随其后）。所以我想我想说的是，我更希望把有限的资源投入到最终的状态中——我认为他们不会期望很快就会如此流行。）

我也有牛津大学的数学学位！我花了一段时间才“拿到”新藏品。但我现在非常喜欢它。事实上，“map”的键入是2.7中最早让我感到困扰的事情之一（也许是因为我做的第一件事是集合类的子类之一）。

阅读Martin关于新的2.8集合的论文确实有助于解释隐式的用法，但是的，文档本身肯定需要更好地解释不同类型的隐式在核心API的方法签名中的作用。

我最担心的是：2.8将于何时发布？bug报告什么时候停止出现？scala团队是不是用2.8咬得太多了/试图一下子改变太多了？

我真的很希望在添加任何其他新功能之前，将2.8稳定发布作为一个优先事项，并想知道（在观望的同时）是否可以对scala编译器的开发路线图进行一些改进。

我不知道该怎么告诉你，但我有剑桥大学的博士学位，我用的是2.8。

更严重的是，我几乎没有花时间使用2.7（它不会与我正在使用的Java库互操作），一个多月前才开始使用Scala。我对Haskell有一些经验（不多），但只是忽略了你担心的东西，并寻找与我的Java经验相匹配的方法（我以Java为生）。

所以：我是一个“新用户”，我并没有被推迟——事实上，它的工作方式与Java类似，这给了我足够的信心，可以忽略我不理解的部分。

（然而，我之所以选择Scala，部分原因是想看看是否要在工作中推动它，我现在还不打算这么做。让文档变得不那么吓人肯定会有所帮助，但让我惊讶的是，它仍在不断变化和开发中（公平地说，最让我吃惊的是它是多么棒，但变化紧随其后）。所以我想我想说的是，我更希望把有限的资源投入到最终的状态中——我认为他们不会期望很快就会如此流行。）

我希望这不是“遗书”，但我明白你的意思。您发现了Scala的优点和问题：它的可扩展性。这使我们能够实现库中的大多数主要功能。在其他一些语言中，带有map或collect之类的序列将被内置，没有人需要了解编译器要使其顺利工作所需的所有步骤。在Scala中，它都在一个库中，因此是公开的。

事实上，复杂类型支持的地图功能非常先进。考虑一下：

scala> import collection.immutable.BitSet
import collection.immutable.BitSet

scala> val bits = BitSet(1, 2, 3)
bits: scala.collection.immutable.BitSet = BitSet(1, 2, 3)

scala> val shifted = bits map { _ + 1 }
shifted: scala.collection.immutable.BitSet = BitSet(2, 3, 4)

scala> val displayed = bits map { _.toString + "!" }
displayed: scala.collection.immutable.Set[java.lang.String] = Set(1!, 2!, 3!)

看看你总是如何得到最好的类型？如果将Ints映射到Ints，则会再次获得一个BitSet，但如果将Int映射到Strings，则将获得一个通用Set。映射结果的静态类型和运行时表示都取决于传递给它的函数的结果类型。即使集合为空，这也有效，因此函数永远不会被应用！据我所知，没有其他集合框架具有同等功能。然而，从用户的角度来看，这就是事情应该如何工作的。

我们面临的问题是，所有实现这一点的巧妙技术都会泄露到类型签名中，而这些签名变得又大又吓人。但也许默认情况下不应该向用户显示地图的完整类型签名？如果她在BitSet中查找地图，她会得到：

map(f: Int => Int): BitSet     (click here for more general type)

在这种情况下，文档不会说谎，因为从用户的角度来看，map确实具有类型（Int=>Int）=>BitSet。但地图也有一个更通用的类型，可以通过单击另一个链接来查看。

我们还没有在工具中实现这样的功能。但我认为我们需要这样做，以避免吓跑人们，并提供更多有用的信息。有了这样的工具，希望智能框架和库不会成为自杀笔记。

我完全同意这个问题和马丁的回答：）。即使在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。泛型中的协变和逆变类型也会增加大量噪声，我认为这可以以更容易理解的方式呈现给用户。

我认为该方法的主要问题是（隐式bf:CanBuildFrom[Rrep，B，that]）没有任何解释。尽管我知道什么是隐式参数，但没有任何信息表明这会如何影响调用。浏览scaladoc只会让我更加困惑（很少有与CanBuildFrom相关的类甚至有文档）。

我认为一个简单的“bf的作用域中必须有一个隐式对象，它为B类型的对象提供了一个构建器”会有所帮助，但当您真正想做的是将a映射到B时，这是一个令人兴奋的概念。事实上，我不确定这是对的，因为我不知道Repr类型是什么意思，而Traversable的文档也毫无头绪。

所以，我有两个选择，都不令人满意：

假设它只适用于旧地图的工作方式以及地图在大多数其他语言中的工作方式深入了解源代码

我认为Scala本质上是在揭示这些东西是如何工作的，最终这是提供了一种实现oxbow_lakes所描述的方法。但签名会分散注意力。