Scala 2.8 藏书库是“历史上最长的遗书”吗？

Is the Scala 2.8 collections library a case of "the longest suicide note in history"?

提问by oxbow_lakes

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

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

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

...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 languagenow have to make sense of method signatures like:

...在任何一个版本中都可以使用。该库非常有用：事实上，它非常棒。然而，那些以前不熟悉 Scala 并四处摸索以了解该语言的人现在必须理解方法签名，例如：

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

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 有可能成为下一个 Java（或 /C/C++/C#）——我不相信它的创造者将它瞄准那个市场——但我认为 Scala 成为/肯定是可行的下一个 Ruby 或 Python（即获得重要的商业用户群）

• 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 playthingthat 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?

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

Steve Yeggeonce 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 FUDwith this API (similarly to how Josh Bloch scared the JCPout of adding closures to Java).

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

Note- I should be clear that, whilst I believe that Joshua Blochwas 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.

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

---

---

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 Scalafor about a year (also commercially).

尽管我的妻子和同事一直告诉我，我并不认为我是个白痴：我拥有牛津大学的良好数学学位，我已经从事商业编程近 12 年，在Scala 工作了大约一年（也是商业上的）。

Note the inflammatory subject title is a quotation made about the manifesto of a UK political partyin 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.

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

回答by Martin Odersky

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 mapor collectwould 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.

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

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

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

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!)

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 supposedto work.

看看你如何总是得到最好的类型？如果您将Ints映射到Ints，您将再次得到 a BitSet，但如果您将Ints映射到Strings，您将得到一个将军Set。映射结果的静态类型和运行时表示都取决于传递给它的函数的结果类型。即使集合为空，这也有效，因此永远不会应用该功能！据我所知，没有其他具有等效功能的集合框架。然而，从用户的角度来看，这就是事情应该如何运作。

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 mapin BitSetshe got:

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

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

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

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

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.

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

回答by J?rg W Mittag

