大卫·波拉克（David Pollak）和迪克·沃尔（Dick Wall）讨论了采用Scala的障碍

著名的Scala倡导者David Pollak写了一篇博客文章， “是的，弗吉尼亚州，Scala很难” ，这在Scala社区引起了一些麻烦。 该帖子声称Scala试图做太多事情，IDE支持差，具有令人生畏的类型系统等等。 最终，大卫的断言质疑Scala的广泛吸引力以及Scala是否将成为下一个Java 。 Scala社区似乎对他们对Scala的攻击感到沮丧。 David断言，他将通过公开解决Scala的问题以及Scala适应市场的水平设置来尽最大努力保持Scala的成功。 InfoQ与David Pollak和Scala的另一位拥护者Dick Wall会面，讨论了Scala的采用，成功和未来，并讨论了此博文以及锡兰等相关主题。

自从2009年以来 ，Scala便通过多个著名的Scala项目（包括Twitter ， Foursquare和guardian.co.uk）开始真正地发力， David的职位实际上与某些人有些矛盾。 在报道了Twitter对Scala的高使用率之后，几乎可以跟踪采用率的增长。 Twitter继续转移其更多代码库以使用Scala 。

David的Scala凭据使他对Scala的看法很重要。 除了创建Lift之外 ，David还主持了2008年首届Scala会议之一，即Scala LiftOff ，直到今天他仍继续主持该会议（伦敦Scala LiftOff于今年10月13日至14日举行）。 他还是关于Scala的两本书的作者：Scala简介和Beginning Scala ，并且已经教了数百名Java开发人员Scala。 David是Scala的顶级开发人员之一，他从事过许多对Scala的采用产生巨大推动作用的项目。

David的目标是使Scala成为Python之类的顶级语言。 他的帖子是关于他对实现这一目标的步伐感到沮丧的。 “今年春天，我放弃了那种幻想。我意识到Scala永远不会像Python那样流行。” 他希望Scala具有Smalltalk或Lisp作为第二层语言的持久能力。 他担心的是Scala不会达到这个目标，因为Scala被炒作Java的替代品 。 大卫继续向InfoQ解释他的立场

虽然我同意Scala-the-language具有一些巨大的技术优点，并且我同意Scala生态系统中有一些出色的创新库，但是Scala（语言，工具链，生态系统，与Scala无关）还不成熟足以成为Java的替代品，并且不增加对Scala商业化的一两个数量级的投资，我看不到Scala成为Java的替代品。

因此，如果我们对Scala采用“跨越鸿沟”方法，则Scala尚未跨越鸿沟。 现在是Scala生命周期中一个特别棘手的阶段。 如果Scala承诺过多而交付不足，则存在Scala声誉受损的风险。 如果太多的Scala项目失败了，Scala将会失去光泽。 我的目标是放慢处理鸿沟的方法，并帮助找到一个或两个Scala可以统治的滩头堡，以便当需要克服鸿沟时，会有很多成功点。

我致力于Scala的成功，但我认为成功将受到限制，尽管Scala完全有可能会完全失败（例如Forth或Groovy ...是的，Groovy还没有死）。

然后，他列举了伦敦摩根士丹利（Morgan Stanley）等公司大量采用Scala的例子。 这种采用方式对于Scala的采用可能是一笔巨大的财富，也可能是人们在决定使用Scala时指出的遗憾的试金石。 他担心摩根士丹利可能很难为他们的项目找到合适的Scala开发人员，而且Scala的技能很少。 例如，如果未受指导的招聘人员招聘新生的Scala开发人员，则Scala项目的成功可能会变得困难。 大卫感叹，

“如果他们结识了一些强大的Scala开发人员，他们可以在传播良好的Scala设计规范以及良好的学习，共享和成长的制度流程方面做正确的事情，那么他们很有可能获得成功。另一方面，如果摩根士丹利（Morgan Stanley）在Scala上失败，那么金融界将面临很大的障碍，以启动另一个大型Scala项目。”

David担心，由于财务是Scala的最佳选择，因此在一家知名金融机构中一些关键项目的失败可能标志着Scala整体采用的终结。

Java Posse播客声望的Dick Wall一直是Scala的倡导者。 迪克三年前发现了Scala，并已将它用作他的主要语言已有两年了。 迪克说，他对强类型Scala的简洁性和表现力感到欣喜，其水平通常与动态类型化语言（如Python，Groovy和Ruby）相关。 这似乎是JVM的一类全新的强类型语言的梦feature以求的功能。 Dick在Scala世界中一直很忙。 他写了SubCut ，一个开源的Scala依赖注入解决方案。 他还是ScalaTest的贡献者。 迪克还与著名的Scala专家Bill Venners一起成立了一家专注于Scala培训和咨询的咨询公司 ，这似乎广受欢迎 。 迪克对Scala的看法与大卫不同。

InfoQ： 您读过大卫·波拉克（David Pollak）的《是的弗吉尼亚》吗？

迪克·沃尔

