scala 类 java类_Scala是否应该朝着Java之类的主流语言发展?

scala 类 java类

有人说Java 8引入了lambda表达式之后,Scala失去了它的吸引力,因为现在也可以直接在Java中进行函数式编程。

您对此有何看法/h3>

Heiko Seeberger: Java仅仅通过添加lamda并不能成为一种功能编程语言。 顺便说一下,Scala也不是纯函数式编程语言。 您可以清楚地看到lambda嵌入到Java Development Kit(JDK)的集合库中的方式:通过流,因为您无法使用功能概念来处理可变集合。 Java 8可能是Scala和其他函数式编程语言的“入门药”,因为开发人员可以对函数式编程概念产生第一印象,学会喜欢它们,然后环顾四周,看看还有什么。

Markus Hauck:函数式编程不只是lambda表达式-它们只是其中的一小部分。 这是编写和组织软件的完全不同的方式。 Java和Java生态系统位于面向对象的程序设计中,因此,如果您想在Java中使用功能性程序设计,则必须首先学习另一种语言才能真正理解功能性程序设计的含义。 由于Scala在这方面非常出色,因此为什么要切换回Java

Daniel Westheide: Lambda表达式不是一种功能编程语言。 您可以使用Java 8编写功能代码,但它的支持程度却不高。 没有对currying的适当支持,例如,伴随更差的类型推断的某些事情。 完全依赖于不变数据结构的标准库也是功能编程语言的必需部分。 Java和周围的生态系统不是这种情况。 另一方面,Scala完全依赖于不变的数据结构,由于结构共享,它们在Scala集合库中也得到了更有效的实现。 由于除了Java中的所有数据类型和结构通常都是不可变的,因此无需昂贵的防御性复制就可以做到。 此外,Scala提供了许多工具,它们仅属于静态类型化编程语言中的函数式编程,例如Case类,For-Comprehensions,Pattern Matching和Type类。 我真的会在Java 8中怀念他们。

伊万·库萨利克(Ivan Kusalic): Lambda只是其中的一小部分。 Java仍然是主要的命令式OO语言。 关于curring,模式匹配,更高种类,不变性呢这是朝着正确方向迈出的一步,但是如果不破坏向后兼容性,Java将永远不会成为Scala。 没关系,他们俩都有自己的优点。 但是在我看来,说Java 8是一种功能语言是相当错误的。

Daniela Sfregola: 我认为在Java 8中引入lambda函数后,Scala不会失去吸引力。我实际上却相反。 Java仍然缺少Scala可以提供的许多功能:隐式,理解,特征,类型推断,案例类,简单的货币支持,不可变的集合……等等! 在Java 8中引入lambda表达式为OO开发人员提供了一个品尝功能性编程功能的机会-然后再使用Scala或Haskell之类的语言一路走来。

Julien Tournay: Lambdas当然是Java社区期待已久的功能。 尽管这是向前迈出的一步,但它本身无法实现Java中的函数式编程。

功能性编程语言至少具有对不变性的一流支持。 Lambda使基本的功能技术成为可能,我很高兴看到Java社区对这种可能性的崭新世界感到兴奋,但是Java首先而且现在将永远是面向对象的。


React性
要了解有关React式编程的更多信息,请下载最新一期的《 JAX杂志》:

    • 使用Scala,Lagom,Spark,Akka和Play进行React式编程

响应式编程对不同的人意味着不同的事情,我们不打算重新发明轮子或定义这个概念。 相反,我们允许我们的作者证明Scala,Lagom,Spark,Akka和Play如何共存并共同创造一个React性的宇宙。

如果“事件流”的定义不满足您对知识的渴求,请准备好了解响应式编程对我们在Scala,Lagom,Spark,Akka和Play方面的专家意味着什么。 另外,我们与Scala的创建者Martin Odersky进行了交谈,讨论了即将推出的Scala 2.12,该编程语言的当前状态以及等待我们的技术创新。

渴了吗打开杂志,看看我们为您准备了什么。

我们如何定义它/h3>

