我刚刚开始研究即将发布的2.8版本中的Scala集合库重新实现 。 熟悉2.7中的库的人会注意到，从使用角度来看，库几乎没有变化。 例如...

> List("Paris", "London").map(_.length)
res0: List[Int] List(5, 6)

......适用于任何一个版本。 图书馆非常实用 ：实际上它太棒了。 然而，那些以前不熟悉Scala并且想要了解语言的人现在必须理解方法签名，例如：

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

对于这样简单的功能，这是一个令人生畏的签名，我发现自己很难理解。 并不是说我认为Scala有可能成为下一个Java （或/ C / C ++ / C＃） - 我不相信它的创建者会瞄准那个市场 - 但我认为Scala成为/当然是可行的下一个Ruby或Python（即获得重要的商业用户群）

• 这会让人们去Scala吗？
• 这是否会让Scala在商业世界中成为一个不好的名字，作为学术玩具 ，只有专门的博士生才能理解？ CTO和软件负责人是否会受到惊吓？
• 图书馆重新设计了一个明智的想法吗？
• 如果您在商业上使用Scala，您是否担心这一点？ 您是打算立即采用2.8还是等待看看会发生什么？

Steve Yegge 曾经因为他过于复杂的类型系统而攻击Scala （在我看来是错误的）。 我担心有人会在这个API上传播FUD （类似于Josh Bloch如何通过向Java添加闭包来吓唬JCP ）。

注意 - 我应该清楚，虽然我相信约书亚布洛赫在拒绝BGGA关闭提案方面具有影响力，但我并没有将此归因于他诚实地认为提案代表错误的其他信息。

---

尽管我的妻子和同事一直在告诉我，我不认为我是一个白痴：我在牛津大学获得了很好的数学学位，而且我已经在商业方面进行了近12年的编程，并在斯卡拉进行了大约一年（也是商业上）。

请注意，炎症主题标题是关于 20世纪80年代早期英国政党宣言的引文 。 这个问题是主观的，但这是一个真实的问题，我已经成为CW，我想就此事提出一些意见。

---

#1楼

这里似乎有必要说明学位：政治学学士学位和计算机科学学士学位。

要点：

这会让人们去Scala吗？

Scala很难，因为它的底层编程范例很难。 功能编程让很多人感到害怕。 可以在PHP中构建闭包，但人们很少这样做。 所以不，不是这个签名，而是所有其他人都会放弃，如果他们没有特定的教育，使他们重视潜在范式的力量。

如果有这种教育，每个人都可以做到。 去年我在斯卡拉与一群学校的孩子们一起制作了一台国际象棋电脑！ 他们有他们的问题，但他们最终做得很好。

如果您在商业上使用Scala，您是否担心这一点？ 您是打算立即采用2.8还是等待看看会发生什么？

我不担心。

---

#2楼

我不知道如何打破它，但我有剑桥博士学位，我使用2.8就好了。

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

所以：我是一个“新用户”而且我没有被推迟 - 事实上它像Java一样让我有足够的信心忽略了我不理解的部分。

（但是，我看Scala的原因部分是为了看看它是否会推动它工作，我还没有这样做。让文档不那么令人生畏肯定会有所帮助，但令我惊讶的是它还有多少变化和发展（最公平的是我最让我感到惊讶的是它有多棒，但变化紧随其后）。所以我想我所说的是我宁愿选择有限的资源来实现这一目标。最终状态 - 我认为他们很快就会期待这种流行。）

---

#3楼

Scala有许多疯狂的功能（特别是在涉及隐式参数的地方），看起来非常复杂和学术，但旨在使事情易于使用。 最有用的是获得语法糖（如[A <% B] ，这意味着类型A的对象具有对类型B的对象的隐式转换）以及对它们的作用的详细说明。 但大多数情况下，作为这些库的客户端，您可以忽略隐式参数并信任它们做正确的事情。

---

#4楼

我有一个廉价的“大众市场”美国大学的本科学位，所以我说我落入了用户智能（或至少是教育）规模的中间:)我已经和Scala讨论了几个月并且已经开发了两三个非平凡的应用程序。

特别是现在IntelliJ已经发布了他们的精美IDE，其中恕我直言是目前最好的Scala插件，Scala开发相对无痛：

• 我发现我可以使用Scala作为“没有分号的Java”，即我在Java中编写类似于代码的代码，并从语法简洁中获益，例如类型推断所获得的。 异常处理，当我这样做时，更方便。 没有getter / setter样板，类定义就不那么冗长了。

