java项目集成scala_在至少一半的Java项目中,Scala的使用效果不如Java。

java项目集成scala

所以,我做了一个帖子关于与有关Scala的是“硬”的Java开发人员的很大一部分后同意。 这篇文章引起了相当多的“讨论”,其中很多都曲解了我的帖子。 我正在发表一篇文章,希望就谁,为什么和我的动机会更加清楚。

首先,关于我。 我叫大卫·波拉克(David Pollak)。 自2006年11月以来,我一直活跃于Scala社区。我是Lift网络框架项目的创始人。 以下是重要的要点:

  • 我连续编写Scala代码的时间比EPFL之外的任何人都更长。 [更新– @propensive和Bill Venners在Scala社区的时间比我更长。]
  • 我在2008年开始了第一次Scala会议,即Scala Lift Off ,直到今天仍在继续举办该会议。
  • 我编写的Scala代码行(超过250K)比地球上几乎任何人都多。
  • 我写了一本流行的介绍Scala的书,叫做Beginning Scala
  • 在过去的近5年中,我在Scala和Lift邮件列表中进行了10,000多次与Scala和Lift相关的交互(这意味着我已经与许多开发人员进行了交互。)
  • 我创建了Lift网络框架项目,并编写了大量的Lift,包括设计Lift的核心API。 Lift是最流行的基于Scala的框架之一,也是第一个广为人知的 Scala库。
  • 去年,我审查了超过500,000行Scala代码。
  • 我主要在Scala和Lift相关项目上提供生活咨询,并且对很多项目都有广泛的了解。
  • 在过去的5年中,我已经针对Scala和Lift进行了25次以上的演讲。
  • 我教过数百人以小组形式使用Scala和Lift。
  • 我直接或间接向TypeSafe主页上列出的一半Scala大名用户介绍了Scala。

以上都是说:“我在编码Scala,教授Scala以及将Scala引入各种环境中都有丰富的经验。 我已经与足够多的Scala用户和潜在的Scala用户进行了互动,以便在我对Scala成功因素进行分析时可以借鉴广泛的数据基础。” 这并不意味着我认为我是对的,其他所有人都是错误的。 它,然而,意味着谁使用对人不对事的人 言辞 来反对我的帖子都在自己的岗位非常少的有效性和价值 。 [更新:重新阅读@fogus的帖子……我误解了。 我认为@fogus和我得出相同的结论。 我坚持我没有永久保留模因的主张。 但是,对于在@fogus及其帖子上的粗暴行为,我深表歉意!]

以此作为我的设置,让我给你我的结论:

对于大多数Java开发人员来说,Scala是一种不合适的语言,不能期望它取代Java,因为对于至少50%的Java开发人员而言,Scala的困难超过了其价值。

这应该没有什么争议:

Java对于大多数PHP开发人员来说是一种不合适的语言,不能期望替代Java,因为对于至少50%PHP开发人员而言,Java的困难重于其价值。

当我在上一篇博客文章中使用“对于某些开发人员而言,Scala很难”时,我在这里要更加精确。 我并不是说觉得Scala很难。 但是,我观察到很多开发人员发现Scala很难,并且 这里这里概述了我的推理。 对于这类开发人员,Scala的价值超过了Scala的成本。

讨论区

我最不擅长的一件事是拼写。 我的大脑只是不记得单词的拼写。 当我是大学报纸的编辑时,其中一位记者因为不敢拼写而懒惰(这是1985年……在拼写检查之前。)我在黑板上写了一个积分(这是在白板之前) ),请她解决。 她说:“那是数学……很难。我在说的只是拼写。” 好吧,对我来说,我可以解决睡眠中的积分问题,也无法拼命挽救生命。 不同的人有不同的技能。

不同的人重视不同的事物。 有一类人喜欢计算机并且喜欢编码。 我在那堂课上。 有一群人不会将编码放在他们喜欢做的前五件事中。

有很多开发人员选择开发作为他们的职业,但缺乏先天能力和动力的结合。 有学校培养这种思想。 大量的博客和鼓舞都不会改变这一点。

对于那些缺乏天生的编码能力和提高自身兴趣的人来说,Scala是一种责任。 如果周围有太多Scala负债(即,失败的Scala项目),Scala将停止增长,对于像我这样在Scala生态系统中投资超过60万美元的人们来说,这是一个非常不理想的情况。 帖子末尾更多关于动机的信息。

反对我的“ Virgina”帖子的主要论据之一是,我们必须采用Java开发人员库,因为Scala的性能还不够好,无法实质性地改善池的整体质量。 引用我:

我明确拒绝了“那么,找到更好的开发人员”的论点。 我们可以通过提高开发人员(可以读取类型签名的人员,可以以数学方式表达程序的人员等)的整体质量来解决“ Scala很难”的问题,但是这没有切合实际。 Scala尚不足以迫使其在培训,教育和招聘方面进行革命,以使Scala能够改变普通开发人员的质量,从而使Scala对该开发人员而言并不难。

我同意Paul Snively的观点, Scala是可以学习的 。 这就是为什么我多年来一直积极宣传Scala的原因。 问题在于,Scala 对某些人是可以学习的。 该类不包括那些不想学习它的人和那些没有能力学习Scala的人(就像有些可以编写PHP但不能编写Java的人一样)。

