我刚刚开始研究即将发布的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获得对更高级类型的支持以来,我一直认为缺少使用更高级类型类型的集合是一个主要缺点。它使API文档更加复杂,但确实使使用更加自然。

这是否会让scala在商业界成为一个只有专业的博士生才能理解的学术玩物?首席技术官和软件负责人会被吓跑吗?

有些人可能会。我不认为很多“专业”开发人员可以访问Scala,部分原因是Scala的复杂性,部分原因在于许多开发人员不愿意学习。雇佣此类开发人员的首席技术官们会被吓跑。

图书馆重新设计是否明智?

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

如果你在商业上使用scala,你会担心吗?您是否计划立即采用2.8版本,还是等待结果?

我没有在商业上使用它。我可能会等到2.8.x系列的至少两个版本之后,再尝试引入它,以便清除bug。我还将拭目以待EPFL在改进其开发和发布过程方面取得了多大成功。我所看到的似乎充满希望,但我在一家保守的公司工作。

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

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

未来的主流开发人员将致力于维护和扩展目前正在构建的应用程序。其中许多应用程序不是由主流开发人员构建的。未来的主流开发人员将使用当今最成功的新应用程序开发人员所使用的语言。

其他回答

我不知道该怎么告诉你,但我有剑桥大学的博士学位,我用的是2.8。

更严重的是,我几乎没有花时间使用2.7(它不会与我正在使用的Java库互操作),一个多月前才开始使用Scala。我对Haskell有一些经验(不多),但只是忽略了你担心的东西,并寻找与我的Java经验相匹配的方法(我以Java为生)。

所以:我是一个“新用户”,我并没有被推迟——事实上,它的工作方式与Java类似,这给了我足够的信心,可以忽略我不理解的部分。

(然而,我之所以选择Scala,部分原因是想看看是否要在工作中推动它,我现在还不打算这么做。让文档变得不那么吓人肯定会有所帮助,但让我惊讶的是,它仍在不断变化和开发中(公平地说,最让我吃惊的是它是多么棒,但变化紧随其后)。所以我想我想说的是,我更希望把有限的资源投入到最终的状态中——我认为他们不会期望很快就会如此流行。)

我希望这不是“遗书”,但我明白你的意思。您发现了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。但地图也有一个更通用的类型,可以通过单击另一个链接来查看。

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

使用站点中的错误消息如何?

当出现需要将现有类型与适合DSL的自定义类型集成的用例时,情况又会如何呢。一个人必须在关联、优先级、隐式转换、隐式参数、更高级的类型,以及可能存在的类型方面受过良好的教育。

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

Scala社区可以帮助减轻新手程序员对Scala的恐惧,其中一个方法就是专注于实践,并通过实例进行教学——很多实例都是从小开始,逐渐长大的。以下是一些采用这种方法的网站:

每日Scala学习Scala简单Scala

在这些网站上花了一段时间后,人们很快意识到Scala及其库虽然可能很难设计和实现,但使用起来并不那么困难,特别是在常见情况下。

似乎有必要在这里注明自己的学位:政治学学士和计算机科学学士。

说到点子上:

这会让人们不去斯卡拉吗?

Scala很难,因为它的底层编程范式很难。函数式编程让很多人害怕。在PHP中构建闭包是可能的,但人们很少这样做。因此,如果人们没有特定的教育来让他们重视底层范式的力量,那么不,不是这个签名,而是其他所有签名都会让人们望而却步。

如果这种教育是可行的,每个人都可以做到。去年我在SCALA和一群学生一起制作了一台国际象棋电脑!他们有自己的问题,但最终还是做得很好。

如果你在商业上使用Scala,你会担心吗?您是否计划立即采用2.8版本,还是等待结果?

我不会担心的。