是的，但是我会选择将标题扩展为“软件开发困难”或“强大的软件开发困难”。 当您着手完成一个项目或编写一个系统时，就需要解决一个问题。 很有可能，如果这是一件好事和新事物，那就很难了。 所交付项目的复杂性将在某种程度上取决于要解决的问题，无论您如何解决，该复杂性条的高度都将大致相同。

选择一种功能更强大的语言是您获得更高标准的第一种方法。 接下来是选择库，其余的则由您自己填写。 在Java中，功能（按现代标准）相当低，留下了更大的差距。 大多数人都填写了库，例如JPA，Wicket，Spring或成熟的Java EE。 这些给项目带来了自己的重大复杂性（更不用说他们自己的学习曲线了）。 然后，工作从最后一部分开始，这是到达标尺所必需的自定义工作。

如果您正在编写类似Web应用程序的内容，则可能会获得可用的库（其中有很多Java语言），尽管您在初次学习库时会投入大量资金，但几乎可以带您到达那里。 。 如果任务不那么普遍，例如科学或数学项目，或者只是一些全新的想法或方法，那么您还有更多工作要做。 在这一点上，您希望获得最大的功能，灵活性和表现力，而这又取决于您选择的语言。

至于Scala很难，那就是我不同意David的观点。 它可能很难，也可能和您必须解决的问题一样困难，这在我看来是有好处的。 另一方面，在最近的BASE（湾区Scala热心者）上，我们看到了Kojo的演示-Kocal的完整环境-嵌入到孩子的学习环境中，看起来像Logo，这是几年前的学习环境），上个月是由11岁的人演示，他自己写了自己的Conway的《人生游戏》。 现在有问题的孩子很聪明，没有争议，但是它仍然表明语言的可访问性。 归结为这样一个想法，即复杂性是您要解决的问题的功能，而不仅仅是解决问题的语言。

InfoQ： Java开发人员学习Scala必须克服的最大概念障碍是什么？

大卫·波拉克（David Pollak）

不变性。 在Java中，编码人员会通过更改某种状态和查询某种状态来解决大多数问题。 豆，吸气剂，二传手。 从概念上讲，这类似于汇编语言，我们在各处都推字节。 Scala包含但不强制执行转换方法（您不更改事物，但是给定事物，您将返回具有所需更改的事物的新实例）。 一个函数将输入转换为具有很少或没有副作用的输出（无论调用该函数的方式和时间，如果输入相同，则结果将相同）。

开发人员经常面临围绕不变性的许多挑战。

Scala的问题之一是它不会像Erlang和Haskell和Clojure那样强制执行不变性。 因此，退回Java约定非常容易...做“ Java方式”很容易。 不幸的是，当您在Scala中以Java方式进行操作时，您失去了很多Scala的优势，并且还陷入了Scala的劣势（例如，文档和较差的IDE支持）。

因此，使用Scala，除非您有很多纪律（内部自律或周围有一支强大的团队），否则很容易就没有意识到语言的好处。 此外，由于Scala领域中有很多范例，所以很难弄清楚您是否“以正确的方式”做事。

简而言之，Java开发人员必须克服的最大障碍是，学习Scala不会退缩到他们的Java可变方式上。 但是还有许多其他障碍（类型系统，文档，缺乏明确定义的模式等）。

迪克·沃尔

Java有很多要学习的地方。 Java开发人员没有意识到这一点，但是Java拥有了绝大部分的知识和知识。 从头开始设计语言的人可能没有静态方法和字段，例如，当类元对象在概念上更有意义时。 匿名内部类带来的功能和问题与函数文字和闭包基本相同，但语法较不方便，使初学者感到困惑。

当然，学习Scala所提供的功能还存在额外的障碍，但是您不必立即做到这一点-随手添加一些这样的想法，然后看看您的想法如何。 首先，您可以像编写Java一样简单地编写Scala，然后主要的障碍是学习可以忽略的内容，而不是必须输入的内容。

InfoQ： 您对Scala IDE支持最大的抱怨是什么？

大卫·波拉克（David Pollak）

慢。 破碎。 记忆猪。 自动完成不良。 弱代码导航支持。 重构支持薄弱。 无法打开大文件或大项目。 仅举几个。

迪克·沃尔

首先，Scala IDE支持在过去的一年中有了很大的提高。 目前，我使用IntelliJ IDEA，因为我认为它现在得到了最好的支持，但是NetBeans和Eclipse都获得了很好的支持，并且由于EPFL团队对该项目的参与，Eclipse的发展Swift。

查看Scala的IDEA工具的最新状态，我们已经支持所有主要功能（包括隐式）的代码完成。 语法着色非常出色，并且在像Scala这样的表达性语言方面给Java带来了额外的收获。 有重构支持，一些实时错误突出显示（尽管还没有完成）和调试支持。

最后两个是目前最薄弱的部分。 错误突出显示在某些情况下有效，但在其他情况下，您仅在尝试编译时才会得到错误。 调试也有一些小问题，主要的问题是，将断点放在闭包或函数文字内部时有时会被跳过。 这两个都是烦人的事情，可以轻松解决。

