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

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

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

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

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

我拥有一所廉价的“大众市场”美国大学的本科学位，所以我可以说我处于用户智能（或至少是教育）的中等水平：）我涉足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获得对更高级类型的支持以来，我一直认为缺少使用更高级类型类型的集合是一个主要缺点。它使API文档更加复杂，但确实使使用更加自然。

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

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

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

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

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

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

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

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

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

我没有博士学位，也没有任何其他学位，既没有计算机科学，也没有数学，也没有其他领域。我以前没有使用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很可能不会成功的原因有很多，但程序员在坐在键盘前不必费心动脑这一事实可能不是主要原因。

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

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

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

考虑到这些，我认为：

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

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

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

我希望这不是“遗书”，但我明白你的意思。您发现了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。但地图也有一个更通用的类型，可以通过单击另一个链接来查看。

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

不幸的是，您提供的地图签名对地图来说是不正确的，而且确实存在合理的批评。

第一个批评是，通过颠覆地图的签名，我们得到了更一般的东西。认为这是一种默认的美德是一种常见的错误。它不是。映射函数被很好地定义为一个协变函子Fx->（x->y）->Fy，它遵循复合和恒等两个定律。任何其他归因于“地图”的东西都是一个笑话。

给定的签名是其他东西，但它不是地图。我怀疑它试图成为一个专门的、略有改动的“遍历”签名版本，该签名来自论文《迭代器模式的本质》。以下是其签名：

traverse :: (Traversable t, Applicative f) => (a -> f b) -> t a -> f (t b)

我将把它转换成Scala：

def traverse[A, B](f: A => F[B], a: T[A])(implicit t: Traversable[T], ap: Applicative[F]): F[T[B]

当然，它失败了——它还不够普遍！此外，它略有不同（请注意，您可以通过运行遍历Identity函子来获得map）。然而，我怀疑，如果库编写者更了解有充分记录的库概括（前面提到的是使用效果的应用编程），那么我们就不会看到这个错误。

第二，map函数在Scala中是一种特殊的情况，因为它用于理解。不幸的是，这意味着一个装备更好的库设计者不能忽视这个错误，而不牺牲理解的语法糖。换句话说，如果Scala库设计者要破坏一个方法，那么这很容易被忽略，但请不要映射！

我希望有人对此直言不讳，因为事实上，解决Scala坚持犯的错误将变得更加困难，显然是出于我强烈反对的原因。也就是说，解决“来自普通程序员的不负责任的反对（即太难了！）”的方法不是“安抚他们，让他们更容易”，而是，为成为更好的程序员提供指导和帮助。我和Scala的目标在这个问题上存在争议，但回到你的观点。

你可能是在表明自己的观点，预测“普通程序员”的具体反应。也就是说，那些声称“但这太复杂了！”或诸如此类的人。这些是你所指的耶格人或布洛赫人。我对这些反智主义/实用主义运动的人的反应相当严厉，我已经预料到会有一连串的反应，所以我将省略它。

我真的希望Scala库能够改进，或者至少可以将错误安全地隐藏在角落里。Java是一种“尝试做任何有用的事情”的代价非常高昂的语言，因此通常不值得这样做，因为大量的错误根本无法避免。我恳求斯卡拉不要重蹈覆辙。

Scala社区可以帮助减轻新手程序员对Scala的恐惧，其中一个方法就是专注于实践，并通过实例进行教学——很多实例都是从小开始，逐渐长大的。以下是一些采用这种方法的网站：

每日Scala学习Scala简单Scala

在这些网站上花了一段时间后，人们很快意识到Scala及其库虽然可能很难设计和实现，但使用起来并不那么困难，特别是在常见情况下。

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

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

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

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

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

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

我是一个Scala初学者，老实说，我看不出那种类型签名有什么问题。参数是要映射的函数，隐式参数是生成器返回正确集合的参数。清晰易读。

事实上，整件事很优雅。生成器类型参数允许编译器选择正确的返回类型，而隐式参数机制对类用户隐藏此额外参数。我试过了：

Map(1 -> "a", 2 -> "b").map((t) => (t._2) -> (t._1)) // returns Map("a" -> 1, "b" -> 2)
Map(1 -> "a", 2 -> "b").map((t) =>  t._2)            // returns List("a", "b")

多态性做得很好。

当然，这不是一种主流范式，它会吓跑很多人。但是，它也会吸引许多看重其表现力和优雅的人。

使用站点中的错误消息如何？

当出现需要将现有类型与适合DSL的自定义类型集成的用例时，情况又会如何呢。一个人必须在关联、优先级、隐式转换、隐式参数、更高级的类型，以及可能存在的类型方面受过良好的教育。

很高兴知道，大多数情况下，这很简单，但并不一定足够。如果要设计广泛的图书馆，至少必须有一个人知道这些东西。

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;
}

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

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

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

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

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