• 偶尔我会设法编写一行来完成相当于多行的Java。 在适用的情况下，诸如地图，折叠，收集，过滤等功能方法的链条组成和优雅看起来很有趣。

• 我很少发现自己受益于Scala更强大的功能：闭包和部分（或咖喱）功能，模式匹配......这样的事情。

作为一个新手，我继续努力用简洁和惯用的语法。 没有参数的方法调用不需要括号，除非他们这样做; 匹配语句中的case需要一个胖箭头（ => ），但也有一些地方需要一个细箭头（ -> ）。 许多方法都有简短但相当神秘的名称，比如/:或\\: - 如果我翻转足够的手册页，我可以完成我的工作，但是我的一些代码最终看起来像Perl或线路噪音。 具有讽刺意味的是，最常用的句法速记之一在行动中缺失：我一直被Int没有定义++方法的事实所Int 。

这只是我的观点：我觉得Scala具有C ++的强大功能以及C ++的复杂性和可读性。 语言的语法复杂性也使得API文档难以阅读。

斯卡拉在许多方面都经过深思熟虑和辉煌。 我怀疑很多学者都喜欢在其中编程。 然而，它也充满了聪明和陷阱，它具有比Java更高的学习曲线，并且更难阅读。 如果我扫描论坛，看看有多少开发人员仍然在努力克服Java的细节， 我无法想象Scala会成为主流语言 。 没有公司能够证明派遣开发人员参加为期3周的Scala课程，而之前他们只需要1周的Java课程。

---

#5楼

这会让人们去Scala吗？

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

这是否会让scala在商业世界中成为一个不好的名字，作为一个只有专门的博士生可以理解的学术玩具？ CTO和软件负责人是否会受到惊吓？

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

图书馆重新设计了一个明智的想法吗？

绝对。 它使得集合与其他语言和类型系统相比更加合适，即使它仍然有一些粗糙的边缘。

如果你在商业上使用scala，你是否担心这个？ 您是打算立即采用2.8还是等待看看会发生什么？

我没有在商业上使用它。 我可能要等到至少两次转入2.8.x系列之后才尝试引入它以便可以刷出错误。 我还要等一下，看看EPFL在改进发展过程中取得多大成功。 我所看到的看起来很有希望，但我为一家保守的公司工作。

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

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

明天的主流开发人员将负责维护和扩展当前正在构建的应用程序。 其中许多应用程序并非由主流开发人员构建。 明天的主流开发人员将使用当今最成功的新应用程序开发人员使用的语言。

---

#6楼

我没有博士学位，也没有任何其他类型的学位，既不是CS，也不是数学，也不是任何其他领域。 我之前没有使用Scala或任何其他类似语言的经验。 我甚至没有远程可比类型系统的经验。 事实上，我所拥有的唯一一种语言，不仅仅是一种肤浅的知识，甚至还有一个类型系统，它是Pascal，并不完全以其复杂的类型系统而闻名。 （虽然它确实有范围类型，AFAIK几乎没有其他语言，但这在这里并不相关。）我知道的其他三种语言是BASIC，Smalltalk和Ruby，其中没有一种甚至都有类型系统。

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

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

所以，而不是

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

这是map的传统类型签名，它被推广为不需要具体的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]

这是map的传统签名。 （注意由于Scala的面向对象特性，输入列表参数消失了，因为它现在是单调度OO系统中每个方法都具有的隐式接收器参数。）然后它从具体List推广到更多一般IterableLike

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

现在，它将IterableLike结果集合替换为一个可以产生任何东西的函数。

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

我真的相信是不是很难理解。 实际上只需要几个智力工具：

1. 你需要知道（大致）是什么map 。 如果你只提供了没有方法名称的类型签名，我承认，要弄清楚发生了什么将会困难得多。 但既然你已经知道应该做什么map ，并且你知道它的类型签名应该是什么，你可以快速扫描签名并关注异常，例如“为什么这个map将两个函数作为参数，而不是一个？”
2. 您需要能够实际读取类型签名。 但即使你以前从未见过Scala，这应该很容易，因为它实际上只是你已经从其他语言中学到的类型语法的混合：VB.NET使用方括号进行参数多态，并使用箭头表示返回类型和冒号分隔名称和类型，实际上是常态。
3. 您需要大致了解泛型编程的含义。 （这是不是很难搞清楚，因为它的名字基本上都规定了：它真的只是一种通用的方式编程）。

