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

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

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

我不认为这是影响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获得对更高级类型的支持以来，我一直认为缺少使用更高级类型类型的集合是一个主要缺点。它使API文档更加复杂，但确实使使用更加自然。

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

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

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

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

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

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

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

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

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

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

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

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

考虑到这些，我认为：

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

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

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

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