我不认为这是影响Scala流行程度的主要因素，因为Scala具有强大的功能，其语法对于Java/C++/PHP程序员来说不像Haskell、OCaml、SML、Lisps等那样陌生。。

但我确实认为Scala的流行程度将比现在的Java要低，因为我也认为下一个主流语言必须要简化得多，而我认为实现这一点的唯一方法是纯不变性，即声明性的HTML，但图灵是完整的。然而，我有偏见，因为我正在开发这样一种语言，但我只是在几个月的研究中排除了Scala不能满足我的需求后才这么做的。

这会不会让斯卡拉在商业界名声扫地，因为它是一种只有专业的博士生才能理解的学术游戏？首席技术官和软件负责人会被吓跑吗？

我认为斯卡拉的声誉不会因为哈斯克尔情结而受损。但我认为有些人会推迟学习，因为对于大多数程序员来说，我还没有看到一个用例迫使他们使用Scala，他们会拖延学习。也许高度可扩展的服务器端是最引人注目的用例。

而且，对于主流市场来说，首先学习Scala并不是“新鲜空气”，而是立即编写程序，比如首先使用HTML或Python。当一个人从一开始就了解了所有的细节之后，Scala会逐渐发展壮大。然而，如果我从一开始就阅读了Scala编程，我对学习曲线的经验和看法可能会有所不同。

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

肯定

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

我使用Scala作为我新语言的初始平台。如果我在商业上使用Scala，我可能不会在Scala的集合库上构建代码。我会创建我自己的基于类别理论的库，因为有一次我发现Scalaz的类型签名比Scala的集合库更加冗长和笨拙。问题的一部分可能是Scala实现类型类的方式，这是我创建自己语言的一个次要原因。

我决定写这个答案，因为我想强迫自己研究并比较Scala的集合类设计和我为自己的语言所做的设计。不妨分享一下我的思考过程。

2.8 Scala集合使用生成器抽象是一个合理的设计原则。我想探讨以下两个设计权衡。

