我根本不懂Scala，但几周前我还不会读Clojure。现在我能读到大部分，但除了最简单的例子之外，我还写不出任何东西。我想Scala也没什么不同。你需要一本好书或一门课程，这取决于你的学习方式。只是看了上面的地图声明，我大概得到了其中的1/3。

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

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

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

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

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

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

说到点子上：

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

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

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

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

我不会担心的。

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

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

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

（然而，我之所以选择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流行程度的主要因素，因为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中的许多函数会针对不同类型重复。