除了性能问题,为什么Java仍然选择Groovy/JRuby等？

Question

[这是关于最新技术的经验问题:我不是在问Java是否比在JVM中运行的动态语言更酷或更酷.

除了性能是主要决策因素的情况之外,公司/开发人员是否仍然愿意选择Java而不是Groovy,JRuby或Jython？

编辑:如果答案是"是",为什么？

个人注意:我要问的原因是,虽然我在Ruby中做了一些我的专业工作(现在不是JRuby),但在我的个人项目中,我使用的是Java.虽然我在Groovy中编写了非平凡的应用程序,但我更喜欢Java,但我想知道我是否应该克服它并在Groovy中做所有事情.我喜欢Java,因为我觉得静态打字可以节省我的时间并帮助重构.(不,我不熟悉Scala.)但是,我觉得这个非常经验的,关于主题的编程问题可能会为我的决定提供信息.

Answer 1

静态打字仍然是一件大事.

虽然它一再被争论,但动态方法的支持者表示,通过足够的单元测试可以减少(甚至消除)动态类型带来的问题.

我不想争论这个论点是否正确,所以我认为这是对于这个答案.

在这种情况下,仍然存在一个问题,即许多商店没有程序/技术诀窍/规则/管理来产生足够数量的高质量单元测试.

如果我必须在没有单元测试的动态类型代码和没有单元测试的静态类型代码之间进行选择,我将每天选择静态类型的代码.

双重调度存在类似问题:

在Groovy方法中,调用基于运行时的实际参数类型进行调度(这几乎是必需的,因为静态类型是未知的和/或Object大部分时间).这意味着当面对可扩展的类层次结构时,没有可靠的方法来知道在代码的任何给定点调用哪个方法.

任何在foo(String)大多数情况下都使用签名调用方法的代码可能会突然调用foo(Integer)或foo(SomethingElseEntirely)仅依赖于运行时参数的实际类型.在Java语言中永远不会发生,因为要调用的方法的确切签名是在编译时决定的.

与其他"动态"语言特性非常相似,双重调度有时候是一个非常有用的工具,缺少它可以在Java中产生一些丑陋的结构,但它的成本却使得它更难以阅读,理解和推理代码.

Answer 2

非静态类型语言在维护意义上不能"扩展".最多可以维护几万行代码.过去他们只需要花费更多精力来维护,重新考虑或更新.任何非静态类型语言,Perl,Python,Groovy,Ruby等都是如此.用于处理50万行Python代码的工具与使用C/C++/Java中相同数量的代码行的工具不同在那里.现在,Python作为等效的Java程序的代码行数约为1/3到1/5.所以这永远不会是苹果和橘子,但是有一个截止点,非静态语言中的代码行数会减少维护的回报.众所周知,维护是软件项目的真正成本所在.

Answer 3

是的，显然。

为什么企业仍然“心甘情愿”地使用Java？

因为企业本质上是保守的。他们改变技术并不是因为它们很酷，甚至很酷。当有审慎的理由时，他们会不情愿地改变。早期采用者会因为成为早期采用者而付出非常沉重的惩罚。

编辑：这不是贬义意义上的“惰性”，如“除了抵制变革之外没有理由避免变革”，而是谨慎意义上的“惰性”。在有事实证明更好的东西出现之前，公司不应放弃有效的东西，这是正确的。

并不是“让开发人员高兴，因为它很酷”的更好感觉，而是更快速、更可靠地满足推动组织发展的任何业务需求。

Java 提供：

1. 拥有大量训练有素、经验丰富的开发人员。如果不选择一种出现时间不长的语言，就很难找到能够做好软件开发的人。培训人们使用新语言在时间和金钱上都是昂贵的。

2. 品牌知名度和成功完成项目的易于证明的跟踪记录。这没什么可嘲笑的：如果我告诉高层管理人员我正在用他们从未听说过的某种新语言开始一个项目，我必须对他们进行教育，他们会认为这是一种风险。对于任何“已建立的”语言，我都可以跳过这一步。

3. 完善、成熟的支持工具和第三方支持。

这些优势体现在一种历史悠久的语言和一种新语言之间的任何比较中，而不仅仅是 Java 和您的列表之间。我预计有一天，Groovy 等将成为既定的语言，并且会有人对某种更新、更闪亮的语言提出同样的问题。这就是循环。这比我从事这个行业的时间还要长。