Heiko Seeberger: Scala生态系统非常活跃且广泛。 Lightbend Reactive Platform产品,尤其是Akka和Play,代表了这一“工具箱”的重要组成部分。 不应将其理解为与JEE和Spring相对的模型,而应将其基本上视为一种全新的体系结构方法:想要构建React式清单定义的系统的任何人都必须使用Akka等现代工具,而不是仍在使用的技术。遵循“每个请求一个线程”的原则,并让分布式数据库处理该分布。

马库斯·豪克(Markus Hauck):可以使用“建筑套件”,但不能“宽松”。 如果不需要其余部分,则可以很好地单独使用堆栈的各个部分。 同时,如果需要,您可以稍后添加它的一部分。 但这不是偶然的集合,有一个共同的焦点适用于所有这些集合,即构建React系统。

Daniel Westheide: 在我看来,Lagom确实是一种尝试为Java EE和Spring提供相反的模型,并且它针对企业环境中的Java开发人员。 到目前为止,只有Java API,而我们仍在等待Scala API。 堆栈中的其他工具更像是一个松散的工具箱。

如果您选择Akka作为Java EE和Spring的对立模型,那么最终您将使用Event Sourcing和CQRS。 通过将Play与Slick结合使用来链接到关系数据库,Java EE和Spring有了另一种选择,它对某些体系结构和技术决策没有太大的影响。 由Spark,Mesos,Akka,Cassandra和Kafka组成的SMACK堆栈非常受欢迎。 但是我不认为它是Java EE或Spring的对立模型,因为它是为解决一组完全不同的问题而构建的:快速数据和大数据处理。

伊万·库萨利奇(Ivan Kusalic):我的 上下文不是典型的CRUD方案和企业Web应用程序的上下文,而是云设置中高度分散的系统的上下文。 有时甚至在DevOps方面。 我玩过堆栈,看起来很棒,但是我每天都只使用Akka,所以我将把这个问题留给可以提供更明智见解的人。

Daniela Sfregola: 我没有JavaEE或Spring的丰富经验,因此比较它们时我感到不舒服。

Julien Tournay: 的确,Scala开源社区非常活跃。 当然,Spark是Scala采用的巨大推动力。

该堆栈是JEE或Spring的替代方案吗好吧,JEE和Spring都是大型生态系统,因此,Scala生态系统中的项目正在与JEE或Spring生态系统中的项目竞争。 Lightbend开发的项目对他们认为Scala应该是什么有着共同的愿景。 他们试图使构建的所有内容对Java开发人员可用。

例如,您可以使用Play而无需编写任何Scala代码。 当然,这里需要权衡。 两种语言的开发都需要更多时间。 设计一个Java开发人员可以使用的API,同时又不影响其Scala同类产品的设计也可能很困难。

但是,由于Java不仅限于Oracle开发的项目(Spring是一个很好的例子),Scala也不限于Lightbend的计划。 Typelevel所做的工作对我来说尤其有趣。 他们将Scala推向更多功能性途径,并且还建立了一个一致的生态系统。 我认为,从Java背景来到Scala的人们可能会开始使用Lightbend的技术,并在几个月后对某些功能性想法感到满意之后将某些项目移至Typelevel。

还请参见: Scala创作者Martin Odersky的访谈— Scala的当前状态

我们可以针对哪种应用程序使用堆栈/h3>

Heiko Seeberger:具有Scala和Akka的堆栈适用于各种应用程序。 它的优势对于您的个人网站不会发挥作用,但是在您需要构建高度可用的系统时才发挥作用。 我最喜欢的例子之一是加拿大沃尔玛 。 他们使用传统技术建立了一家网上商店,该商店经常在前几天因负载高峰而崩溃。 在加拿大沃尔玛(Walmart Canada)改用Scala,Akka和Play之后,停机不仅消失了,而且还节省了一些软件许可费用。

Markus Hauck:此堆栈适合必须快速响应和/或扩展至大量数据的应用程序。 同时,它的模块化程度足以使用户有机会选择和使用他真正需要的零件。

