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

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

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

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

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

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

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

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

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

C++中的相同内容：

template <template <class, class> class C,
          class T,
          class A,
          class T_return,
          class T_arg
              >
C<T_return, typename A::rebind<T_return>::other>
map(C<T, A> &c,T_return(*func)(T_arg) )
{
    C<T_return, typename A::rebind<T_return>::other> res;
    for ( C<T,A>::iterator it=c.begin() ; it != c.end(); it++ ){
        res.push_back(func(*it));
    }
    return res;
}

我完全同意这个问题和马丁的回答：）。即使在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，但几周前我还不会读Clojure。现在我能读到大部分，但除了最简单的例子之外，我还写不出任何东西。我想Scala也没什么不同。你需要一本好书或一门课程，这取决于你的学习方式。只是看了上面的地图声明，我大概得到了其中的1/3。

我认为，更大的问题不在于这些语言的语法，而在于采用和内化使它们在日常生产代码中可用的范例。对我来说，Java并不是C++的巨大飞跃，也不是C的巨大飞跃。Pascal和Basic等根本不是Java的飞跃。但用Clojure这样的函数式语言编写代码是一个巨大的飞跃（对我来说）。我想在Scala中，你可以用Java风格或Scala风格编写代码。但在Clojure中，您将创建一个相当混乱的环境，试图让您的命令习惯远离Java。

嗯，我可以理解你的痛苦，但坦率地说，像你和我这样的人——或者几乎任何一个普通的StackOverflow用户——都不是规则。

我的意思是。。。大多数程序员都不会在意类型签名，因为他们永远不会看到它们！他们不阅读文档。

只要他们看到了代码如何工作的一些示例，并且代码不会使他们无法产生他们期望的结果，他们就永远不会查看文档。当失败时，他们将查看文档并期望在顶部看到用法示例。

考虑到这些，我认为：

任何人（像大多数人一样）遇到这种类型签名时，如果事先对Scala进行了处理，就会对其进行无限的嘲笑，如果他们喜欢Scala，就会认为它是Scala力量的象征。如果文档没有得到增强以提供使用示例，并清楚地解释方法的用途和使用方法，那么可能会有点影响Scala的采用。从长远来看，这无关紧要。Scala可以做这样的事情，这将使为Scala编写的库更加强大，使用起来更加安全。这些库和框架将吸引熟悉强大工具的程序员。喜欢简单和直接的程序员将继续使用PHP或类似的语言。

唉，Java程序员非常热衷于强大的工具，所以，在回答这个问题时，我刚刚修正了我对主流Scala采用的期望。我毫不怀疑Scala会成为主流语言。不是C主流，但可能是Perl主流或PHP主流。

说到Java，您曾经替换过类加载器吗？你有没有调查过这涉及到什么？如果你看看框架编写者所做的事情，Java可能会很可怕。只是大多数人都不知道。这同样适用于Scala，IMHO，但早期采用者倾向于在他们遇到的每一块岩石下寻找，看看是否有什么隐藏在那里。