最后，每个人总是抱怨它，但是编译速度可能是最大的麻烦。 大多数情况下，都有许多巧妙的方法来解决它，例如fsc（一种像服务器一样工作并保持运行状态的快速Scala编译器）或sbt （Scala的构建工具），但最终scala编译器需要大量工作做。 EPFL似乎意识到这是一个大问题，并且一直在努力。

InfoQ： 很难找到要在Scala中编程的开发人员吗？ 为什么？

大卫·波拉克（David Pollak）

不。找到优秀的Scala开发人员很容易。 但是，很难找到大量的Scala开发人员。 下周，我可以组成一个由10个Scala和/或Lift开发人员组成的强大团队，进行项目。 它们不会便宜（平均成本为每小时$ 250加上我加的任何标记。）它们不会是本地的。 但是他们会很棒。

Foursquare和Twitter等人正在招聘各领域的优秀开发人员，并通常使他们成为Scala的优秀开发人员。

困难的是要找到一个由25名Scala开发人员组成的外包团队，每小时收费40美元。 在该价格下，您可以找到很多PHP，Ruby和Java开发人员，但在此价格下，很少有Scala开发人员。

这是一个供需问题。 供应量少是因为需求量小。 随着更多Scala开发人员的出现，这是一个积极的良性循环。 但是可用的Scala开发人员数量是数百，而不是数万。 除非Scala成为主流（例如Python和Ruby，PHP和Java和C＃），否则车身修理厂没有经济诱因来留住Scala人才或出售Scala项目。

迪克·沃尔

我们发现在Scala中很难找到开发人员。 新语言会产生有趣的效果，充满活力和敬业精神的工程师往往会寻找它们并进行学习，然后在其中寻找工作。 他们倾向于自我开创，这是大多数公司至少声称要从开发人员那里获得的东西。 如果您想找人在Scala工作，那么比检查您当地的Scala用户组做得更糟。

InfoQ： 与其他Web框架 相比， Lift 具有 哪些优势 ？

大卫·波拉克（David Pollak）

更安全。 快点。 更适合编写高度互动的网站（很多Ajax和Comet）。 强类型（较少的运行时错误）。 简洁。 这里是一些文章和一些视频，讨论了如何使用Lift以及它如何改变了开发人员对Web开发的观点。 （ 视频 ）

迪克·沃尔

Lift在Web框架上是一个有趣的转折，因为它将页面显示为XML数据的节点序列，您通过功能将这些页面传递给您想要的结果-这是一种查看世界的非常实用的方法。 使用Scala actor的Comet支持也非常聪明。

我喜欢的其他库有： 播放 -一种Web开发方法，对于许多开发人员来说将更加熟悉； Squeryl用于对象关系映射； Salal用于任何相关测试； Akka是企业框架解决方案的核心； Borachio用于测试模拟 ；以及SubCut（当然）用于依赖项注入和服务位置。 所有这些都通过利用Scala功能（特别是对于构造DSL（特定于域的语言）），在Java等效项上提供了出色的表达能力。

InfoQ： David，您在文章中提到，您觉得Scala实际上是针对具有95％技能水平的团队的。 前5％的开发人员。 公司要吸引这样的开发商有多难？ 值得吗？

大卫·波拉克（David Pollak）

我当时好漂亮。 在我的后续帖子中，我尝试更加精确。 我认为Scala对于从人才库顶部招聘的公司来说可能会非常成功。 我将其量化为Java商店的上半部分。 这不是游泳池的5％。 这是游泳池的50％。

取决于您的公司，您的薪水，您的激励措施，您的管理，吸引高层人才可能很容易，也可能很困难。 Google每天都会吸引顶尖人才，而SalesForce.com，Twitter和Facebook等也是如此。另一方面，按照定义，大多数公司都无法吸引最优秀的人才。 游泳池是有限的。

（这值得吗？）这取决于。 Spring ORM有很多填空的应用程序，它们并不具有挑战性或令人兴奋。 如果您的公司和市场定位明确，发展缓慢，那么招募那些在稳定的工作环境中挣扎，及时回家与家人相处以及在低压力的环境中工作的人非常有用。 为食品杂货连锁店或医疗保健公司编写后端系统的目的在于项目的寿命，可维护性和低风险。 在这些环境中，使用久经考验的真实语言和工具会带来可预期的结果，这是一件好事。

我认为Scala在技术上优于Java，但不足以克服使用已知解决方案的可预测性。 Scala作为一种语言“不够好”，无法克服在缓慢发展的项目中使用Java的机构价值。 是的，我可以想象一个场景，在15年内，Scala取代了Java，但是该场景是一个低可能性的场景，而今天出售该场景将无助于Scala的采用。

但是我认为Oracle更有可能醒来并将C＃克隆到Java中，或者技术上较不进取的Java替换语言之一将成为主流，而Scala有望在技术上出色并突破理论和实践的界限...。乔布斯（Steve Jobs）花费了18年的时间和意志力，以及平台范式的改变，使NeXTSTEP成为主流。 Scala会一直持续到其技术优势成为主流并将该技术优势称为Scala吗？ 这是一个长期的赌注。

