首页 文章

Scala 2.8馆藏图书馆是“历史上最长的遗书”吗? [关闭]

提问于
浏览
821

我刚刚开始关注Scala collections library re-implementation即将发布的Scala collections library re-implementation . 熟悉2.7中的库的人会注意到,从使用角度来看,库几乎没有变化 . 例如...

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

......可以在任何一个版本中使用 . The library is eminently useable :事实上它太棒了 . 然而,那些以前不熟悉Scala并且想要了解语言的人现在必须理解方法签名,例如:

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

对于这样简单的功能,这是一个令人生畏的签名,我发现自己很难理解 . Not that I think Scala was ever likely to be the next Java (或/ C / C / C#) - 我不相信它的创建者会瞄准那个市场 - 但我认为Scala成为下一个Ruby或Python当然是可行的(即获得一个重要的商业广告)用户基础)

  • 这会让人们去Scala吗?

  • 这是否会让Scala在商业世界中成为一个不错的名字,作为学术玩具,只有专门的博士生才能理解?是CTO和软件负责人会害怕吗?

  • 图书馆重新设计了一个明智的想法吗?

  • 如果您在商业上使用Scala,您是否对此感到担忧?您是打算立即采用2.8还是等待看看会发生什么?

Steve Yegge once attacked Scala(在我看来是错误的)因为他看到的是过于复杂的类型系统 . 我担心有人会在这个API上传播FUD(类似于Josh Bloch如何在为Java添加闭包时害怕JCP) .

Note - 我应该清楚,虽然我认为Joshua Bloch在拒绝BGGA关闭提案方面具有影响力,但我并没有将此归因于他诚实地认为该提案代表错误的其他任何事情 .


尽管我的妻子和同事一直在告诉我,但我不是一个白痴:我从University of Oxford获得了很好的数学学位,而且我已经在商业上进行了近12年的编程,并在Scala进行了大约一年的编程(也是商业上的) .

请注意,炎症主题在20世纪80年代早期是quotation made about the manifesto of a UK political party . 这个问题是主观的,但这是一个真实的问题,我喜欢这个问题的一些意见 .

18 回答

  • 210

    这会让人们去Scala吗?

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

    这是否会让scala在商业世界中成为一个不好的名字作为学术玩具,只有专门的博士生才能理解? CTO和软件负责人是否会受到惊吓?

    有些可能将 . 我不认为许多“专业”开发人员可以访问Scala,部分原因是Scala的复杂性,部分原因是许多开发人员不愿意学习 . 雇用这些开发人员的CTO将会被吓跑 .

    图书馆重新设计了一个明智的想法吗?

    绝对 . 它使得集合与其他语言和类型系统相比更加合适,即使它仍然有一些粗糙的边缘 .

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

    我没有在商业上使用它 . 我可能要等到至少两次转入2.8.x系列之后才尝试引入它以便可以刷出错误 . 我还要等一下,看看EPFL在改进发展过程中取得多大成功 . 我所看到的看起来很有希望,但我为一家保守的公司工作 .

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

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

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

  • 5

    Scala有许多疯狂的功能(特别是在涉及隐式参数的地方),看起来非常复杂和学术,但旨在使事情易于使用 . 最有用的是获得语法糖(如 [A <% B] ,这意味着类型A的对象具有对类型B的对象的隐式转换)以及对它们的作用的详细说明 . 但大多数情况下,作为这些库的客户端,您可以忽略隐式参数并信任它们做正确的事情 .

  • 11

    好吧,我可以理解你的痛苦,但是,坦率地说,像你我这样的人 - 或几乎任何常规的Stack Overflow用户 - 都不是常规 .

    我的意思是......大多数程序员都不会关心那种类型的签名,因为他们永远不会看到它们!他们不阅读文档 .

    只要他们看到代码如何工作的一些示例,并且代码不会在生成他们期望的结果时失败,他们就会看到文档并期望在顶部看到用法示例 .

    考虑到这些因素,我认为:

    • 任何遇到过该类型签名的人(如同大多数人一样)如果他们预先处理Scala,就会模仿Scala,如果他们喜欢Scala,他们会认为它是Scala权力的象征 .

    • 如果没有增强文档以提供用法示例并清楚地解释方法的用途以及如何使用它,那么它可能会减少Scala的采用 .

    • 从长远来看,没关系 . Scala可以做的事情会使为Scala编写的库更强大,更安全 . 这些库和框架将吸引程序员使用强大的工具 .

    • 喜欢简单性和直接性的程序员将继续使用PHP或类似语言 .

    唉,Java程序员很多都是电动工具,所以,在回答这个问题时,我刚刚修改了我对主流Scala采用的期望 . 毫无疑问,Scala将成为主流语言 . 不是C主流,但可能是Perl主流或PHP主流 .

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

  • 7

    我希望它不是"suicide note",但我能看出你的观点 . 你同时兼顾了Scala的优势和问题:它的 extensibility . 这使我们可以实现库中的大多数主要功能 . 在其他一些语言,内置类似于 mapcollect 的序列将被内置,并且没有人必须看到编译器必须经历的所有箍以使它们顺利地工作 . 在Scala中,它只是在一个库中,因此是公开的 .

    实际上,由复杂类型支持的 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!)
    

    了解如何始终获得最佳类型?如果您将 Int s映射到 Int ,则会再次获得 BitSet ,但如果将 Int 映射到 String ,则会得到一般 Set . 传递给它的静态类型和map 's result depend on the result type of the function that'的运行时表示 . 即使该集合为空,这也有效,因此该函数永远不会应用!据我所知,没有其他具有同等功能的集合框架 . 然而,从用户的角度来看,事情应该是如何运作的 .

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

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

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

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

  • 41

    不幸的是,你提供的 Map 签名对于 Map 而言是不正确的,并且确实存在合法的批评 .

    第一个批评是通过颠覆 Map 的签名,我们有一些更普遍的东西 . 认为默认情况下这是一种美德是一种常见的错误 . 事实并非如此 . map函数被很好地定义为协变函子Fx - >(x - > y) - > Fy,遵守组合和身份的两个定律 . 任何归因于“ Map ”的东西都是一种讽刺 .

    给定的签名是别的,但它不是 Map . 我怀疑它是试图成为一个专门的,略微改变版本的“遍历”签名来自论文,迭代模式的本质 . 这是它的签名:

    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]
    

    当然它失败了 - 它不够通用!此外,它略有不同(请注意,您可以通过身份仿函数运行遍历来获取映射) . 但是,我怀疑如果库编写者更了解已经详细记录的库概括(Applicative Programming with Effects先于上述内容),那么我们就不会看到这个错误 .

    其次,map函数是Scala中的一个特例,因为它用于for-comprehension . 不幸的是,这意味着一个装备更好的图书馆设计师不能忽视这个错误而不会牺牲理解的语法糖 . 换句话说,如果Scala库设计者要销毁一个方法,那么这很容易被忽略,但请不要映射!

    我希望有人能够说出来,因为事实上,解决Scala坚持做出的错误会变得更加困难,显然是出于我强烈反对的原因 . 也就是说,“普通程序员不负责任的反对意见(即太难!)”的解决方案不是“安抚他们让他们更容易”,而是提供指导和帮助以成为更好的程序员 . 我自己和斯卡拉的目标是在这个问题上争论,但回到你的观点 .

    您可能会提出自己的观点,预测“普通程序员”的具体回答 . 也就是说,那些会声称“但太复杂了!”的人 . 或者其他一些 . 这些是你所指的Yegges或Blochs . 我对反智主义/实用主义运动的这些人的回应非常苛刻,我已经预料到会有一连串的反应,所以我会省略它 .

    我真的希望Scala库可以改进,或者至少可以将错误安全地隐藏在角落里 . Java是一种语言,“试图做任何有用的事情”是如此昂贵,以至于它通常是不值得的,因为绝大多数错误根本无法避免 . 我恳请斯卡拉不要走同样的道路 .

  • 54

    同样的事情在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;
    }
    
  • 69

    似乎有必要在这里陈述一个学位:B.A . 政治学专业,计算机科学专业 .

    要点:

    这会让人们去Scala吗?

    Scala很难,因为它的底层编程范式很难 . 功能编程让很多人感到害怕 . 可以在PHP中构建闭包,但人们很少这样做 . 所以不,不是这个签名,但如果他们没有特定的教育使他们重视潜在范式的力量,那么所有其他人都会放弃他们 .

    如果有这种教育,每个人都可以做到 . 去年我在斯卡拉与一群学校的孩子们一起制作了一台国际象棋电脑!他们有他们的问题,但他们最终做得很好 .

    如果你在商业上使用Scala,你是否担心这个?您是打算立即采用2.8还是等待看看会发生什么?

    我不担心 .

  • 846

    我认为该方法的主要问题是 (implicit bf : CanBuildFrom[Repr, B, That]) 没有任何解释 . 即使我知道隐含的参数是什么,但没有任何迹象表明这会如何影响调用 . 追逐scaladoc只会让我更加困惑(很少有与_158446相关的类甚至有文档) .

    我认为一个简单的“在 bf 范围内必须有一个隐式对象,为 B 类型的对象提供构建器到返回类型 That ”会有所帮助,但是当你真正想做的就是映射时,这是一个令人兴奋的概念 A 's to B 's. In fact, I'我不确定's right, because I don'知道 Repr 的含义是什么, Traversable 的文档肯定没有任何线索 .

    所以,我有两个选择,他们都不愉快:

    • 假设它只是工作旧 Map 的工作方式以及 Map 如何在大多数其他语言中工作

    • 深入了解源代码

    我知道Scala基本上暴露了这些东西如何工作的内容,并且最终这提供了一种方法来执行oxbow_lakes所描述的内容 . 但这是签名中的分心 .

  • 20

    我完全同意这个问题和马丁的回答:) . 即使在Java中,由于额外的噪声,使用泛型读取javadoc也比应该更难 . 这在Scala中是复合的,其中隐含参数被用在问题的示例代码中(而implicits做非常有用的收集变形的东西) .

    我不认为语言本身存在问题 - 我认为这更像是一个工具问题 . 虽然我同意JörgWMittag所说的内容,但我认为看看scaladoc(或IDE中某种类型的文档) - 它应该需要尽可能少的脑力来确定方法是什么,需要什么以及返回什么 . 不需要在一点纸上破解一点代数就可以了:)

    确定IDE需要一种很好的方式来显示任何变量/表达式/类型的所有方法(与Martin的示例一样,可以将所有泛型内联,因此它很好且易于理解) . 我也喜欢Martin默认隐藏隐含的想法 .

    以scaladoc为例...

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

    在scaladoc中查看这个时,我希望默认隐藏通用块[B,That]以及隐含参数(如果你用鼠标悬停一个小图标,它们可能会显示) - 作为它的额外内容读它通常不相关 . 例如想象一下,如果这看起来......

    def map(f: A => B): That
    

    它很好,清晰,明显 . 如果你把鼠标移开,你可能想知道'那'是什么或点击它可以扩展[B,那]突出显示'那'的文本 .

    也许一个小图标可以用于[]声明和(隐式...)块,所以它清楚有一点声明崩溃了吗?很难使用令牌,但我会使用 . 目前...

    def map.(f: A => B).: That
    

    因此,默认情况下,类型系统的'noise'隐藏在人们需要查看的主要80%的位置 - 方法名称,参数类型和返回类型,简洁明了 - 只有很少的可扩展链接到细节如果你真的那么在乎 .

    大多数人都在阅读scaladoc以找出他们可以在类型上调用的方法以及它们可以传递的参数 . 我们有点笨拙的用户如何过多的细节权利如何恕我直言 .

    这是另一个例子......

    def orElse[A1 <: A, B1 >: B](that: PartialFunction[A1, B1]): PartialFunction[A1, B1]
    

    现在如果我们隐藏泛型声明它更容易阅读

    def orElse(that: PartialFunction[A1, B1]): PartialFunction[A1, B1]
    

    然后,如果人们将鼠标悬停在A1上,我们可以显示A1的声明为A1 <:A . 泛型中的协变和逆变类型也会增加很多噪声,这些噪声可以更容易地呈现给我认为的用户 .

  • 46

    我不知道如何打破它,但我有剑桥博士学位,我正在使用2.8就好了 .

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

    所以:我是一个“新用户”而且我没有被推迟 - 事实上,它像Java一样让我有足够的信心忽略了我不理解的部分 .

    (但是,我看Scala的原因部分是为了看看是否要将它推向工作状态,我还没有这样做 . 让文档不那么令人生畏肯定会有所帮助,但让我感到惊讶的是它还有多少改变和发展(最公平的是我最让我感到惊讶的是它有多棒,但变化紧随其后) . 所以我想我所说的是我宁愿选择有限的资源来实现这一目标 . 最终状态 - 我认为他们很快就会期待这种流行 . )

  • 32

    使用网站中的错误消息怎么样?

    那么什么时候需要将现有类型与适合DSL的自定义类型集成在一起 . 必须在关联,优先级,隐式转换,隐式参数,更高种类以及可能存在类型等方面受过良好教育 .

    很高兴知道这主要是简单但不一定足够 . 如果要设计广泛的图书馆,至少必须有一个人知道这些东西 .

  • 15

    Scala社区可以帮助减轻Scala新手程序员的恐惧的一种方法是专注于练习并通过示例进行教学 - 很多例子从小开始逐渐变大 . 以下是一些采用这种方法的网站:

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

  • 10

    我有一个廉价的“大众市场”美国大学的本科学位,所以我说我处于用户智能(或至少是教育)规模的中间:)我已经和Scala讨论了几个月并且已经开发了两三个非平凡的应用程序 .

    特别是现在IntelliJ已经发布了他们的精美IDE,其中恕我直言是目前最好的Scala插件,Scala开发相对无痛:

    • 我发现我可以使用Scala作为“没有分号的Java”,即我在Java中编写类似于代码的代码,并从语法简洁中获益,例如类型推断所获得的 . 异常处理,当我这样做时,更方便 . 没有getter / setter样板,类定义就不那么冗长了 .

    • 偶尔我设法编写一行来完成相当于多行Java的操作 . 在适用的情况下,诸如 Map ,折叠,收集,过滤等功能方法的链条组成和优雅看起来很有趣 .

    • 我很少发现自己受益于Scala更强大的功能:闭包和部分(或curried)功能,模式匹配......这种事情 .

    作为一个新手,我继续挣扎于简洁和惯用的语法 . 没有参数的方法调用不需要括号,除非他们这样做;匹配语句中的个案需要一个粗箭头( => ),但也有一些地方需要一个细箭头( -> ) . 许多方法都有简短但相当神秘的名字,如 /:\: - 如果我翻转足够的手册页,我可以完成我的工作,但我的一些代码最终看起来像Perl或线路噪音 . 具有讽刺意味的是,最流行的句法速记之一在行动中缺失:我一直被它咬伤事实上 Int 没有定义 ++ 方法 .

    这只是我的观点:我觉得Scala具有C的强大功能以及C的复杂性和可读性 . 语言的语法复杂性也使得API文档难以阅读 .

    斯卡拉在许多方面都经过深思熟虑和辉煌 . 我怀疑很多学者都喜欢在其中编程 . 然而,它也充满了聪明和陷阱,它具有比Java更高的学习曲线并且更难以阅读 . 如果我扫描论坛,看看有多少开发人员仍在努力克服Java的细节, I cannot conceive of Scala ever becoming a mainstream language . 没有公司能够证明派遣开发人员参加为期3周的Scala课程,而之前他们只需要1周的Java课程 .

  • 22

    这会让人们去Scala吗?

    我不认为这是影响Scala流行程度的主要因素,因为Scala具有很强大的功能,而且它的语法对于Java / C / PHP程序员来说并不像Haskell,OCaml,SML,Lisps那样陌生 . 等等..

    但我确实认为Scala的受欢迎程度将低于今天的Java,因为我认为下一个主流语言必须大大简化,我认为实现这一目标的唯一方法是纯粹的不变性,即像HTML一样的声明,但图灵完成 . 但是,我有偏见是因为我正在开发这样一种语言,但我只是在排除了几个月的研究后才这样做,Scala不能满足我的需要 .

    这是否会让Scala在商业世界中成为一个不好的名字,作为一个只有专门的博士生可以理解的学术玩具? CTO和软件负责人是否会受到惊吓?

    我不认为Scala的声誉会受到Haskell复杂性的影响 . 但我认为有些人会推迟学习它,因为对于大多数程序员来说,我还没有看到强制他们使用Scala的用例,他们会拖延学习它 . 也许高度可扩展的服务器端是最引人注目的用例 .

    而且,对于主流市场,首先学习Scala并不是一种“呼吸新鲜空气”,其中一种是立即编写程序,例如首先使用HTML或Python . 在得知所有从一开始就绊倒的细节之后,Scala往往会在你身上成长 . 但是,如果我从一开始就阅读Scala编程,那么我对学习曲线的经验和看法会有所不同 .

    图书馆重新设计了一个明智的想法吗?

    当然 .

    如果你在商业上使用Scala,你是否担心这个?您是打算立即采用2.8还是等待看看会发生什么?

    我使用Scala作为我新语言的初始平台 . 如果我在商业上使用Scala,我可能不会在Scala的集合库上构建代码 . 我会创建自己的基于类别理论的库,因为我看过一次,我发现Scalaz的类型签名比Scala的集合库更加冗长和笨拙 . 这个问题的一部分可能是Scala实现类型类的方式,这是我创建自己的语言的一个小原因 .


    我决定写这个答案,因为我想强迫自己去研究和比较Scala的集合类设计和我为我的语言所做的那个 . 不妨分享我的思考过程 .

    2.8 Scala集合使用构建器抽象是一种合理的设计原则 . 我想探讨下面的两个设计权衡 .

    • WRITE-ONLY CODE:在写完这一节之后,我读了Carl Smotricz's comment,这与我期望的权衡是一致的 . 詹姆斯·斯特拉坎和davetron5000 _158469的评论是关于写Scala的,但是如何阅读其他不是"in the common cases"的Scala .

    我读过有关Scala的一个批评是,编写它比阅读其他人编写的代码更容易 . 而且我发现这种情况偶尔会出于各种原因(例如编写函数的方法,自动闭包,DSL单元等),但如果这是主要因素,我还是未定 . 这里使用隐式函数参数有优点和缺点 . 从好的方面来说,它可以减少冗长并自动选择构建器对象 . 在Odersky的example中,从BitSet(即Set [Int])到Set [String]的转换是隐含的 . 不熟悉的代码读者可能不会轻易知道集合的类型是什么,除非他们可以很好地推断出当前包范围中可能存在的所有潜在的隐形隐式构建器候选者 . 当然,有经验的程序员和代码编写者会知道BitSet仅限于Int,因此String的映射必须转换为不同的集合类型 . 但是哪种收藏类型?它没有明确指定 .

    • AD-HOC收藏设计:在写完这一部分之后,我读到了Tony Morris's comment,并意识到我正在做出几乎相同的观点 . 也许我更详细的阐述会更清楚地表明这一点 .

    在“与类型作斗争”Odersky&Moors中,提出了两个用例 . 他们是限制BitSet为Int元素,Map为对元组元素,并且作为一般元素映射函数A => B必须能够构建备用目标集合类型的原因提供 . 然而,从类别理论的角度来看,这是有缺陷的 . 为了在类别理论中保持一致并因此避免极端情况,这些集合类型是仿函数,其中每个态射A => B必须映射在同一仿函数类别中的对象,List [A] => List [B],BitSet [A] => BitSet [B] . 例如,Option是一个仿函数,可以被视为一个Some(对象)和None的集合的集合 . 从Option的None或List的Nil到没有“空”状态的其他仿函数,没有一般的 Map .

    这里有一个权衡设计选择 . 在我的新语言的集合库的设计中,我选择将所有内容都设置为仿函数,这意味着如果我实现了一个BitSet,它需要支持所有元素类型,通过使用非位字段内部表示来呈现非整数类型参数,该功能已在Scala中继承的Set中 . 我的设计中的Map只需映射其值,它可以提供一个单独的非functor方法来映射其(键,值)对元组 . 一个优点是每个仿函数通常也是一个应用程序,也许也是一个monad . 因此,元素类型之间的所有函数,例A => B => C => D => ...,被自动提升到提升的应用类型之间的功能,例如,列表[A] =>列表[B] =>列表[C] =>列表[D] => ....对于从仿函数到另一个集合类的映射,我提供了一个映射重载,它采用了一个monoid,例如Nil,None,0,“”,Array()等 . 因此构建器抽象函数是monoid的append方法,并且作为必要的输入参数显式提供,因此没有不可见的隐式转换 . (切线:此输入参数还可以附加到非空的幺半群,Scala的 Map 设计无法做到 . )此类转换是同一迭代过程中的 Map 和折叠 . 此外,我在类别意义上提供了一个可遍历的“具有效果的应用程序设计”McBride和Patterson,它还可以在任何遍历到任何应用程序的单个迭代过程中实现 Map 折叠,其中大多数集合类都是 . 状态monad也是一个应用程序,因此是任何可遍历的完全通用的构建器抽象 .

    因此,Scala集合是“ad-hoc”的,因为它不是基于范畴理论,而类别理论是更高层次指称语义的本质 . 尽管Scala的隐式构造器最初看起来“更加普遍”,而不是仿冒器模型的monoid构建器遍历 - > applicative,但它们并未被证明与任何类别一致,因此我们不知道它们遵循的最一般规则是什么感觉以及将给出的角落案例他们可能不遵守任何类别模型 . 添加更多变量使得更一般的东西变得更加普遍,这是不正确的,这是类别理论的巨大好处之一,它提供了一些规则,通过这些规则来保持通用性,同时提升到更高级别的语义 . 集合是一个类别 .

    我读到某个地方,我认为是Odersky,作为库设计的另一个理由,是纯函数式编程具有有限递归和速度的成本,其中不使用尾递归 . 到目前为止我遇到的每种情况都没有发现很难使用尾递归 .


    另外,我在脑海里抱着一个不完整的想法,一些Scala 's tradeoffs are due to trying to be both an mutable and immutable language, unlike for example Haskell or the language I am developing. This concurs with Tony Morris'对于理解的评论 . 在我的语言中,没有循环,也没有可变构造 . 我的语言将位于Scala之上(目前为止),并且很大程度上归功于它,而且它不具备通用类型系统和可变性 . 这可能不是真的,因为我认为Odersky&Moors("Fighting Bit Rot with Types")不正确地指出Scala是唯一具有更高种类的OOP语言,因为我验证了(我自己和通过Bob Harper)标准ML有它们 . 同样出现了对Scala的批评,而是试图对权衡进行不完整的分析,这是我希望与这个问题密切相关的 . Scala和SML无法做diamond multiple inheritance,这很关键,我理解为什么Haskell Prelude中的这么多函数会针对不同类型重复 .

  • -1

    我没有博士学位,也没有其他任何学位,既不是CS,也不是数学,也不是其他任何领域 . 我之前没有使用Scala或任何其他类似语言的经验 . 我甚至没有远程可比类型系统的经验 . 事实上,我所拥有的唯一语言不仅仅是表面知识,甚至还有一个类型系统,它是Pascal,并不完全以其复杂的类型系统而闻名 . (虽然它确实有范围类型,但AFAIK几乎没有其他语言,但这在这里并不相关 . )我知道的其他三种语言是BASIC,Smalltalk和Ruby,它们都没有类型系统 .

    然而,我毫不费力地理解你发布的 map 功能的签名 . 它看起来像我所见过的其他语言中的 map 几乎相同的签名 . 不同之处在于此版本更通用 . 比起Haskell,它看起来更像是一个C STL . 特别是,它通过仅要求参数为 IterableLike 来抽象远离具体集合类型,并且还通过仅要求存在可以从该结果值集合构建某些内容的隐式转换函数来抽象远离具体返回类型 . 是的,这是非常复杂的,但它实际上只是泛型编程的一般范式的表达:不要假设任何你实际上不需要的东西 .

    在这种情况下, map 实际上并不需要将集合作为列表,或者正在排序或可排序或类似的东西 . map 唯一关心的是它可以一个接一个地访问集合的所有元素,但没有特别的顺序 . 并且它不需要知道生成的集合是什么,它只需要知道如何构建它 . 所以,这就是它的类型签名所需要的 .

    所以,而不是

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

    这是 map 的传统类型签名,它被推广为不需要具体的 List 而只是一个 IterableLike 数据结构

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

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

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

    我承认语法有点笨拙,但语义是一样的 . 基本上,它始于

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

    这是 map 的传统签名 . (注意由于Scala的面向对象特性,输入列表参数消失了,因为它现在是单调度OO系统中每个方法都具有的隐式接收器参数 . )然后它从具体的 List 推广到更多一般 IterableLike

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

    现在,它将一个函数替换为 IterableLike 结果集合,该函数可以生成任何东西 .

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

    我真的相信并不难理解 . 实际上只需要几个智力工具:

    • 你需要(大致)知道 map 是什么 . 如果你只提供没有方法名称的类型签名,我承认,要弄清楚发生了什么将会困难得多 . 但既然你已经知道 map 应该做什么,并且你知道它的类型签名应该是什么,你可以快速扫描签名并专注于异常,例如“为什么这个 map 将两个函数作为参数,而不是一个?”

    • 您需要能够实际读取类型签名 . 但即使你以前从未见过Scala,这应该很简单,因为它实际上只是你从其他语言中已经知道的类型语法的混合:VB.NET使用方括号进行参数多态,并使用箭头表示返回类型和冒号分隔名称和类型,实际上是常态 .

    • 您需要大致了解通用编程的含义 . (这并不难理解,因为它实际上只是以通用方式编程) .

    这三者都不应该给任何专业甚至是业余爱好者的程序员带来严重的麻烦 . map 已成为过去50年来设计的几乎所有语言的标准功能,不同语言具有不同语法的事实对任何使用HTML和CSS设计网站并且您无法订阅甚至远程的人来说都应该是显而易见的 . 编程相关的邮件列表没有来自圣斯捷潘诺夫教堂的一些恼人的C fanboy解释泛型编程的优点 .

    是的,Scala很复杂 . 是的,Scala拥有人类已知的最复杂的类型系统之一,可以与Haskell,Miranda,Clean或Cyclone等语言相媲美甚至超越 . 但是,如果复杂性是反对编程语言成功的论据,那么很久以前C就已经死了,我们都会写出Scheme . Scala很可能不会成功的原因有很多,但是程序员在坐在键盘前不能打开他们的大脑这一事实可能并不是主要原因 .

  • 166

    我是Scala初学者,老实说,我没有看到该类型签名的问题 . 该参数是要映射的函数,以及构建器返回正确集合的隐式参数 . 清晰可读 .

    实际上,整件事情非常优雅 . 构建器类型参数允许编译器选择正确的返回类型,而隐式参数机制从类用户中隐藏此额外参数 . 我试过这个:

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

    这种多态性是正确的 .

    现在,被授予,它不是主流范式,它会吓跑很多人 . 但是,它也会吸引人许多人重视其表现力和优雅 .

  • 4

    我也有牛津大学的数学学位!我花了一段时间来“获取”新的收藏品 . 但是我现在非常喜欢它 . 事实上,'map'的输入是我在2.7中遇到麻烦的第一件大事(也许是因为我做的第一件事就是将其中一个集合类子类化) .

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

    我主要担心的是:什么时候2.8会被释放? bug报告何时会停止进入呢?让scala团队咬掉比他们可以咀嚼2.8更多/试图一次改变太多?

    在添加任何其他新东西之前,我真的希望将2.8稳定发布作为优先事项,并且想知道(从旁观看时)是否可以对scala编译器的开发路线图的管理方式进行一些改进 .

  • 6

    根本不知道斯卡拉,但几周前我读不懂Clojure . 现在我可以阅读其中的大部分内容,但除了最简单的例子之外,不能写任何东西 . 我怀疑斯卡拉没有什么不同 . 根据你的学习方式,你需要一本好的书或课程 . 只要阅读上面的 map 声明,我就得到了1/3 .

    我认为更大的问题不是这些语言的语法,而是采用并内化使它们可用于日常 生产环境 代码的范例 . 对我来说,Java并不是C的巨大飞跃,这不是C的巨大飞跃,这不是Pascal,也不是Basic等的飞跃......但是用像Clojure这样的函数式语言进行编码 is 一个巨大的飞跃(对于我无论如何) . 我想在Scala中你可以用Java风格或Scala风格编写代码 . 但是在Clojure中,你会创造很多混乱,试图保持你的命令式习惯来自Java .

相关问题