这三者都不应该给任何专业甚至是业余爱好者的程序员带来严重的麻烦。 map已成为过去50年来设计的几乎所有语言的标准功能，不同语言具有不同语法的事实应该对任何使用HTML和CSS设计网站的人都很明显，你甚至无法订阅编程相关的邮件列表没有来自圣斯捷潘诺夫教堂的一些恼人的C ++粉丝，解释了泛型编程的优点。

是的，Scala 很复杂。 是的，Scala拥有人类已知的最复杂的类型系统之一，可以与Haskell，Miranda，Clean或Cyclone等语言相媲美甚至超越。 但是，如果复杂性是反对编程语言成功的一个论据，那么C ++很久以前就已经死了，我们都会编写Scheme。 Scala很可能不会成功的原因有很多，但程序员在坐在键盘前不能打开他们的大脑这一事实可能不会是主要原因。

---

#7楼

好吧，我可以理解你的痛苦，但是，坦率地说，像你我这样的人 - 或几乎任何常规的Stack Overflow用户 - 都不是常规。

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

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

考虑到这些因素，我认为：

1. 任何人（如在大多数人中）遇到过那种类型的签名都会模仿Scala，如果他们预先处理它，就会模仿Scala，如果他们喜欢Scala，它会认为它是Scala权力的象征。

2. 如果没有增强文档来提供用法示例并清楚地解释方法的用途以及如何使用它，那么它可能会减少Scala的采用。

3. 从长远来看，这无关紧要。 Scala 可以做这样的事情会使为Scala编写的库更强大，更安全。 这些库和框架将吸引程序员使用强大的工具。

4. 喜欢简单性和直接性的程序员将继续使用PHP或类似语言。

唉，Java程序员很多都是电动工具，所以，在回答这个问题时，我刚刚修改了我对主流Scala采用的期望。 毫无疑问，Scala将成为主流语言。 不是C主流，但可能是Perl主流或PHP主流。

说到Java，你有没有替换类加载器？ 你有没有看过这涉及到什么？ 如果你看看框架编写者所做的那些，Java可能会很吓人。 只是大多数人没有。 同样的事情适用于Scala，恕我直言，但早期采用者倾向于在他们遇到的每一块岩石下面看，看看是否有隐藏在那里的东西。

---

#8楼

我希望这不是“遗书”，但我能看出你的观点。 你同时发现了Scala的优势和问题：它的可扩展性 。 这使我们可以实现库中的大多数主要功能。 在其他一些语言中，将内置具有map或collect类的序列，并且没有人必须看到编译器必须经历的所有箍以使它们顺利地工作。 在Scala中，它都在一个库中，因此是公开的。

事实上，复杂类型支持的map功能非常先进。 考虑一下：

scala> import collection.immutable.BitSet
import collection.immutable.BitSetscala> 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!)

了解如何始终获得最佳类型？ 如果将Int s映射到Int s，则会再次获得BitSet ，但如果将Int s映射到String s，则会得到一个通用Set 。 map的结果的静态类型和运行时表示都取决于传递给它的函数的结果类型。 即使该集合为空，这也有效，因此该函数永远不会应用！ 据我所知，没有其他具有同等功能的集合框架。 然而，从用户的角度来看，事情应该是如何运作的。

我们遇到的问题是，所有使这种情况发生的聪明技术都会泄漏到类型签名中，这些签名变得庞大而可怕。 但也许用户不应该默认显示map的完整类型签名？ 如果她在BitSet查找map ，她得到了：

map(f: Int => Int): BitSet     (click here for more general type)

文档不会出现在这种情况下，因为从用户的角度来看，map确实具有类型(Int => Int) => BitSet 。 但是map也有一个更通用的类型，可以通过点击另一个链接进行检查。

我们尚未在我们的工具中实现这样的功能。 但我相信我们需要做到这一点，以避免吓跑人们并提供更多有用的信息。 有了这样的工具，希望智能框架和图书馆不会成为自杀笔记。

---

#9楼

不幸的是，你给出的地图签名对于地图是不正确的，并且确实存在合法的批评。

第一个批评是通过颠覆地图的签名，我们有一些更普遍的东西。 认为默认情况下这是一种美德是一种常见的错误。 事实并非如此。 map函数被很好地定义为协变函子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]