InfoQ： Scala是否值得普通的开发人员团队学习？ 收益是否超过了复杂性和学习曲线？

大卫·波拉克（David Pollak）

这取决于项目。 如果所有并发都在数据库中完成，则否。

如果您要进行某种形式的事件处理（交易大厅，体育博彩，近实时数据分析，社交网络），Scala将是Java的巨大胜利。 如果您拥有复杂的分布式系统，Scala和不变性将是一个巨大的胜利。 在这些情况下，与Scala的优点（不变性，可组合性，良好的事件处理，出色的库/框架）相比，使用Scala的成本（学习曲线，不良的工具等）的成本较低。系统。）

这个问题的答案取决于团队的倾向和项目类型。 回到我的最高目标（Scala取得更大成功）的关键是，在受益于Scala优势的地方使用Scala。

迪克·沃尔

问题在于，复杂性是（或不是）复杂性，而语言是沿着这条路径发展的工具。 如果您有一个非常复杂的问题要解决，那么Scala值得竭尽全力使用它，其他任何可以解决该问题的工具也一样。

另外，Scala代表了我希望能以任何新语言看到的功能集。 无论Scala最终的“成功”是什么，无论对谁说，这意味着什么，学习功能集都能使您很好地学习和使用其他语言，那么有什么要失去的呢？

InfoQ： 一个人能 跻身 前5％的行列，仍然不喜欢Scala吗？

大卫·波拉克（David Pollak）

当然。 有大量的Smalltalk，Lisp，Clojure和Ruby开发人员不会喜欢Scala的静态类型。 查尔斯·纳特（Charles Nutter）并不是Scala的粉丝，但他是一位真正令人惊叹的开发商。

迪克·沃尔

当然。 这样，语言就类似于葡萄酒，人们的口味也各不相同。 没有完美的葡萄酒，但是有您喜欢和不喜欢的葡萄酒，其他人的口味可能会有所不同。 我怀疑如果您调查许多使用Java的人，它可能不是他们最喜欢的语言，或者在某些情况下可能不是他们特别喜欢的语言，但是它确实有效并且是事实上的标准。

它与前5％的收入也没有关系。 就像葡萄酒一样，也许葡萄酒评论家可以为您提供一些指导，尤其是当您确定自己具有相似的口味并且喜欢他们过去的一些建议时，但最终，这才是你想要的。 只需尝试一下，您就会很快知道是否喜欢它，并且您在乎其他人的想法吗？

InfoQ： 从理论上讲，如果不实践，诸如 Ceylon 和 Kotlin之 类的语言将 试图解决Scala针对Java所遇到的一些相同问题，而又不会使Scala变得复杂，也可能会引起争议。 您是否认为锡兰和/或Kotlin可以为并非都处于95％水平的团队提供价值？ 在仍然提供价值的同时，他们缺少什么来瞄准主流？

大卫·波拉克（David Pollak）

我要结束这里的每个人

出于一个简单的原因，Kotlin很有可能成为现有JVM语言中的下一个Java。 它是从IDE开始构建的，并且绝大多数目标受众（Java开发人员）是IDE用户。 尽管我对IntelliJ的UI并不热衷，但JetBrains的人具有惊人的能力，可以触及Java IDE用户大脑中的所有正确位置。 最终，我敢打赌，JetBrains的人将能够提供比Java更强大的Java，并拥有强大的IDE支持。

这并不是说Kotlin在技术上或理论上都是优秀的，或者不会吸引Scala吸引的各种各样的库开发人员（Scalaz提升到Akka到规格）。 Scala拥有范围最广的疯狂智能人士，他们以我所见过的任何语言或平台社区（包括NeXTSTEP社区）的新颖方式解决问题。

回到问题所在，如果Kotlin有大量Spring扩展，并且具有可靠的文档和出色的IDE支持，我认为它很有可能获得“下一个Java”奖。

哦...关于锡兰，我无话可说。

迪克·沃尔

我对这些语言持观望态度。 我会不断学习，并希望在可能的情况下尝试这些语言。 同时，仅当我尝试使用Scala时，了解更多有关Scala的信息对我有帮助-因为许多功能都是相似的。

我认为5％和95％的划分是任意的，我强烈不同意。 该语言对您和您的团队都适用，或者不适用。 如果让您觉得更好，那就想想：“我喜欢Scala，所以我必须处于开发人员的前5％”，但是请不要相信自己的媒体。 人们面临一个更大的问题，那就是人们认为其他人不够聪明，无法学习特定的语言。

同样，我能提供的最佳建议是亲自尝试一下，看看是否喜欢它。 如果您没有答案，那么请不要假定其他人也不能也不愿意使用它。 同样，如果您了解有关函数式程序设计和Monadic程序设计的所有知识，这并不意味着您必须将其用作与其他人打败的俱乐部，直到他们也学习为止。