只写代码：写完本节后，我阅读了卡尔·斯莫特里茨的评论，这与我期望的权衡一致。James Strachan和davetron5000的评论一致认为，that（甚至不是that[B]）的含义和隐含的机制不容易直观地理解。参见我在下面第2期中对幺半群的使用，我认为这一点更加明确。Derek Mahar的评论是关于编写Scala的，但阅读其他人的Scala又如何呢。我读过的关于Scala的一个批评是，写它比读别人写的代码更容易。我发现，由于各种原因（例如，编写函数的许多方法、自动闭包、DSL的单元等），这偶尔是正确的，但我不确定这是否是主要因素。在这里，隐式函数参数的使用有利有弊。另一方面，它减少了冗长的内容，并自动化了构建器对象的选择。在Odersky的示例中，从BitSet（即Set[Int]）到Set[String]的转换是隐式的。不熟悉代码的读者可能不太清楚集合的类型，除非他们能够很好地解释当前包范围中可能存在的所有潜在的不可见隐式构建器候选项。当然，经验丰富的程序员和代码编写者会知道BitSet仅限于Int，因此到String的映射必须转换为不同的集合类型。但哪种集合类型？未明确指定。AD-HOC系列设计：写完本节后，我阅读了托尼·莫里斯的评论，意识到我的观点几乎相同。也许我更详细的阐述会让这一点更清楚。在Odersky&Moors的“用类型对抗比特腐烂”中，介绍了两个用例。它们是BitSet对Int元素和Map对元组元素的限制，并且是通用元素映射函数A=>B必须能够构建替代目标集合类型的原因。然而，从范畴论的角度来看，这是有缺陷的。为了在范畴理论中保持一致，从而避免角落情况，这些集合类型是函子，其中每个态射A=>B必须映射在同一函子类别中的对象之间，List[A]=>List[B]，BitSet[A]=>BitSet[B]。例如，Option是一个函子，可以视为一个Some（对象）和None的集合的集合。没有从Option的None或List的Nil到其他没有“空”状态的函子的一般映射。这里有一个折衷的设计选择。在我的新语言的集合库的设计中，我选择将所有东西都变成一个函子，这意味着如果我实现了一个BitSet，它需要支持所有元素类型，在使用非整数类型参数时使用非位字段内部表示，并且该功能已经存在于它在Scala中继承的Set中。在我的设计中，Map只需要映射它的值，它可以提供一个单独的非函子方法来映射它的（键，值）对元组。一个优点是每个函子通常也是一个应用的，也许也是一个单元。因此，元素类型之间的所有函数，例如A＝＞B＝＞C＝＞D＝＞。。。，自动提升至提升应用类型之间的功能，例如列表[A]=>列表[B]=>列表[C]=>列表[D]=>。。。。对于从一个函子到另一个集合类的映射，我提供了一个映射重载，它接受一个幺半群，例如Nil、None、0、“”、Array（）等。因此，生成器抽象函数是幺半群的append方法，并作为必要的输入参数显式提供，因此没有不可见的隐式转换。（Tangent：这个输入参数还允许附加到非空幺半群，这是Scala的映射设计无法做到的。）这样的转换是同一迭代过程中的映射和折叠。此外，我还提供了一个可遍历的，从类别意义上讲，“带效果的应用编程”McBride&Patterson，它还允许在从任何可遍历到任何应用的单个迭代过程中进行map+折叠，其中大多数集合类都是两者。此外，状态monad是一个应用程序，因此是一个来自任何可遍历的完全通用的构建器抽象。因此，Scala集合是“ad-hoc”的，因为它不是基于范畴理论的，而范畴理论是更高级指称语义的本质。尽管Scala的隐式构造器一开始看起来比函子模型+幺半群构造器+可遍历->应用性“更通用”，但它们并没有被证明与任何类别一致，因此我们不知道它们在最一般的意义上遵循什么规则，也不知道会给出什么样的角情况——它们可能不遵守任何类别模型。添加更多的变量会使事情变得更一般，这是不正确的，这是范畴理论的一个巨大好处，因为它提供了在提升到更高级语义的同时保持通用性的规则。集合是一个类别。我在某个地方读到，我认为这是Odersky，作为库设计的另一个理由，纯函数式编程的代价是在不使用尾部递归的情况下，递归和速度有限。到目前为止，我发现在我遇到的每一种情况下使用尾部递归并不困难。

此外，我的脑海中还带着一个不完整的想法，即Scala的一些权衡是由于试图成为一种可变和不可变的语言，而不像Haskell或我正在开发的语言。这与托尼·莫里斯关于理解的评论一致。在我的语言中，没有循环和可变构造。我的语言将位于Scala之上（目前），这在很大程度上归功于它，如果Scala没有通用的类型系统和可变性，这是不可能的。不过，这可能不是真的，因为我认为Odersky&Moors（“用类型对抗比特烂”）说Scala是唯一一种具有更高种类的OOP语言是不正确的，因为（我自己和通过Bob Harper）验证了Standard ML拥有它们。此外，SML的类型系统可能相当灵活（自20世纪80年代以来），这可能并不容易理解，因为语法与Java（和C++/PHP）的相似性不如Scala。无论如何，这不是对Scala的批评，而是试图对权衡进行不完整的分析，我希望这与问题密切相关。Scala和SML不受Haskell无法执行菱形多重继承的影响，这一点很关键，我理解为什么Haskell Prelude中的许多函数会针对不同类型重复。

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

说到点子上：

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

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

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

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

我不会担心的。