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

其他回答

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

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

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

我真的很希望在添加任何其他新功能之前,将2.8稳定发布作为一个优先事项,并想知道(在观望的同时)是否可以对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,但几周前我还不会读Clojure。现在我能读到大部分,但除了最简单的例子之外,我还写不出任何东西。我想Scala也没什么不同。你需要一本好书或一门课程,这取决于你的学习方式。只是看了上面的地图声明,我大概得到了其中的1/3。

我认为,更大的问题不在于这些语言的语法,而在于采用和内化使它们在日常生产代码中可用的范例。对我来说,Java并不是C++的巨大飞跃,也不是C的巨大飞跃。Pascal和Basic等根本不是Java的飞跃。但用Clojure这样的函数式语言编写代码是一个巨大的飞跃(对我来说)。我想在Scala中,你可以用Java风格或Scala风格编写代码。但在Clojure中,您将创建一个相当混乱的环境,试图让您的命令习惯远离Java。

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

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

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

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

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

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

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

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

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

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

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

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

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

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