InfoQ： 与Python，Groovy或C＃相比，Scala的主要优势之一是Scala完全支持函数式编程，但其语法比大多数函数式编程语言更接近Java。 Clojure还完全采用类似于传统函数式编程语言的语法来包含函数式编程。 使用Clojure和Scala有什么优势？ 有哪些权衡？

大卫·波拉克（David Pollak）

我不确定Scala是否完全接受函数式编程。 我认为Scala完全拥抱OO，并具有一些非常好的功能特性以及不变性。 尽管继承和不变性几乎无法调和。 但是我离题了。

我认为Scala和Clojure之间的差异可以归结为静态与动态，语法（哦，外观，大量的括号）等。我不喜欢动态语言。 我不是Lisps的粉丝。 但是我认为Clojure的References可能是我在过去三年中最被忽视的语言功能。 参考文献比Haskell的monad更好地统一了许多强制不变性。

另一方面，您可以在Scala的类型系统中编码的事物种类繁多且功能强大。 这种权势在右手可以导致更多的编译时错误和更少的运行时错误。 在最初的开发过程中这是一件好事，但在项目处于维护阶段时，这要重要得多。 类型系统和编译器可以指导开发人员做正确的事情的次数越多，成本越低，长期结果越好。

迪克·沃尔

Clojure是一种很好的语言，我也喜欢Clojure空间的许多原理，例如Rich Hickey，Stuart Halloway和Howard Lewis Ship。 我已经坐下来，确保我对Clojure足够了解，也可以将其包含在我的工具箱中。 过去与Lisp的合作对我已经非常熟悉了（特别是当我经常使用emacs时）。

我在Clojure中看到的两个权衡因素是，您不会从编译器获得太多支持（这实际上取决于静态栅栏的哪一侧，如果这是赞成还是反对），甚至比Scala还要多， Clojure程序员可以并且确实以自己的形象创建扩展语言，这样，当您进入别人的库或代码库时，学习曲线会非常陡峭。 STM模型（非常聪明）和非常简洁的语法是一些大的优点。

InfoQ： 对 Erlang有 什么 想法 吗？ 在可以应用Scala和可以应用Erlang的地方是否存在重叠？ （演员）

大卫·波拉克（David Pollak）

Erlang确实做到了分布式，容错性很好。 Scala（即使使用Akka）也不是。 Erlang具有出色的VM支持代码分发和数据分发。 JVM最接近的是GridGain 。 Erlang是迄今为止Erlang成功的胜利。 Erlang有一些很棒的想法可以借用（并使用Scala和其他语言），但是我认为Erlang在通用编程语言领域没有很高的价值。

迪克·沃尔

显然，Scala大量借用了Erlang，用于actor库以及模式匹配等其他功能。 Erlang已成为软件开发领域中可靠性的传奇人物，我知道Akka项目的目标之一就是向Erlang及其可靠性学习。

InfoQ： 在什么用例（应用程序类型）中，Scala 最有意义？

大卫·波拉克（David Pollak）

金融交易大厅和体育博彩。 需要性能，稳定性和事件处理的东西。 我曾经认为Scala对于社交网络应用程序（例如Twitter，Foursquare）最有意义，但是有了Node.js，Scala对髋关节人群的价值要低得多。

迪克·沃尔

就我个人而言，我会考虑将Scala用于任何项目，并且在过去一两年中，Web应用程序支持和数据持久性库进展顺利。 我发现它特别适合数学和科学应用。

InfoQ： 在什么用例（应用程序类型）中，Scala 最没有意义？

大卫·波拉克（David Pollak）

数据库前端，CRUD应用程序。 大多数使用Struts和Spring构建的无聊应用程序。 许多J / EE / Spring的运行情况都很好，不会被打乱，而且还有如此庞大的书籍，工具，培训和承包商生态系统，我认为试图将Scala推入这个领域的价值低而且可能性低成功的基础。

迪克·沃尔

但是，如果尝试将Scala与现有的大型Java项目紧密集成，Scala可能是一个更艰难的决定。 我的意思是，Scala大量调用Java，而Java又大量返回Scala。 无论如何，这都是不可能的，但是存在阻抗不匹配的问题，这很棘手，因此遵守规则并保持整洁很重要。

也就是说，以最小的风险尝试Scala的一种好方法是使用它来为现有Java项目编写测试。 测试代码不会投入生产，ScalaTest， ScalaCheck和Borachio之类的库可以大大提高编写测试时的工作效率。

InfoQ： 五年后您会在哪里看到Scala的采用？ 十年？

大卫·波拉克（David Pollak）

这取决于Scala在未来一两年内的表现。 如果Scala在一个或两个市场中占据一席之地并真正拥有这些市场，我认为Scala具有Smalltalk和Lisp的那种长寿。 如果Scala因失败而“失败”，它将在5年内再次成为研究语言。

迪克·沃尔

我确实对此没有很强烈的意见，尽管我很确定我们将在5年内仍然有大量的培训和咨询机会。至于10年间，谁知道我们将使用哪种聪明的语言？那个阶段？ 我相信Scala作为一种语言已经超越了“生存点”，并且在未来几年将越来越受欢迎。 我不相信它会像Java一样大，但是如果有的话，我认为任何一种语言都不会在很长一段时间内再次做到这一点。

