我刚刚开始研究即将发布的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，你会担心吗？您是否计划立即采用2.8版本，还是等待结果？
Steve Yegge曾攻击Scala（在我看来是错误的），因为他认为Scala的类型系统过于复杂。我担心有人会用这个API来传播FUD（类似于Josh Bloch如何吓得JCP不敢向Java添加闭包）。
注意-我应该清楚，虽然我认为约书亚·布洛赫在拒绝BGGA关闭提案方面有影响力，但我不认为这是因为他诚实地认为该提案代表了错误。
尽管我的妻子和同事一直在告诉我，我并不认为自己是个白痴：我在牛津大学获得了很好的数学学位，我已经在商业编程近12年，在Scala编程大约一年（也是商业编程）。
请注意，煽动性主题标题引用了20世纪80年代初英国一个政党的宣言。这个问题是主观的，但这是一个真实的问题，我已经把它改成了CW，我想就此事发表一些意见。
我希望这不是“遗书”，但我明白你的意思。您发现了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。但地图也有一个更通用的类型，可以通过单击另一个链接来查看。
我们还没有在工具中实现这样的功能。但我认为我们需要这样做，以避免吓跑人们，并提供更多有用的信息。有了这样的工具，希望智能框架和库不会成为自杀笔记。
我没有博士学位，也没有任何其他学位，既没有计算机科学，也没有数学，也没有其他领域。我以前没有使用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很可能不会成功的原因有很多，但程序员在坐在键盘前不必费心动脑这一事实可能不是主要原因。
我拥有一所廉价的“大众市场”美国大学的本科学位，所以我可以说我处于用户智能（或至少是教育）的中等水平：）我涉足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。
未来的主流开发人员将致力于维护和扩展目前正在构建的应用程序。其中许多应用程序不是由主流开发人员构建的。未来的主流开发人员将使用当今最成功的新应用程序开发人员所使用的语言。