当然它失败了 - 它不够通用！ 此外，它略有不同（请注意，您可以通过身份仿函数运行遍历来获取映射）。 但是，我怀疑如果库编写者更了解库文档的一般化，这些文章已经很好地记录了（应用程序编程与前面提到的效果），那么我们就不会看到这个错误了。

其次，map函数是Scala中的一个特例，因为它用于for-comprehension。 不幸的是，这意味着装备更好的图书馆设计师不能忽视这个错误而不会牺牲理解的语法糖。 换句话说，如果Scala库设计者要销毁一个方法，那么这很容易被忽略，但请不要映射！

我希望有人能够说出来，因为实际上，解决Scala坚持做出的错误会变得更加困难，显然是出于我强烈反对的原因。 也就是说，“来自普通程序员的不负责任的反对意见（即太难了！）”的解决方案不是“安抚他们使他们更容易”，而是提供指导和帮助以成为更好的程序员。 我自己和斯卡拉的目标是在这个问题上争论，但回到你的观点。

您可能正在提出自己的观点，预测“普通程序员”的具体回答。 也就是说，那些会声称“但太复杂了！”的人。 或者其他一些。 这些是你所指的Yegges或Blochs。 我对反智主义/实用主义运动的这些人的回应非常苛刻，我已经预料到会有一连串的反应，所以我会省略它。

我真的希望Scala库可以改进，或者至少可以将错误安全地隐藏在角落里。 Java是一种语言，“尝试做任何有用的事情”是如此昂贵，以至于它通常是不值得的，因为绝大多数错误根本无法避免。 我恳请斯卡拉不要走同样的道路。

---

#10楼

Scala社区可以帮助减轻Scala新手程序员的恐惧的一种方法是专注于练习并通过示例进行教学 - 很多例子从小开始逐渐变大。 以下是一些采用这种方法的网站：

• 每日斯卡拉
• 学习斯卡拉小咬
• 斯卡拉

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

---

#11楼

我认为该方法的主要问题是(implicit bf : CanBuildFrom[Repr, B, That])没有任何解释。 即使我知道隐含的参数是什么，但没有任何迹象表明这会如何影响调用。 追逐scaladoc只会让我更加困惑（很少有与CanBuildFrom相关的类甚至都有文档）。

我认为一个简单的“ bf范围内必须有一个隐式对象，为类型B对象提供构建器到返回类型中” That会有所帮助，但当你真正想做的就是映射时，这是一个令人兴奋的概念A 's到B的。 事实上，我不确定这是对的，因为我不知道Repr的类型是什么， Traversable的文档肯定没有任何线索。

所以，我有两个选择，他们都不愉快：

• 假设它只是工作旧地图如何工作以及地图如何在大多数其他语言中工作
• 深入研究源代码

我知道Scala本质上暴露了这些东西如何工作的内容，并且最终这提供了一种方法来执行oxbow_lakes所描述的内容。 但这是签名中的分心。

---

#12楼

我完全同意这个问题和马丁的回答:)。 即使在Java中，由于额外的噪声，使用泛型读取javadoc也比应该更难。 这在Scala中是复杂的，其中隐含参数被用在问题的示例代码中（而implicits做非常有用的收集变形的东西）。

我认为语言本身并不存在问题 - 我认为这更像是一个工具问题。 虽然我同意JörgWMittag所说的内容，但我认为看看scaladoc（或IDE中某种类型的文档） - 它应该需要尽可能少的脑力来确定方法是什么，需要什么以及返回什么。 没有必要在一点纸上破解一些代数来获得它:)

确定IDE需要一种很好的方式来显示任何变量/表达式/类型的所有方法（与Martin的示例一样，可以将所有泛型内联，因此它很好且易于理解）。 我也喜欢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，那]文本突出显示'那'，例如。

也许一个小图标可以用于[]声明和（隐式...）块，所以它清楚有一点声明崩溃了吗？ 它难以使用令牌，但我会使用。 目前...

def map.(f: A => B).: That

因此，默认情况下，类型系统的'noise'隐藏在人们需要查看的主要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。泛型中的协变和逆变类型也会增加很多噪声，这些噪声可以以更容易的方式呈现给用户。

---

#13楼

根本不知道斯卡拉，但几周前我读不懂Clojure。 现在我可以阅读其中的大部分内容，但除了最简单的例子之外，不能写任何东西。 我怀疑斯卡拉没有什么不同。 根据你的学习方式，你需要一本好的书或课程。 只要阅读了上面的映射声明，我也许它的1/3。

