我刚刚开始研究即将发布的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,我想就此事发表一些意见。


当前回答

不幸的是,您提供的地图签名对地图来说是不正确的,而且确实存在合理的批评。

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

给定的签名是其他东西,但它不是地图。我怀疑它试图成为一个专门的、略有改动的“遍历”签名版本,该签名来自论文《迭代器模式的本质》。以下是其签名:

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

我将把它转换成Scala:

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

当然,它失败了——它还不够普遍!此外,它略有不同(请注意,您可以通过运行遍历Identity函子来获得map)。然而,我怀疑,如果库编写者更了解有充分记录的库概括(前面提到的是使用效果的应用编程),那么我们就不会看到这个错误。

第二,map函数在Scala中是一种特殊的情况,因为它用于理解。不幸的是,这意味着一个装备更好的库设计者不能忽视这个错误,而不牺牲理解的语法糖。换句话说,如果Scala库设计者要破坏一个方法,那么这很容易被忽略,但请不要映射!

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

你可能是在表明自己的观点,预测“普通程序员”的具体反应。也就是说,那些声称“但这太复杂了!”或诸如此类的人。这些是你所指的耶格人或布洛赫人。我对这些反智主义/实用主义运动的人的反应相当严厉,我已经预料到会有一连串的反应,所以我将省略它。

我真的希望Scala库能够改进,或者至少可以将错误安全地隐藏在角落里。Java是一种“尝试做任何有用的事情”的代价非常高昂的语言,因此通常不值得这样做,因为大量的错误根本无法避免。我恳求斯卡拉不要重蹈覆辙。

其他回答

我认为该方法的主要问题是(隐式bf:CanBuildFrom[Rrep,B,that])没有任何解释。尽管我知道什么是隐式参数,但没有任何信息表明这会如何影响调用。浏览scaladoc只会让我更加困惑(很少有与CanBuildFrom相关的类甚至有文档)。

我认为一个简单的“bf的作用域中必须有一个隐式对象,它为B类型的对象提供了一个构建器”会有所帮助,但当您真正想做的是将a映射到B时,这是一个令人兴奋的概念。事实上,我不确定这是对的,因为我不知道Repr类型是什么意思,而Traversable的文档也毫无头绪。

所以,我有两个选择,都不令人满意:

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

我认为Scala本质上是在揭示这些东西是如何工作的,最终这是提供了一种实现oxbow_lakes所描述的方法。但签名会分散注意力。

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

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

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

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

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

Scala有很多疯狂的特性(特别是在隐式参数方面),看起来非常复杂和学术,但设计的目的是使其易于使用。最有用的是语法糖(如[A<%B],这意味着A类型的对象隐式转换为B类型的对象)和对它们所做操作的详细说明。但大多数时候,作为这些库的客户,您可以忽略隐式参数,并相信它们会做正确的事。

我也有牛津大学的数学学位!我花了一段时间才“拿到”新藏品。但我现在非常喜欢它。事实上,“map”的键入是2.7中最早让我感到困扰的事情之一(也许是因为我做的第一件事是集合类的子类之一)。

阅读Martin关于新的2.8集合的论文确实有助于解释隐式的用法,但是的,文档本身肯定需要更好地解释不同类型的隐式在核心API的方法签名中的作用。

我最担心的是:2.8将于何时发布?bug报告什么时候停止出现?scala团队是不是用2.8咬得太多了/试图一下子改变太多了?

我真的很希望在添加任何其他新功能之前,将2.8稳定发布作为一个优先事项,并想知道(在观望的同时)是否可以对scala编译器的开发路线图进行一些改进。