InfoQ ： 有些人认为Scala是一种有趣的语言，但其语法却很难看懂。 他们抱怨Scala的类型系统比所需的更为复杂，并且具有损害可读性和可读性的几种语言功能，以及丑陋的语法（“吃一顿早餐”）。 您如何应对这种批评？

大卫·波拉克（David Pollak）

我已经看到Scala的类型系统在过去5年中不断发展。 从图书馆作者的角度来看，我认为其发展的每个步骤都是必要且有价值的。 看看Rogue家伙对针对MongoDB的编译器强制查询系统做了什么。 流氓令人cool目结舌，很容易“正确”。

因此，Scala具有一个强大的类型系统，它可以编码比我所知道的日常使用的任何其他语言更多的支票。 Scala类型的语法并不理想。 在我看来，Haskell具有更好的通用语法，并且在大多数情况下具有更简洁的语法来描述类型。 另一方面，Scala无疑是C语法的派生语言，而C风格的语言自然是丑陋的。 花3个月时间做Ruby或Haskell，然后看一些C ++并告诉我这不是“狗的早餐”。 ...

我认为非Scala开发人员不会过多考虑Scala的类型系统或其语法。

迪克·沃尔

回到葡萄酒和口味。 我不同意关于语法的陈述，我发现该陈述具有表达力，并且用良好的代码编写，非常漂亮。 在您真正尝试做一些聪明的事情之前，类型系统似乎已经过时了，例如Scala集合（非常棒，并且很好地展示了更高种类的类型）。 不过，这很重要-大多数开发人员不会使用类型系统的全部功能来编写自己的库，但是实际上，每个人在正常开发过程中都会在collection API中使用它，并且清晰，一致且非常很明显发生了什么。

就像我经常说的那样，让人们对不同意见做出解决的最佳方法是亲自尝试并下定决心。

InfoQ： 为什么您认为在Scala中进行编程的开发人员如此批评锡兰和Kotlin？ 您曾经看到过对Ruby的相同热情，但Groovy开发人员却没有看到太多。

大卫·波拉克（David Pollak）

我有我的想法，但是没有一个可以帮助推动讨论。 另外，我敢肯定，在这次采访中，我设法让更多的人不高兴，走这条路是免费的。

Groovy是所有可能世界中最糟糕的一个。 之所以存在，是因为Groovy诞生时JRuby还没有达到标准。 但是Groovy丑陋（像Java），语法不一致，元编程能力弱，性能低下，类型系统的垃圾等等。...我认为Groovy的空间是：“嗯...什么都没有。更好。没有什么值得兴奋的，但是总比没有好。” 有点像塑料垃圾桶。 他们的凹痕少于金属的凹痕，并且几乎没有其他可以兴奋的东西。

InfoQ： 是什么使Scala开发人员如此热情？

大卫·波拉克（David Pollak）

至少对我而言，它的一部分是免受不良设计决策的影响。 当我开始使用Scala时，我对许多卓越的语言（以及Java中相应的错误语言选择）大开眼界。 对我来说，那种解放的感觉赢得了很多热情。

我认为，Scala社区中有些人会进行智力欺凌。 但这是少数，尽管他们非常有声。

迪克·沃尔

有些人喜欢它，另一些人不喜欢，我想任何好奇的人都应该尝试一下并自己决定。

我必须说，除了几个人以外，我还没有真正注意到这一点。 我认识或与之合作的许多Scala开发人员只是从事开发工作，甚至不写博客，都必须减少对其他语言的公开批评。 所有社区都有他们的发烧友，有时精力会变得有点高。 我个人的观点是，我迫不及待地想尝试锡兰和Kotlin，但是与此同时，我的面包和黄油都来自Scala，我再也不会快乐了。

InfoQ： 学习Scala会使您成为更好的软件开发人员吗？

大卫·波拉克（David Pollak）

探索新的想法和概念以及对旧的想法进行新的/不同的选择将始终使一个更好。 一位出色的厨师可以向麦当劳学习。 麦当劳食品设计师（或称其为“食品设计师”）可以在五星级餐厅用餐中学习。 对于那些想拓宽视野并提高其编码技能的人，Scala是一个学习的好地方。 但是Ruby和Clojure，Smalltalk和Haskell甚至C＃也是如此。

迪克·沃尔

我相信，无论您正在学习什么，学习都会使您成为更好的开发人员。 参加地面试验学校对我的编程技能有有益的影响，尤其是了解测试和自动化的重要性。

我认为，学习Scala是使您的语言技能面向未来的好方法。 目前，我正在学习Haskell，因为这不会让您欺骗函数式编程，并且正在帮助我完善函数式开发方法。

InfoQ： 您是否可以为采用Scala的电梯提供三段式的间距，或者至少使我们指向您所知道的最好的电梯？

大卫·波拉克（David Pollak）

我将转达这个问题。 我还没有将针对Scala目标市场的想法具体化。 抱歉。