我认为更大的问题不是这些语言的语法，而是采用并内化使它们可用于日常生产代码的范例 。 对我来说，Java并不是C ++的巨大飞跃，这不是C的巨大飞跃，这不是Pascal，也不是Basic等的飞跃......但是像Clojure这样的函数式语言的编码是一个巨大的飞跃（对于我无论如何）。 我想在Scala中你可以用Java风格或Scala风格编写代码。 但是在Clojure中，你会创造一些混乱，试图保持你的命令式习惯来自Java。

---

#14楼

我是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")

这种多态性是正确的。

现在，被授予，它不是主流范式，它会吓跑很多人。 但是，它也会吸引许多重视其表现力和优雅的人。

---

#15楼

使用网站中的错误消息怎么样？

那么什么时候需要将现有类型与适合DSL的自定义类型集成在一起。 必须对关联，优先级，隐式转换，隐式参数，更高种类以及可能存在类型等问题进行良好的教育。

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

---

#16楼

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

---

#17楼

我也有牛津大学的数学学位！ 我花了一段时间来“获取”新的收藏品。 但是我现在非常喜欢它。 事实上，'map'的输入是我在2.7中遇到麻烦的第一件大事（也许是因为我做的第一件事就是将其中一个集合类子类化）。

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

我主要担心的是这个问题：什么时候2.8会被释放？ bug报告什么时候会停止进入呢？ 让scala团队咬掉的东西超过他们可以咀嚼的2.8 /试图一次改变太多？

在添加任何其他新东西之前，我真的希望看到2.8稳定发布作为优先级，并且想知道（从旁观看时）是否可以对scala编译器的开发路线图的管理方式进行一些改进。

---

#18楼

这会让人们去Scala吗？

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

但我确实认为Scala的受欢迎程度将低于今天的Java，因为我认为下一个主流语言必须大大简化，我认为实现这一目标的唯一方法是纯粹的不变性，即像HTML一样的声明，但图灵完成。 然而，我有偏见是因为我正在开发这样一种语言，但我只是在排除了几个月的研究后才这样做，Scala不能满足我的需要。

这是否会让Scala在商业世界中成为一个不好的名字，作为学术玩具，只有专门的博士生才能理解？ CTO和软件负责人是否会受到惊吓？

我不认为Scala的声誉会受到Haskell复杂性的影响。 但我认为有些人会推迟学习它，因为对于大多数程序员来说，我还没有看到强制他们使用Scala的用例，他们会拖延学习它。 也许高度可扩展的服务器端是最引人注目的用例。

而且，对于主流市场，首先学习Scala不是一种“新鲜空气”，其中一个是立即编写程序，例如首先使用HTML或Python。 在得知所有从一开始就绊倒的细节之后，Scala往往会在你身上成长。 但是，如果我从一开始就阅读Scala编程，我对学习曲线的经验和看法会有所不同。

图书馆重新设计了一个明智的想法吗？

当然。

如果您在商业上使用Scala，您是否担心这一点？ 您是打算立即采用2.8还是等待看看会发生什么？

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

---

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

2.8 Scala集合使用构建器抽象是一种合理的设计原则。 我想探讨下面的两个设计权衡。

1. 只写代码：在写完这一部分之后，我读了Carl Smotricz的评论 ，该评论与我期望的权衡是一致的。 James Strachan和davetron5000的评论一致认为，那个（它甚至不是那个[B]）的含义和隐含的机制并不容易直观地掌握。 在下面的问题＃2中看到我对monoid的使用，我认为这更明确。 Derek Mahar的评论是关于编写Scala的，但是阅读那些不是“在常见情况下”的其他人的Scala。

   我读过有关Scala的一个批评是，编写它比阅读其他人编写的代码更容易。 我发现这种情况偶尔会出于各种原因（例如编写函数的方法，自动闭包，DSL单元等），但如果这是主要因素，我还是未定。 这里使用隐式函数参数有优缺点。 从好的方面来说，它可以减少冗长并自动选择构建器对象。 在Odersky的示例中 ，从BitSet（即Set [Int]）到Set [String]的转换是隐式的。 不熟悉的代码读者可能不知道集合的类型是什么，除非他们可以很好地推断当前包范围内可能存在的所有潜在的隐形构造候选者。 当然，有经验的程序员和代码编写者会知道BitSet仅限于Int，因此String的映射必须转换为不同的集合类型。 但是哪种收藏类型？ 它没有明确指定。

