我没有博士学位，也没有任何其他学位，既没有计算机科学，也没有数学，也没有其他领域。我以前没有使用Scala或任何其他类似语言的经验。我甚至没有使用远程可比类型系统的经验。事实上，我所掌握的不仅仅是表面知识，甚至还有一种类型系统的语言是Pascal，它并不完全以其复杂的类型系统而闻名。（虽然它确实有范围类型，而AFAIK几乎没有其他语言有，但这在这里并不重要。）我知道的其他三种语言是BASIC、Smalltalk和Ruby，它们都没有类型系统。

然而，我完全不难理解你发布的地图函数的签名。在我看来，这与地图上我见过的其他语言的签名几乎相同。不同的是，这个版本更通用。它看起来更像C++STL，而不是Haskell。特别是，它通过仅要求参数为IterableLike来抽象具体的集合类型，并且通过仅要求存在隐式转换函数来抽象具体返回类型，该函数可以从结果值集合中构建一些东西。是的，这很复杂，但它实际上只是泛型编程的一般范式的一种表达：不要假设任何实际上不需要的东西。

在这种情况下，map实际上不需要集合是列表，也不需要被排序或可排序等。地图唯一关心的是，它可以一个接一个地访问集合的所有元素，但没有特定的顺序。它不需要知道生成的集合是什么，只需要知道如何构建它。因此，这就是它的类型签名所要求的。

所以

map :: (a → b) → [a] → [b]

这是映射的传统类型签名，它一般不需要具体的List，而只需要IterableLike数据结构

map :: (IterableLike i, IterableLike j) ⇒ (a → b) → i → j

然后通过仅要求存在能够将结果转换为用户想要的任何数据结构的函数来进一步概括：

map :: IterableLike i ⇒ (a → b) → i → ([b] → c) → c

我承认语法有点笨拙，但语义是一样的。基本上，它从

def map[B](f: (A) ⇒ B): List[B]

这是地图的传统签名。（注意，由于Scala的面向对象特性，输入列表参数是如何消失的，因为它现在是单个分派OO系统中每个方法都具有的隐式接收器参数。）

def map[B](f: (A) ⇒ B): IterableLike[B]

现在，它用一个函数替换了IterableLike结果集合，这个函数实际上可以产生任何东西。

def map[B, That](f: A ⇒ B)(implicit bf: CanBuildFrom[Repr, B, That]): That

我真的相信这并不难理解。你只需要几个智能工具：

你需要知道（大致）map是什么。我承认，如果你只给出了类型签名，而没有给出方法的名称，那么很难弄清楚到底发生了什么。但既然你已经知道map应该做什么，而且你知道它的类型签名应该是什么，你就可以快速扫描签名并关注异常情况，比如“为什么这个映射将两个函数作为参数，而不是一个？”您需要能够实际读取类型签名。但是，即使您以前从未见过Scala，这也应该很容易，因为它实际上是您从其他语言中已经知道的类型语法的混合：VB.NET使用方括号来表示参数多态性，使用箭头表示返回类型，使用冒号来分隔名称和类型，这实际上是一种规范。您需要大致了解泛型编程是什么。（这并不难理解，因为它基本上都是用名称拼写的：它实际上只是以通用方式编程）。

这三项都不应该让任何专业程序员甚至业余程序员头疼。在过去的50年中，map已经成为几乎每一种语言的标准功能，不同的语言都有不同的语法，这一事实对于任何使用HTML和CSS设计网站的人来说都是显而易见的，如果没有一些来自圣教堂的讨厌的C++粉丝，你就无法订阅甚至远程编程相关的邮件列表。Stepanov解释泛型编程的优点。

是的，Scala很复杂。是的，Scala是人类所知的最复杂的类型系统之一，可以媲美甚至超越Haskell、Miranda、Clean或Cyclone等语言。但如果复杂性是一种编程语言成功的理由，C++早就死了，我们都会写Scheme。Scala很可能不会成功的原因有很多，但程序员在坐在键盘前不必费心动脑这一事实可能不是主要原因。

我完全同意这个问题和马丁的回答：）。即使在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课程。

Scala有很多疯狂的特性（特别是在隐式参数方面），看起来非常复杂和学术，但设计的目的是使其易于使用。最有用的是语法糖（如[A<%B]，这意味着A类型的对象隐式转换为B类型的对象）和对它们所做操作的详细说明。但大多数时候，作为这些库的客户，您可以忽略隐式参数，并相信它们会做正确的事。

似乎有必要在这里注明自己的学位：政治学学士和计算机科学学士。

说到点子上：

这会让人们不去斯卡拉吗？

Scala很难，因为它的底层编程范式很难。函数式编程让很多人害怕。在PHP中构建闭包是可能的，但人们很少这样做。因此，如果人们没有特定的教育来让他们重视底层范式的力量，那么不，不是这个签名，而是其他所有签名都会让人们望而却步。

如果这种教育是可行的，每个人都可以做到。去年我在SCALA和一群学生一起制作了一台国际象棋电脑！他们有自己的问题，但最终还是做得很好。

如果你在商业上使用Scala，你会担心吗？您是否计划立即采用2.8版本，还是等待结果？

我不会担心的。

这会让人们不去斯卡拉吗？

是的，但这也会防止人们被推迟。自从Scala获得对更高级类型的支持以来，我一直认为缺少使用更高级类型类型的集合是一个主要缺点。它使API文档更加复杂，但确实使使用更加自然。

这是否会让scala在商业界成为一个只有专业的博士生才能理解的学术玩物？首席技术官和软件负责人会被吓跑吗？

有些人可能会。我不认为很多“专业”开发人员可以访问Scala，部分原因是Scala的复杂性，部分原因在于许多开发人员不愿意学习。雇佣此类开发人员的首席技术官们会被吓跑。

图书馆重新设计是否明智？

绝对地它使集合更适合语言和类型系统的其他部分，即使它仍然有一些粗糙的边缘。

如果你在商业上使用scala，你会担心吗？您是否计划立即采用2.8版本，还是等待结果？

我没有在商业上使用它。我可能会等到2.8.x系列的至少两个版本之后，再尝试引入它，以便清除bug。我还将拭目以待EPFL在改进其开发和发布过程方面取得了多大成功。我所看到的似乎充满希望，但我在一家保守的公司工作。

一个更普遍的话题是“Scala对于主流开发人员来说太复杂了吗？”。。。

大多数开发人员，无论是主流还是其他，都在维护或扩展现有系统。这意味着，他们使用的大部分内容都是由很久以前做出的决定决定的。仍然有很多人在编写COBOL。

未来的主流开发人员将致力于维护和扩展目前正在构建的应用程序。其中许多应用程序不是由主流开发人员构建的。未来的主流开发人员将使用当今最成功的新应用程序开发人员所使用的语言。