Scala 2.8 收藏库是“历史上最长的遗书"吗? [英] Is the Scala 2.8 collections library a case of "the longest suicide note in history"?

问题描述

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

I have just started to look at the Scala collections library re-implementation which is coming in the imminent 2.8 release. Those familiar with the library from 2.7 will notice that the library, from a usage perspective, has changed little. For example...

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

...可以在任一版本中使用.图书馆非常好用:事实上，它很棒.然而，那些以前不熟悉 Scala 并且四处摸索以了解该语言的人现在必须了解方法签名，例如:

...would work in either versions. The library is eminently useable: in fact it's fantastic. However, those previously unfamiliar with Scala and poking around to get a feel for the language now have to make sense of method signatures like:

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

对于如此简单的功能，这是一个令人生畏的签名，我发现自己很难理解.并不是说我认为 Scala 有可能成为下一个 Java(或/C/C++/C#)——我不相信它的创造者将它瞄准那个市场——但我认为它是/Scala 成为下一个 Ruby 或 Python 肯定是可行的(即获得重要的商业用户群)

For such simple functionality, this is a daunting signature and one which I find myself struggling to understand. Not that I think Scala was ever likely to be the next Java (or /C/C++/C#) - I don't believe its creators were aiming it at that market - but I think it is/was certainly feasible for Scala to become the next Ruby or Python (i.e. to gain a significant commercial user-base)

• 这会让人们不愿意来 Scala 吗?
• 这是否会让 Scala 在商业世界中声名狼藉，因为它是一个只有专门的博士生才能理解的学术玩物?首席技术官和软件负责人会被吓跑吗?
• 图书馆重新设计的想法是否明智?
• 如果您在商业上使用 Scala，您是否担心这一点?您打算立即采用 2.8 还是等着看会发生什么?

• Is this going to put people off coming to Scala?
• Is this going to give Scala a bad name in the commercial world as an academic plaything that only dedicated PhD students can understand? Are CTOs and heads of software going to get scared off?
• Was the library re-design a sensible idea?
• If you're using Scala commercially, are you worried about this? Are you planning to adopt 2.8 immediately or wait to see what happens?

Steve Yegge 曾经攻击 Scala(在我看来是错误的)，因为他认为其类型系统过于复杂.我担心有人会用这个 API 来传播FUD(类似于Josh Bloch 如何让 JCP 害怕向 Java 添加闭包).

Steve Yegge once attacked Scala (mistakenly in my opinion) for what he saw as its overcomplicated type-system. I worry that someone is going to have a field day spreading FUD with this API (similarly to how Josh Bloch scared the JCP out of adding closures to Java).

注意 - 我应该清楚这一点，虽然我相信 Joshua Bloch 在拒绝 BGGA 关闭提案方面具有影响力，除了他诚实地认为该提案代表错误之外，我不会将其归咎于任何其他原因.

Note - I should be clear that, whilst I believe that Joshua Bloch was influential in the rejection of the BGGA closures proposal, I don't ascribe this to anything other than his honestly-held beliefs that the proposal represented a mistake.

尽管我的妻子和同事一直告诉我，我并不认为我是白痴:我拥有 牛津大学，我从事商业编程近 12 年，并且在 Scala 大约一年(商业上也是如此).

Despite whatever my wife and coworkers keep telling me, I don't think I'm an idiot: I have a good degree in mathematics from the University of Oxford, and I've been programming commercially for almost 12 years and in Scala for about a year (also commercially).

请注意，煽动性主题的标题是引用英国政党宣言的内容 1980 年代初期.这个问题是主观的，但它是一个真正的问题，我已经把它变成了 CW，我想就此事发表一些意见.

Note the inflammatory subject title is a quotation made about the manifesto of a UK political party in the early 1980s. This question is subjective but it is a genuine question, I've made it CW and I'd like some opinions on the matter.

推荐答案

我希望这不是自杀笔记"，但我能理解你的观点.您同时发现了 Scala 的优势和问题:它的可扩展性.这让我们可以在库中实现大多数主要功能.在其他一些语言中，诸如 map 或 collect 之类的序列将被内置，并且没有人需要看到编译器必须经过的所有环节才能使它们顺利工作.在 Scala 中，这一切都在一个库中，因此是公开的.

I hope it's not a "suicide note", but I can see your point. You hit on what is at the same time both a strength and a problem of Scala: its extensibility. This lets us implement most major functionality in libraries. In some other languages, sequences with something like map or collect would be built in, and nobody has to see all the hoops the compiler has to go through to make them work smoothly. In Scala, it's all in a library, and therefore out in the open.

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

In fact the functionality of map that's supported by its complicated type is pretty advanced. Consider this:

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，但是如果你将 Ints 映射到 Strings，你得到一个通用的Set.映射结果的静态类型和运行时表示都取决于传递给它的函数的结果类型.即使集合为空，这也有效，因此永远不会应用该功能！据我所知，没有其他具有等效功能的集合框架.然而，从用户的角度来看，这就是应该工作的方式.

See how you always get the best possible type? If you map Ints to Ints you get again a BitSet, but if you map Ints to Strings, you get a general Set. Both the static type and the runtime representation of map's result depend on the result type of the function that's passed to it. And this works even if the set is empty, so the function is never applied! As far as I know there is no other collection framework with an equivalent functionality. Yet from a user perspective this is how things are supposed to work.

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

The problem we have is that all the clever technology that makes this happen leaks into the type signatures which become large and scary. But maybe a user should not be shown by default the full type signature of map? How about if she looked up map in BitSet she got:

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

文档不会在这种情况下撒谎，因为从用户的角度来看，地图确实具有 (Int => Int) => 类型.位集.但是map 还有一个更通用的类型，可以通过点击另一个链接来查看.

The docs would not lie in that case, because from a user perspective indeed map has the type (Int => Int) => BitSet. But map also has a more general type which can be inspected by clicking on another link.

我们尚未在我们的工具中实现此类功能.但我相信我们需要这样做，以避免吓跑人们并提供更多有用的信息.有了这样的工具，希望智能框架和库不会成为遗书.

We have not yet implemented functionality like this in our tools. But I believe we need to do this, to avoid scaring people off and to give more useful info. With tools like that, hopefully smart frameworks and libraries will not become suicide notes.

这篇关于Scala 2.8 收藏库是“历史上最长的遗书"吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！