2. AD-HOC收藏设计：在写完这一部分之后，我阅读了Tony Morris的评论，并意识到我的观点几乎相同。 也许我更详细的阐述会更清楚地说明这一点。

   在“与类型的战斗位腐”Odersky＆Moors中，提出了两个用例。 它们是BitSet对Int元素的限制，Map是对元组元素的对，并且作为一般元素映射函数A => B必须能够构建备用目标集合类型的原因提供。 然而，从类别理论的角度来看，这是有缺陷的。 为了在类别理论中保持一致并因此避免极端情况，这些集合类型是仿函数，其中每个态射A => B必须映射在同一仿函数类别中的对象，List [A] => List [B]，BitSet [A] => BitSet [B]。 例如，Option是一个仿函数，可以被视为一个Some（对象）和None的集合的集合。 从Option's None或List's Nil到没有“空”状态的其他仿函数，没有一般的地图。

   这里有一个权衡设计选择。 在我的新语言的集合库的设计中，我选择将所有内容都变成一个函子，这意味着如果我实现了一个BitSet，它需要支持所有元素类型，通过使用非位字段内部表示来呈现非整数类型参数，该功能已在Scala中继承的Set中。 我的设计中的Map只需要映射它的值，它可以提供一个单独的非functor方法来映射它的（键，值）对元组。 一个优点是每个仿函数通常也是一个应用程序，也许也是一个monad。 因此，元素类型之间的所有函数，例如A => B => C => D => ...，被自动提升到提升的应用类型之间的函数，例如List [A] => List [B] => List [ C] => List [D] => ....对于从仿函数到另一个集合类的映射，我提供了一个map过载，它采用了一个monoid，例如Nil，None，0，“”，Array（）等。因此构建器抽象函数是monoid的append方法，并且显式地作为必要的输入参数提供，因此没有不可见的隐式转换。 （Tangent：此输入参数还可以附加到非空幺半群，Scala的地图设计无法做到这一点。）此类转换是同一迭代过程中的映射和折叠。 此外，我提供了一个可移动的，在类别意义上，“使用效果的应用程序编程”McBride和Patterson，它还可以在任何遍历到任何应用程序的单次迭代过程中实现map + fold，其中大多数集合类都是。 状态monad也是一个应用程序，因此是任何可遍历的完全通用的构建器抽象。

   因此，Scala集合是“ad-hoc”的，因为它不是基于范畴理论，而类别理论是更高层次指称语义的本质。 虽然Scala的隐式构建器最初看起来比构造函数+ monoid builder + traversable“更普遍” - > applicative，但它们并未被证明与任何类别一致，因此我们不知道它们遵循什么规则。最一般的意义和角落案件将给予他们可能不遵守任何类别模型。 添加更多变量使得更为通用的东西是不正确的，这是类别理论的巨大好处之一，它提供了一些规则，通过这些规则来维持一般性，同时提升到更高级别的语义。 集合是一个类别。

   我读到某个地方，我认为是Odersky，作为库设计的另一个理由，是纯函数式编程具有有限递归和速度的成本，其中不使用尾递归。 到目前为止我遇到的每种情况都没有发现使用尾递归很困难。

---

另外，我在脑子里想到一个不完整的想法，Scala的一些权衡是由于试图成为一种可变和不可变的语言，不像Haskell或我正在开发的语言。 这与托尼莫里斯关于理解的评论一致。 在我的语言中，没有循环，也没有可变构造。 我的语言将位于Scala之上（目前为止）并且欠其很多，如果Scala没有通用类型系统和可变性，这将是不可能的。 虽然这可能不是真的，因为我认为Odersky＆Moors（“与类型斗争”）不正确地指出Scala是唯一具有更高种类的OOP语言，因为我验证了（我自己和通过Bob Harper）标准ML有它们。 同样出现SML的类型系统可能具有同等的灵活性（自20世纪80年代以来），这可能不容易理解，因为语法与Scala并没有太多类似于Java（和C ++ / PHP）。 无论如何，这不是对Scala的批评，而是试图对权衡进行不完整的分析，这是我希望与这个问题密切相关的。 Scala和SML不会受到Haskell无法进行菱形多重继承的影响 ，这很关键，我理解为什么Haskell Prelude中的这么多函数会针对不同类型重复。