丹尼尔·韦斯海德(Daniel Westheide): 正如我之前提到的,我并不将这些技术视为固定的堆栈,而是视为单独的实体。 Akka非常适合需要低延迟的应用程序,因为您可以使用Akka Persistence在内存中维护应用程序的当前状态。 这不仅对于物联网环境,而且对于交易,实时竞标或多人游戏而言,都可能令人兴奋。 当您说Akka Persistence时,您也说了Event Sourcing,因此Akka是一个不错的选择,除了延迟和吞吐量事件Sourcing以外,其他原因还包括审核日志或作为商务智能的中介。 Akka和Spark与Cassandra和Kafka一起注定要实现Lambda架构。

伊万·库萨利奇(Ivan Kusalic):我将不得不允许其他人回答这个问题。

Daniela Sfregola: 此类堆栈的应用范围非常广泛,并根据您要求的性能和应用类型而有所不同。 Play和Lagom用于快速构建简单的应用程序; Play还支持HTML5,因此非常适合像我这样的人,他们对JavaScript不太满意,并且需要构建简单的网页以及服务器端。 Lagom是一个相当新的框架,用于基于事件源构建微服务。 Akka是多种工具的集合,可用于构建更复杂和可扩展的服务器端应用程序-从API的HTTP层到Actors系统再到集群管理。 Spark用于高效地处理数据,因此它通常非常适合需要处理和聚合连续数据流的大数据应用程序。

Julien Tournay: 我想Lightbend的生态系统正在试图成为构建分布式应用程序的参考栈。 肯定有很多很棒的项目。 例如,我非常喜欢Akka Streams。 除此之外,Scala与Java一样通用。 您几乎可以构建任何东西:)

查看我们的Scala专家清单

  • 问题的6个答案:为什么使用Scala而不使用Java
  • 剖析Scala 2.12:6个开发人员权衡了好,坏和计划

Heiko Seeberger:有趣的是,关于缺少兼容性的故事仍然存在。 从2.9版开始,Scala自2011年以来一直是100%与次要版本兼容。 以前不是这样,这很烦人。 如果今天每两年发布一次主要版本,以消除标记为@deprecated的API,那么我欢迎您。 对我来说,Scala走在正确的道路上,因为即使开发人员考虑了兼容性,仍在进行创新。

马库斯·豪克(Markus Hauck):对我来说,斯卡拉(Scala)是并且将继续是一种创新语言。 尤其是在以探索性方式开发语言时,重要的是让失败消失,Scala过去处理得很好。 就我而言,向后兼容性起着重要的作用,但不惜一切代价。

Daniel Westheide:我认为目前的步伐还可以。 我们不得不面对不相容的变化的时代已经过去。 在过去的几年中,Scala甚至扩展到了大型的传统组织中,这一事实表明向后兼容性做得很好。 那些想要更多更快的创新的人可以选择使用Scala的Typelevel分支。

伊万·库萨利克(Ivan Kusalic): 我当然想要两者。 此时,越来越多的公司正在使用Scala,因此向后兼容性变得越来越重要。 但是,这并不是语言停止发展的原因。 希望在过去的Scala行为和过于保守的Java进化之间有一个甜蜜点。

Daniela Sfregola: 我认为Scala应该同时做到! 对于任何一种语言来说,被广泛使用并拥有一个良好的开源社区来支持它是非常重要的:该语言越流行,越容易发生,因此要牢记不同版本之间的向后兼容性。 但是,我还认为,如果社区要求进行重大更改或新的创新功能,那么中断与以前版本的兼容性是使该语言保持鲜活和有趣的一种有效选择。

朱利安·图尔奈: 这又是一个很难回答的问题。 向后兼容性非常重要,应该在语言级别上打破它。 自从Python 3发行以来,Python社区一直在艰难地学习这一方法,而Python 3多年来一直未能取代Python2。总的来说,我希望Scala语言将继续发展和改进。 我非常感兴趣地关注Dotty(Scala的下一个主要版本)的工作。

翻译自: https://jaxenter.com/scala-expert-check-part-3-scala-mainstream-like-java-130007.html

scala 类 java类

文章知识点与官方知识档案匹配,可进一步学习相关知识Java技能树首页概览92193 人正在系统学习中 相关资源:聚会喝酒看美女必备APP_秀人网-Android其他资源-CSDN文库

来源:diluan6799

声明:本站部分文章及图片转载于互联网,内容版权归原作者所有,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!

上一篇 2020年5月25日
下一篇 2020年5月25日

相关推荐