实际上,我一直在说有一类开发人员,对于Scala来说 ,将近四年都不适合 ……甚至更长的时间,但这是我能找到的最古老的职位。 我当时的职位与许多人现在的职位没有什么不同:培训或解雇使用Scala效率较低的开发人员。 我也很清楚,有一类纯Java开发人员在Scala上至少三年没有成功 。 所以,我的立场多年来一直很稳定。

发生的变化是,我已经意识到,有很多开发商店供开发人员出现,参加一些会议,编写几行代码然后回家。 在过去的一年中,我曾在该公司的三个实例中工作过。 一个采用Scala的人虽然很挣扎,但是尽管用Scala编写Java出现了问题,但仍在尝试做正确的事情,招募开发人员和内部抵制。 一个人决定不采用Scala(尽管VP Eng在生产中不了解一点Scala,但是它由一个人维护,因为这个人Scala在工作上比Java更好)。从Scala退回Java,因为更换一半开发人员,将剩余员工的25%派到昂贵的课程上以及上述项目的部分外包所带来的机构成本超过了Scala为前三名开发人员带来的价值(尽管这是一个非常艰难而亲密的电话。)

我们生活在一个平均每个开发人员每年编写3,250行代码 (每天约20行)的世界中。 这是进入Eclipse的过程,按下“给我模式X”并填充空白,然后参加几次会议,并称之为一天。 我们不能解雇所有这些开发人员。 我们不能训练这些开发人员变得更好。 这是中值的中心。 这名开发人员可能是Dilbert卡通的屁股。 但是您知道,那是使用Java的人。 您知道还有什么,开发人员缺乏先天能力的某种组合,并且会变得更好。 不仅如此,而且在开发人员的管理链中一直没有改变这种状况的能力或意愿。 我们不能搬上这座山……或更具体地说,Scala的优势无法使商店解雇效率低下的开发商中的50%。

因此,更好的行动方针是:

  • 专注于可以从Scala获得3倍或更多收益的开发人员和项目; 要么;
  • 为COTM开发人员改进Scala(只要Scala主要是研究驱动的语言,就不会发生这种情况)

动机

因此,“您会问”什么?您编写一系列似乎使Scala看起来不成功且困难的文章的动机是什么?”

自从五年前遇到该语言以来,我一直是Scala的支持者和支持者。 很少有人能将Scala的事业向前推进,而我对看到Scala和Lift继续取得成功抱有浓厚的既得利益。

Scala看到了一些非凡的成功案例。 围绕Scala的报价和文章以及令人敬畏的一般感觉既巨大又当之无愧。 Scala是一种了不起的语言,并且在解决各种简单到复杂的问题的多功能性方面,在当今的计算中还没有同等的语言。

但是,Scala并非万能药。 Scala在雇用优秀开发人员的地方很成功。 与Java或大多数其他语言相比,Scala使那些开发人员的能力倍增。 但是,在专家不满或什至更糟的情况下,在那些讨厌Scala的人的手中,它不如Java好。 这导致了团队冲突和不和,在给定团队类型的情况下,常常以被动进取的方式表现自己,即船期延误并最终归咎于语言。

为了使Scala继续增长,必须继续以最少的Scala故障实现Scala的成功。 这意味着是开放和诚实的Scala的长处短处是必要的,以便正确地选择Scala和电梯。

Scala的成长意味着,Scala必须被那些具有适当能力和渴望用Scala构建令人惊叹的东西的开发人员所采用。

我们必须接受Scala不会为绿屏,CRUD,DB前端应用程序替换Java。 Scala进行ORM的价值(对不起,Max……Squeryl真是太神奇了)远小于Scala进行实时,分布式,并发应用程序的价值。 但是世界上大多数地区都在进行ORM,CRUD,绿屏,填写表格并更新数据库之类的工作。 那就是大多数开发人员和金钱所在的地方。 虽然很酷的孩子正在构建大型的,含糊的,事件驱动的,超超超级混合数据,实时,嗡嗡声,嗡嗡声的东西,但大多数开发人员却在无聊地移动数据和数据库和Oracle / SQL提供了一个完美合理的并发模型。

作为一个社区,我们必须接受Scala的弱点。 我们必须招募那些将充分利用Scala优势的开发人员。如果存在合理的失败可能性,我们还必须积极劝阻人们不要使用Scala。 拥有“ Scala很难”或“ Scala确实是优秀的开发人员”品牌要比拥有“ Scala有风险,而且常常导致失败”品牌好得多。

我写这些文章的动机是在开发人员的大脑中提高这种意识。 我宁愿在明年看到5,000个新的Scala项目,其中4,000个成功,而不希望看到50,000个新项目,其中10,000个成功。 有能力和意愿成功使用Scala的开发人员可能会阅读我的文章,并声称在尝试和成功使用Scala之后我不知道我在说什么。 其他开发人员将重复该结论(“ Scala太难了”),并选择不使用它。 这样的结果可能会导致百分比更大的Scala成功,直到Scala对COTM开发人员变得更好为止,这才是Scala和Lift取得成功的更好途径。

哦……所有邪恶的聪明人都在努力(或认为会)在数据大小,事件频率和实时性方面突破界限,您会发现Scala梦想成真,而且没有比这更理想的了您曾经使用过(好吧,也许Haskell除外)。 因此,来吧,在Scala上构建您的出色产品并取得成功。

参考: 我们的JCG合作伙伴 David PollakGOOD STUFF博客上,至少有一半的Java项目中Scala的使用不如Java

相关文章 :


翻译自: https://www.javacodegeeks.com/2011/09/scala-use-is-less-good-than-java-use.html

java项目集成scala

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值