迪克·沃尔

我认为，对于合适的团队和项目，Scala将使您的工作效率更高，并提供更具可读性和可维护性的代码库。 它还可以在开发速度方面为您提供竞争优势。 对于涉及数学和/或科学成分的问题，这是非常合适的选择，并且很有趣。

至少，学习Scala将使您熟悉您将在未来几年内发布的其他现代静态类型语言中看到的功能，那么您有什么要失去的呢？

InfoQ： 您如何看待Java语言的最新更新和建议的更新？ 具体来说，您如何看待Java提出的Lambda语法？

大卫·波拉克（David Pollak）

这比用锋利的棍子戳眼睛要好。 太糟糕了，它花了大约7年的时间才能完成，并且改变了Java语言的语义（“ return”关键字变成了“有时是可选的”。）说更多的话对任何人都没有任何好处。

迪克·沃尔

Lambda项目的目标和语法对于Java来说很有意义，因为它们在方便使用现有功能方面有所改进。 我认为它们不能满足人们对完整的闭包和一流函数文字的所有需求，但是无论如何，对于需要更多功能的人来说，其他语言也可以为他们提供不错的选择。

接口注入 （如果已交付）也将是一个好处，并且可以帮助解决Scala在两个版本之间存在的兼容性问题。 任何认真的改进对Java都是一件好事，但也许在这一点上，它们不仅是对Java的增量改进，更是其他语言更强大功能的垫脚石。

InfoQ： 是否有空间使用强于Scala的语言（比Scala更容易学习），并能适当地修复Java缺陷？ 锡兰， Gosu ，Kotlin，Groovy， Groovy ++ 吗？ 或者是其他东西？

大卫·波拉克（David Pollak）

当然。 一旦类型可以像非类型语言一样具有非侵入性，整个世界就会变得更好。

迪克·沃尔

我不知道这件事-我会玩观望游戏。

就我个人而言，我发现Scala像我想要的那样简单，或者像我想要的那样强大，并且很大程度上归结为品尝代码在其中的可读性。 对于我和我所工作的团队来说，这没关系。如果出现了简单得多但仍然提供很多功能的东西，我将对其进行评估，但是我认为必须提供一些简单性或力量。

我上面没有提到的另一种语言是Fantom 。 有人说这已经是一种更简单的语言，可以在不增加Scala强大功能的情况下对Java进行改进，但是尚未得到广泛采用。 有很多理论，我个人认为这可能无法为某人提供足够的新东西来尝试切换。 显然，Scala确实增加了很多价值，因此对于新手来说应该是一个教训。 提供足够的新东西让人们感兴趣。

InfoQ： 看起来 Scala实际上在很多地方都在流行 。

大卫·波拉克（David Pollak）

有一百个左右的工作清单很不错。 证明Scala尚未死。 好极了。 但是，2009-2010年本来应该是增长曲线上的最佳选择。 Scala的采用一直是线性的，但是与2或3年前的线性相同。 因此，“未死”和“在Python流行的轨迹上”之间存在巨大差异。 Scala生态系统可能支持十几个咨询机构，并且这个数量正呈线性增长。 这与大约在2006年的Ruby / Rails完全不同。在2006年，Ruby / Rails起飞了。 在社区和采用方面，Scala和Lift和Akka似乎比Ruby和Rails落后约5年。 但是，Scala并未取得去年的飞速发展，而是继续保持良好的增长势头，但并没有像Scala成为编程语言领域的长期组成部分所需要的，而没有其他人将其商业化的研究来源。

我的目标是将Scala和Lift引入采用者可以自行选择的位置（不是“所有人”或“所有Java开发人员”，而是可以从Scala的优势中受益的组织），并且成功的故事很少，而且很少失败。 感谢您的采访，以便希望我能整理一些围绕我的帖子的讨论，以便人们广泛了解我的目标和观点。

迪克·沃尔

是的，情况很好。 我之所以没学，是因为我一定相信它会成功，我学到了它，因为我喜欢自己所看到的，并且很好地解决了我的问题。 现在，我很高兴自己做到了。

大卫回答了迪克·沃尔的一些回答。

大卫·波拉克（David Pollak）

除非您掌握了Scala，否则它会很困难，然后它会比Java更轻松，更好。 但是，无论是个人还是团队，都不要低估学习它的成本。 ...简单地争论说Scala最终会更好，但是忽略采用的机构成本，将无助于Scala在企业中的采用。

David继续解释说，在计划采用组织时，最终收益可以被否定，并且成本与收益之间需要进行平衡，以及与长期过渡相关的机会成本。

大卫的立场是，迪克（Dick）的想法反映了他关于Scala的帖子很难发表的评论和回应。 他认为逻辑是错误的（“假想三段论”）。 他将逻辑总结如下

大卫·波拉克（David Pollak）

“如果您的组织投入时间，精力和金钱来教员工Scala并过渡到Scala，那么您的组织将精通Scala。如果Scala是Java的高级语言，那么使用Scala的组织将产生出色的程序。”