I do not have a PhD, nor any other kind of degree neither in CS nor math nor indeed any other field. I have no prior experience with Scala nor any other similar language. I have no experience with even remotely comparable type systems. In fact, the only language that I have more than just a superficial knowledge of which even hasa type system is Pascal, not exactly known for its sophisticated type system. (Although it doeshave range types, which AFAIK pretty much no other language has, but that isn't really relevant here.) The other three languages I know are BASIC, Smalltalk and Ruby, none of which even have a type system.

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

And yet, I have no trouble at all understanding the signature of the mapfunction you posted. It looks to me like pretty much the same signature that maphas in every other language I have ever seen. The difference is that this version is more generic. It looks more like a C++ STL thing than, say, Haskell. In particular, it abstracts away from the concrete collection type by only requiring that the argument is IterableLike, and also abstracts away from the concrete return type by only requiring that an implicit conversion function exists which can build somethingout of that collection of result values. Yes, that is quite complex, but it really is only an expression of the general paradigm of generic programming: do not assume anything that you don't actually have to.

然而，我完全理解map你发布的函数的签名。在我看来，它与我map见过的所有其他语言中的签名几乎相同。不同的是，这个版本更通用。它看起来更像是 C++ STL，而不是 Haskell。特别是，它通过只要求参数 is 来抽象出具体的集合类型IterableLike，并且还通过只要求存在一个隐式转换函数来抽象出具体的返回类型，该函数可以从结果值的集合中构建一些东西。是的，这非常复杂，但它实际上只是泛型编程的一般范式的一种表达：不要假设您实际上不必做的任何事情。

In this case, mapdoes not actually needthe collection to be a list, or being ordered or being sortable or anything like that. The only thing that mapcares about is that it can get access to all elements of the collection, one after the other, but in no particular order. And it does not need to know what the resulting collection is, it only needs to know how to build it. So, that is what its type signature requires.

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

So, instead of

所以，而不是

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

which is the traditional type signature for map, it is generalized to not require a concrete Listbut rather just an IterableLikedata structure

这是 的传统类型签名map，它被概括为不需要具体的List，而只需要IterableLike数据结构

map :: (IterableLike i, IterableLike j) ? (a → b) → i → j

which is then further generalized by only requiring that a function exists that can convertthe result to whatever data structure the user wants:

然后通过只要求存在一个可以将结果转换为用户想要的任何数据结构的函数来进一步推广：

map :: IterableLike i ? (a → b) → i → ([b] → c) → c

I admit that the syntax is a bit clunkier, but the semantics are the same. Basically, it starts from

我承认语法有点笨拙，但语义是相同的。基本上，它从

def map[B](f: (A) ? B): List[B]

which is the traditional signature for map. (Note how due to the object-oriented nature of Scala, the input list parameter vanishes, because it is now the implicit receiver parameter that every method in a single-dispatch OO system has.) Then it generalized from a concrete Listto a more general IterableLike

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

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

Now, it replaces the IterableLikeresult collection with a function that produces, well, really just about anything.

现在，它IterableLike用一个函数替换了结果集合，这个函数产生了，嗯，几乎任何东西。

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

Which I really believe is not thathard to understand. There's really only a couple of intellectual tools you need:

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

1. You need to know (roughly) what mapis. If you gave onlythe type signature without the name of the method, I admit, it would be a lot harder to figure out what is going on. But since you already knowwhat mapis supposed to do, and you know what its type signature is supposed to be, you can quickly scan the signature and focus on the anomalies, like "why does this maptake two functions as arguments, not one?"
2. You need to be able to actually readthe type signature. But even if you have never seen Scala before, this should be quite easy, since it really is just a mixture of type syntaxes you already know from other languages: VB.NET uses square brackets for parametric polymorphism, and using an arrow to denote the return type and a colon to separate name and type, is actually the norm.
3. You need to know roughly what generic programming is about. (Which isn't thathard to figure out, since it's basically all spelled out in the name: it's literally just programming in a generic fashion).

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

None of these three should give any professional or even hobbyist programmer a serious headache. maphas been a standard function in pretty much every language designed in the last 50 years, the fact that different languages have different syntax should be obvious to anyone who has designed a website with HTML and CSS and you can't subscribe to an even remotely programming related mailinglist without some annoying C++ fanboy from the church of St. Stepanov explaining the virtues of generic programming.

这三个都不应该让任何专业甚至业余程序员严重头痛。map在过去的 50 年里，几乎所有设计的语言都已成为标准功能，对于使用 HTML 和 CSS 设计网站的人来说，不同语言具有不同语法的事实应该是显而易见的，而且您甚至无法订阅远程编程相关的邮件列表，没有来自 St. Stepanov 教堂的一些烦人的 C++ 粉丝解释泛型编程的优点。

Yes, Scala iscomplex. Yes, Scala has one of the most sophisticated type systems known to man, rivaling and even surpassing languages like Haskell, Miranda, Clean or Cyclone. But if complexity were an argument against success of a programming language, C++ would have died long ago and we would all be writing Scheme. There are lots of reasons why Scala will very likely not be successful, but the fact that programmers can't be bothered to turn on their brains before sitting down in front of the keyboard is probably not going to be the main one.

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

回答by skyde

Same thing in C++:

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

回答by Daniel C. Sobral

Well, I can understand your pain, but, quite frankly, people like you and I -- or pretty much any regular Stack Overflow user -- are not the rule.

好吧，我能理解你的痛苦，但坦率地说，像你我这样的人——或者几乎任何普通的 Stack Overflow 用户——都不是规则。

What I mean by that is that... most programmers won't care about that type signature, because they'll never see them! They don't read documentation.

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

As long as they saw some example of how the code works, and the code doesn't fail them in producing the result they expect, they won't ever look at the documentation. When that fails, they'll look at the documentation and expect to see usage examplesat the top.

只要他们看到代码如何工作的一些示例，并且代码没有使他们无法产生他们期望的结果，他们就永远不会看文档。如果失败，他们会查看文档并希望在顶部看到使用示例。

With these things in mind, I think that:

考虑到这些问题，我认为：

1. Anyone (as in, most people) who ever comes across that type signature will mock Scala to no end if they are pre-disposed against it, and will consider it a symbol of Scala's power if they like Scala.

2. If the documentation isn't enhanced to provide usage examples and explain clearly what a method is for and how to use it, it can detract from Scala adoption a bit.

3. In the long run, it won't matter. That Scala cando stuff like that will make libraries written for Scala much more powerful and safer to use. These libraries and frameworks will attract programmers atracted to powerful tools.

4. Programmers who like simplicity and directness will continue to use PHP, or similar languages.

1. 任何遇到过这种类型签名的人（就像大多数人一样）如果对它有偏见，就会无休止地嘲笑 Scala，如果他们喜欢 Scala，就会认为它是 Scala 力量的象征。

2. 如果文档没有得到增强以提供使用示例并清楚地解释方法的用途以及如何使用它，它可能会有点影响 Scala 的采用。

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

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

Alas, Java programmers are much into power tools, so, in answering that, I have just revised my expectation of mainstream Scala adoption. I have no doubt at all that Scala will become a mainstream language. Not C-mainstream, but perhaps Perl-mainstream or PHP-mainstream.

唉，Java 程序员非常喜欢强大的工具，因此，在回答这个问题时，我刚刚修改了我对主流 Scala 采用的期望。我毫不怀疑 Scala 将成为一种主流语言。不是 C 主流，但可能是 Perl 主流或 PHP 主流。

Speaking of Java, did you ever replace the class loader? Have you ever looked into what that involves? Java can be scary, if you look at the places framework writers do. It's just that most people don't. The same thing applies to Scala, IMHO, but early adopters have a tendency to look under each rock they encounter, to see if there's something hiding there.

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

回答by Erik Engbrecht

Is this going to put people off coming to Scala?

这会让人们不愿意来 Scala 吗？

Yes, but it will also prevent people from being put off. I've considered the lack of collections that use higher-kinded types to be a major weakness ever since Scala gained support for higher-kinded types. It make the API docs more complicated, but it really makes usage more natural.

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

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?

这是否会让 Scala 在商业世界中声名狼藉，因为它是一种只有敬业的博士生才能理解的学术玩物？首席技术官和软件负责人会被吓跑吗？

Some probably will. I don't think Scala is accessible to many "professional" developers, partially due to the complexity of Scala and partly due to the unwillingness of many developers to learn. The CTOs who employ such developers will rightly be scared off.

有些人可能会。我认为许多“专业”开发人员无法使用 Scala，部分原因是 Scala 的复杂性，部分原因是许多开发人员不愿意学习。雇用此类开发人员的 CTO 理所当然地会被吓跑。

Was the library re-design a sensible idea?

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

Absolutely. It makes collections fit much better with the rest of the language and the type system, even if it still has some rough edges.

绝对地。它使集合更适合语言的其余部分和类型系统，即使它仍然有一些粗糙的边缘。

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?

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

I'm not using it commercially. I'll probably wait until at least a couple revs into the 2.8.x series before even trying to introduce it so that the bugs can be flushed out. I'll also wait to see how much success EPFL has in improving its development a release processes. What I'm seeing looks hopeful, but I work for a conservative company.

我没有在商业上使用它。在尝试引入 2.8.x 系列之前，我可能会等到至少有几个版本，以便可以清除错误。我也会等着看 EPFL 在改进其开发和发布流程方面取得了多大的成功。我所看到的看起来很有希望，但我为一家保守的公司工作。

One the more general topic of "is Scala too complicated for mainstream developers?"...

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

Most developers, mainstream or otherwise, are maintaining or extending existing systems. This means that most of what they use is dictated by decisions made long ago. There are still plenty of people writing COBOL.

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

Tomorrow's mainstream developer will work maintaining and extending the applications that are being built today. Many of these applications are not being built by mainstream developers. Tomorrow's mainstream developers will use the language that is being used by today's most successful developers of new applications.

明天的主流开发人员将致力于维护和扩展今天正在构建的应用程序。许多这些应用程序不是由主流开发人员构建的。明天的主流开发人员将使用当今最成功的新应用程序开发人员正在使用的语言。

回答by Derek Mahar

One way that the Scala community can help ease the fear of programmers new to Scala is to focus on practice and to teach by example--a lot of examples that start small and grow gradually larger. Here are a few sites that take this approach:

Scala 社区可以帮助减轻对 Scala 新手的恐惧的一种方法是专注于实践并通过示例进行教学——许多示例从小处开始并逐渐变大。以下是一些采用这种方法的网站：

• Daily Scala
• Learning Scala in small bites
• Simply Scala

• 每日斯卡拉
• 一点一点地学习 Scala
• 简单的斯卡拉

After spending some time on these sites, one quickly realizes that Scala and its libraries, though perhaps difficult to design and implement, are not so difficult to use, especially in the common cases.

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

回答by Carl Smotricz

I have an undergraduate degree from a cheap "mass market" US university, so I'd say I fall into the middle of the user intelligence (or at least education) scale :) I've been dabbling with Scala for just a few months and have worked on two or three non-trivial apps.

我有一个廉价的“大众市场”美国大学的本科学位，所以我会说我属于用户智能（或至少是教育）规模的中间:) 我已经涉足 Scala 几个月了并且已经开发了两三个重要的应用程序。

Especially now that IntelliJ has released their fine IDE with what IMHO is currently the best Scala plugin, Scala development is relatively painless:

尤其是现在 IntelliJ 已经发布了他们的优秀 IDE，IMHO 是目前最好的 Scala 插件，Scala 开发相对轻松：

• I find I can use Scala as a "Java without semicolons," i.e. I write similar-looking code to what I'd do in Java, and benefit a little from syntactic brevity such as that gained by type inference. Exception handling, when I do it at all, is more convenient. Class definition is much less verbose without the getter/setter boilerplate.

• Once in a while I manage to write a single line to accomplish the equivalent of multiple lines of Java. Where applicable, chains of functional methods like map, fold, collect, filter etc. are fun to compose and elegant to behold.

• Only rarely do I find myself benefitting from Scala's more high-powered features: Closures and partial (or curried) functions, pattern matching... that kinda thing.

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

• 有时我设法编写一行来完成相当于多行 Java 的工作。在适用的情况下，映射、折叠、收集、过滤等功能方法链很有趣，而且看起来很优雅。

• 我很少发现自己受益于 Scala 更强大的功能：闭包和部分（或柯里化）函数、模式匹配……诸如此类。

As a newbie, I continue to struggle with the terse and idiomatic syntax. Method calls without parameters don't need parentheses except where they do; cases in the match statement need a fat arrow ( =>), but there are also places where you need a thin arrow ( ->). Many methods have short but rather cryptic names like /:or \:- I can get my stuff done if I flip enough manual pages, but some of my code ends up looking like Perl or line noise. Ironically, one of the most popular bits of syntactic shorthand is missing in action: I keep getting bitten by the fact that Intdoesn't define a ++method.

作为一个新手，我继续与简洁和惯用的语法作斗争。没有参数的方法调用不需要括号，除非它们需要；match 语句中的 case=>需要一个粗箭头 ( ->) ，但也有一些地方需要一个细箭头 ( )。许多方法都有简短但相当神秘的名称，例如/:or \:- 如果我翻阅足够多的手册页，我可以完成我的工作，但是我的一些代码最终看起来像 Perl 或行噪声。具有讽刺意味的是，最流行的语法速记之一在行动中缺失：我一直被Int没有定义++方法的事实所困扰。

This is just my opinion: I feel like Scala has the power of C++ combined with the complexity and readability of C++. The syntactic complexity of the language also makes the API documentation hard to read.

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

Scala is very well thought outand brilliant in many respects. I suspect many an academic would love to program in it. However, it's also full of cleverness and gotchas, it has a much higher learning curve than Java and is harder to read. If I scan the fora and see how many developers are still struggling with the finer points of Java, I cannot conceive of Scala ever becoming a mainstream language. No company will be able to justify sending its developers on a 3 week Scala course when formerly they only needed a 1 week Java course.

Scala在许多方面都经过深思熟虑和出色的表现。我怀疑许多学者都喜欢在其中编程。然而，它也充满了聪明才智和陷阱，它的学习曲线比 Java 高得多，而且更难阅读。如果我浏览论坛，看看有多少开发人员仍在为 Java 的精髓而苦苦挣扎，我无法想象 Scala 会成为主流语言。没有一家公司能够证明让开发人员参加 3 周 Scala 课程的理由，因为他们以前只需要 1 周的 Java 课程。

回答by davetron5000

I think primary problem with that method is that the (implicit bf : CanBuildFrom[Repr, B, That])goes without any explanation. Even though I know what implicit arguments are there's nothing indicating how this affects the call. Chasing through the scaladoc only leaves me more confused (few of the classes related to CanBuildFromeven have documentation).

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

I think a simple "there must be an implicit object in scope for bfthat provides a builder for objects of type Binto the return type That" would help somewhat, but it's kind of a heady concept when all you really want to do is map A's to B's. In fact, I'm not sure that's right, because I don't know what the type Reprmeans, and the documentation for Traversablecertainly gives no clue at all.

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

So, I'm left with two options, neither of them pleasant:

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

• Assume it will just work how the old map works and how map works in most other languages
• Dig into the source code some more

• 假设它仅适用于旧地图的工作方式以及地图在大多数其他语言中的工作方式
• 深入研究源代码

I get that Scala is essentially exposing the guts of how these things work and that ultimately this is provide a way to do what oxbow_lakes is describing. But it's a distraction in the signature.

我知道 Scala 本质上是在揭示这些东西是如何工作的，最终这提供了一种方法来完成 oxbow_lakes 所描述的事情。但这会分散签名的注意力。

回答by Thomas Heywood

I'm a Scala beginner and I honestly don't see a problem with that type signature. The parameter is the function to map and the implicit parameter the builder to return the correct collection. Clear and readable.

我是 Scala 初学者，老实说，我认为该类型签名没有问题。参数是要映射的函数，是构建器返回正确集合的隐式参数。清晰易读。

The whole thing's quite elegant, actually. The builder type parameters let the compiler choose the correct return type while the implicit parameter mechanism hides this extra parameter from the class user. I tried this:

实际上，整个事情非常优雅。构建器类型参数让编译器选择正确的返回类型，而隐式参数机制对类用户隐藏了这个额外的参数。我试过这个：

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

That's polymorphism done right.

这就是多态性做得对。

Now, granted, it's not a mainstream paradigm and it will scare away many. But, it will also attract many who value its expressiveness and elegance.

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

回答by Tony Morris

Unfortunately the signature for map that you gave is an incorrect one for map and there is indeed legitimate criticism.

不幸的是，您提供的地图签名是一个不正确的地图签名，确实存在合理的批评。

The first criticism is that by subverting the signature for map, we have something that is more general. It is a common error to believe that this is a virtue by default. It isn't. The map function is very well defined as a covariant functor Fx -> (x -> y) -> Fy with adherence to the two laws of composition and identity. Anything else attributed to "map" is a travesty.

第一个批评是，通过颠覆 map 的签名，我们得到了更通用的东西。认为这是一种默认的美德是一个常见的错误。不是。映射函数被很好地定义为协变函子 Fx -> (x -> y) -> Fy 并遵守组成和恒等式这两个定律。任何其他归因于“地图”的东西都是一种讽刺。

The given signature is something else, but it is not map. What I suspect it is trying to be is a specialised and slightly altered version of the "traverse" signature from the paper, The Essence of the Iterator Pattern. Here is its signature:

给定的签名是别的东西，但它不是地图。我怀疑它试图成为的是来自论文“迭代器模式的本质”的“遍历”签名的专门化且略有改动的版本。这是它的签名：

traverse :: (Traversable t, Applicative f) => (a -> f b) -> t a -> f (t b)

I shall convert it to Scala:

我会将其转换为 Scala：

def traverse[A, B](f: A => F[B], a: T[A])(implicit t: Traversable[T], ap: Applicative[F]): F[T[B]

Of course it fails -- it is not general enough! Also, it is slightly different (note that you can get map by running traverse through the Identity functor). However, I suspect that if the library writers were more aware of library generalisations that are well documented (Applicative Programming with Effects precedes the aforementioned), then we wouldn't see this error.

当然它失败了——它不够通用！此外，它略有不同（请注意，您可以通过遍历 Identity 函子来获取地图）。但是，我怀疑，如果库作者更了解有据可查的库泛化（Applicative Programming with Effects 在上述内容之前），那么我们就不会看到这个错误。

Second, the map function is a special-case in Scala because of its use in for-comprehensions. This unfortunately means that a library designer who is better equipped cannot ignore this error without also sacrificing the syntactic sugar of comprehensions. In other words, if the Scala library designers were to destroy a method, then this is easily ignored, but please not map!

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

I hope someone speaks up about it, because as it is, it will become harder to workaround the errors that Scala insists on making, apparently for reasons that I have strong objections to. That is, the solution to "the irresponsible objections from the average programmer (i.e. too hard!)" is not "appease them to make it easier for them" but instead, provide pointers and assistance to become better programmers. Myself and Scala's objectives are in contention on this issue, but back to your point.

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

You were probably making your point, predicting specific responses from "the average programmer." That is, the people who will claim "but it is too complicated!" or some such. These are the Yegges or Blochs that you refer to. My response to these people of the anti-intellectualism/pragmatism movement is quite harsh and I'm already anticipating a barrage of responses, so I will omit it.

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

I truly hope the Scala libraries improve, or at least, the errors can be safely tucked away in a corner. Java is a language where "trying to do anything useful" is so incredibly costly, that it is often not worth it because the overwhelming amount of errors simply cannot be avoided. I implore Scala to not go down the same path.

我真的希望 Scala 库有所改进，或者至少，错误可以安全地隐藏在角落里。Java 是一种语言，其中“尝试做任何有用的事情”成本非常高，以至于它通常不值得，因为无法避免大量错误。我恳求 Scala 不要走同样的路。