我刚刚开始研究即将发布的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的优点和问题：它的可扩展性。这使我们能够实现库中的大多数主要功能。在其他一些语言中，带有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。但地图也有一个更通用的类型，可以通过单击另一个链接来查看。
我们还没有在工具中实现这样的功能。但我认为我们需要这样做，以避免吓跑人们，并提供更多有用的信息。有了这样的工具，希望智能框架和库不会成为自杀笔记。