如果您考虑在大型组织中使用Scala，则David认为逻辑“ Scala是Java的一种高级计算机语言，用Scala编写的程序比...用Java编写的程序优越……”是有缺陷的。 他的关注点一直在“ Scala的机构改革成本很高”这一点上。 他断言，忽略成本并专注于收益是一个逻辑缺陷。

总结一下。

Scala难吗？

迪克·沃尔（Dick Wall）的观点是，您要么花时间学习一门伟大的语言来帮助解决难题，要么花时间学习那些必须弥补他认为像Java这样的语言缺陷的框架。 因此，他认为，学习曲线的数量大致相同。 他还指出，Scala与您要解决的问题一样困难。 即使您断言Scala有疣，Java也有其自身的缺陷和问题，这由Dick指出。 它可能是已知复杂性（Java）与未知复杂性（Scala）的问题。 David带来了学习Scala的最大障碍是忘记Java强迫您养成的不良习惯。

缺乏良好的IDE支持和大型公司的支持是否会损害Scala的采用？

David所说的工具栈还不够成熟，无法被主流采用。 迪克指出，这种支持是相当不错的，但可能并不完美。 对许多组织来说，IDE支持可能是一大障碍。 同样，例如，如果Eclipse对Scala的支持不佳，并且您在一家以Eclipse为认可标准的商店工作，则可能难以使用另一个更好地支持Scala的IDE。 根据组织的不同，这可能是一个小障碍，也可能是一个秀场停止者。 良好的IDE支持似乎是在第一层语言范围（C＃，Java，Python，Ruby）上广泛采用的必要条件。 另一方面，Ruby和Python直到最近才获得了良好的IDE支持，但是它们取得了重要的成功，早于良好的IDE支持。

David的观点Scala需要强大的企业支持者（Oracle，Microsoft和Sun）才能成为第一层语言。 有人可能会说，Python（创建于1980年代末）和Ruby（创建于1993年）花了很多时间才真正流行起来（2003年和2005年），而且它们没有强大的公司支持者，被认为是第一语言。 因此，Scala可能与它们处于同一条较长但可持续的曲线上。

很难找到好的Scala开发人员？

David指出，如果您能负担得起$ 250.00的小时费率，或者愿意雇用顶尖的开发人员并对其进行培训，则可以轻松找到优秀的Scala开发人员。 很难以40美元的价格找到优秀的开发人员。 仅每小时赚250.00美元的潜力就可以鼓励一些人在业余时间学习Scala（或为一个项目提出建议）继续前进。 这些价格可以说服开发商，作为纯粹的经济催化剂，值得付出努力。

Dick指出，找到Scala开发人员并不难。 他断言，您发现的开发人员将是精力充沛，专注，自我启动的那种。 人们还可以想象，作为早期采用者的开发人员可能与采用下一个热门趋势的开发人员相同，这可能意味着较少的前沿语言可以吸引长期稳定的开发人员，这些人会坚持一段时间。

学习Scala会使您成为更好的开发人员吗？

有人可能会争辩说，如果您真的想专注于开发功能性编程肌肉，那么在不分散Scala其他功能的情况下，Clojure或Haskell将是很好的学习语言。 这也许可以使您成为一个更好的Scala程序员，或者至少一个可以在功能上进行更多思考（编程）的人。 虽然，Scala似乎是学习现代强类型OOP /功能语言可以做什么的好地方。

转弯处的竞争对手：

Kotlin和Ceylon的灵感来自具有现代语言功能的Scala强类型。 Kotlin和Ceylon的压力可能会迫使像David这样的人质疑Scala的广泛吸引力。 当然，很少有Scala开发人员会在每次发布具有现代语言功能强类型的JVM语言的每一次声明时都会扑朔迷离。 Scala可能会面临激烈的采用竞争。 具有更主流语法的功能较弱的语言以及修复Java疣的良好工具支持是否存在？ 如果可以的话，它能否超越Scala的采用？ 时间会证明一切。 在这里，由于学习曲线较长，Scala的优势（力量）可能会变弱。 另一方面，Kotlin和Ceylon可能成为更广泛地采用Scala的门户语言。

Scala是否很难学习似乎取决于您的观点，背景和品味。 如果您需要一些框架来弥补力量上的差异，那么您就必须考虑这些框架的复杂性。 似乎Scala在这里保持某种形状和形式。 Scala影响了Java的Lambda语法。 Scala将成为下一个Java吗？ 不太可能，但是似乎它成为了像Ruby或Python这样的第一层语言。 只需要十五年。 具有强大类型的现代编程语言功能以及很少的遗留疣的Scala可能正在激发大量新竞争者（例如Ceylon和Kotlin）和一些旧竞争者（Groovy ++和Gosu）。 在将大型组织迁移到Scala时，应考虑David的宏观采用观点，而在提高自己的技能时，Dick关于Scala的功能和效用的观点也应予以考虑。

翻译自: https://www.infoq.com/articles/barriers-to-scala-adoption/?topicPageSponsorship=c1246725-b0a7-43a6-9ef9-68102c8d48e1