16

在我看来，在某些方面，Java 是 C 很久以前的地方。两者在当时都是相当简约的语言，具有相对干净、简单的核心构建。（我指的是这里的核心语言，而不是库。）两者都非常流行。两者都是/曾经是通用语，具有大量遗留代码。两者都缺乏其他语言的程序员经常错过的几个现代生产力功能。两者似乎都非常惯性主导，并且适应不断变化的世界的速度很慢。

在我看来，创建一个大致是 Java 超集的 Java++ 是合理的，就像 C++ 之于 C 一样。这种语言会试图让 Java 摆脱它所经历的相对停滞，只在少数情况下破坏向后兼容性仅在绝对必要的情况下使用次要方法，添加许多普通旧 Java 所缺少的现代特性，并担心以后的标准化。可能是个好主意的功能包括：

  1. 一流的功能，代表。
  2. 关闭。
  3. 静态类型推断，类似于varC# 或autoD 中的类型。
  4. 运算符重载。
  5. 结构体作为不同于类的值类型，如 C# 和 D。
  6. 特性。
  7. 忽略检查异常的选项。
  8. 在一个文件中声明多个顶级公共类的能力。
  9. 更强大的内置数组，允许追加之类的东西。
  10. 更好的泛型/真实模板。
  11. 类似于 C# 4.0 的动态关键字，它允许在必要时以一般静态语言进行鸭式输入。
  12. 由于 Java 主要是一种 VM 语言，因此可能有一些核心元编程功能，例如为某些事情动态生成代码。

你认为这种语言会有需求吗？你认为这样的事情会成功吗？

编辑：我不是在谈论运行时/字节码级别的兼容性，而是在源代码级别谈论与 Java 的兼容性。此外，是的，Java 7 可以添加其中的一些，但似乎为 Java 添加功能的“官方”过程非常保守。真正的重点是将Java分叉成一个分支的想法，重点是创新而不是稳定性/标准化。

4

19 回答 19

29

比如，Scala或更好的 Groovy，它自称是 java 的动态版本？

于 2009-01-27T16:48:01.850 回答
20

Java 粉丝对此会否决，但作为同时编写 Java 和 C# 的人，我会说 C# 与 Java ++ 一样接近。

C 到 C++ 是一个范式转变，从面向过程到面向对象，他们保留这个名称的唯一原因是吸引 C 程序员认为它是导致大量伪装成 C++ 的非常糟糕的 C 代码负载的同一语言。

Java 不断扩展，Sun 正在迅速整合越来越多的功能，因此 Java 7 或 8 很可能是您的 Java ++

于 2009-01-27T18:14:14.437 回答
18

我认为“我们需要 Java++ 吗？ ”的答案取决于“我们”是谁（我不确定“我们”是否都是一个类的实例 ;-)。Java Posse不止一次讨论过这个问题。

Java 的大型企业用户倾向于更加保守。他们有大量的开发人员和大量的现有代码。因此，对语言或库的更改（培训、维护、现有代码的破坏等）存在很高的感知成本和风险。

另一方面，有许多小型的、轻率的开发团队（开源或其他）随时准备抓住编程中的下一个好主意。我不清楚一个答案是否会让每个人都足够满意。

我建议不断增长的基于 JVM 的语言生态系统可能有助于解决这种紧张局势。如果较新的语言（Scala、Fan、JRuby、JavaFxScript 等）提供第二组所需的符号特性（和新颖性），同时保持与现有 Java 的互操作性（可以以更稳定的速度移动），也许这两个组都可以有他们选择的蛋糕口味。

我对某些人似乎想要一种真正的语言的程度感到有些困惑。在过去，很常见的说法是每种语言（符号）都有一个适用的“甜蜜点”。有时正确的解决方案是用适当的语言编写系统的每个部分并将它们链接在一起。

回到未来，有人吗？

于 2009-01-27T17:48:50.010 回答
6

问题实际上是您如何决定“下一种语言”的内容。只是零碎地添加/删除功能会导致一堆废话。最好考虑一下这些功能的添加或删除（通常结合使用）如何根据新原则改变您的编程方式。例如，我认为有趣的是，Java 闭包提案在许多方面都因必须在没有丰富类型推断的情况下处理静态类型而受到影响。有大量具有漂亮闭包的动态语言示例-它们很好地结合在一起。Scala 和其他语言已经表明，静态类型加上丰富的类型推断也可以使闭包变得漂亮。我的观点是，采用语言 X 并制作语言 X++ 可能并不那么有趣。它'

现在肯定没有什么可以阻止您分叉 Java 并将其变成您想要的任何东西（只要您不称它为 Java 或想要通过测试套件）。如上所述，现在已经有一组令人兴奋的高质量语言可以做到这一点并保持与 Java 的互操作性。我主要考虑的是 Groovy、Scala、Clojure 和 Fan，而不是像 JRuby、Jython 和 Rhino 这样的 JVM 先前语言的端口，这些语言在实现干净的 Java 集成时往往更具挑战性。

Java 7中的 JVM 中的JSR 292 特性很可能会在已经非常出色的 JVM 基础上为语言开发提供更丰富的平台。CLR+DLR 也在推动许多有趣的界限。

越来越多的，我认为未来将倾向于为工作选择正确的语言。这要么发生在具有混合传统的语言中（例如 Scala 是 FP / OO 的一个很好的例子），要么发生在促进多种语言之间干净集成的虚拟机（JVM、CLR、BEAM、Parrot 等）中。或者最有可能的是，两者兼而有之。我认为我们不会倾向于任何一种衍生自 Java（或其他任何东西）的 Next Big Language。

于 2009-01-27T19:32:58.910 回答
6

目前在 Java 中，有许多解决方法，这确实使得引入更自然的方法来做这些事情变得更加困难。

  1. 一流的功能，代表。

大多数情况下使用反射会更短。（但不太自然）

.4. 结构体作为不同于类的值类型，如 C# 和 D。

我会同意这一点。

.5. 特性。

现在可以做到这一点，但需要付出一些努力。适当的内置支持会更好。

.6. 忽略检查异常的选项。

你现在可以这样做，但它是一个黑客。注意：检查异常是编译时功能。

我相当怀疑这是否真的是一个好主意，除非人们真正理解异常。通常提出这个建议的人不喜欢被迫考虑错误情况、记录或处理它们。

.7. 在一个文件中声明多个类的能力。

你现在可以这样做了。只是不超过一个顶级公共课程。

.8. 更强大的内置数组，允许追加之类的东西。

请参阅公共 ArrayUtils。一个具有健全 toString() 的数组将被启动。

.9. 更好的泛型/真实模板。

我同意，这取决于你的意思。我认为他们应该先让当前的实施工作，然后再改进它。例如，Java API 可以在没有未经检查的警告的情况下编译。

.10. 类似于 C# 4.0 的动态关键字，它允许在必要时以一般静态语言进行鸭式输入。

同样，反射可以做到这一点，但它相对难看。

.11. 由于 Java 主要是一种 VM 语言，因此可能有一些核心元编程功能，例如为某些事情动态生成代码。

像 JavaCompiler（在 java 6 中）、脚本支持（在 java 6 中）、JCI 或 BeanShell。

于 2009-01-27T20:20:24.183 回答
4

如果你要做出重大改变，你不想重新开始吗？在 Java 中修复/删除可以做很多事情。你不能单独考虑特性——它们确实以意想不到的方式交互。一种大而复杂的语言可能是一种糟糕的语言（参见 C++）。

于 2009-01-27T16:56:53.530 回答
4

Java++已经在这里了... :D

于 2010-01-12T04:51:51.200 回答
3

那些东西大多是绒毛。

您需要解决一些更大的问题，例如使并发代码易于设计和推理。

于 2009-01-27T17:57:36.730 回答
3

大多数功能已经存在。

该语言是：

时髦的
（来源：codehaus.org）

=

至于：

在一个文件中声明多个类的能力。

它从一开始就存在于java中。

于 2009-01-27T18:04:08.543 回答
3

这些似乎都是相当“肤浅”的语言变化，主要是出于开发者的便利性，而不是从根本上改变了语言哲学。

在我看来，对语法的细微调整并不能证明大规模转向新语言的合理性，特别是如果这意味着放弃对平台、代码库和开发人员技能集的大量投资。

如果有足够的需求，可以随着时间的推移（在 Java 7、8、9...中）将微小的更改添加到 Java 语言中。然而，关于它们是否合理存在一个真正的问题，因为像这样的变化会使语言变得更加复杂，因此随着不同的开发人员开始使用不同的特性子集，学习和维护代码库变得更加困难。

以 C++ 为例：理论上它是一种了不起的语言，允许您在任何可能的抽象级别进行编程，同时仍然允许优化代码中的机器代码级别的性能。在实践中，所有这些语言功能的复杂性意味着很少有人能够希望了解真正发生的事情，并且大型代码库变得几乎无法维护。

在我看来，唯一可以证明大规模“Java++”合理的变化将是根本性的范式转变，它会改变您更好地开发软件的方式。在我看来，使 Java 取得成功的根本变化（在 1995-2000 年超过了 C++ 等）：

  • 在可移植、标准、跨平台运行时环境 (JVM/JRE) 中执行字节码，无需重新编译
  • 一个大型、健壮的标准类库（包括线程、网络、GUI 等）——即认识到平台不仅仅是语言
  • 强制收集垃圾

下一阶段基本转变的例子是：

哦，是的，有一种 JVM 语言可以完成所有这些工作 - Clojure

于 2011-02-20T13:59:19.337 回答
2

Sun 所做的这种努力难道不应该简单地称为 Java 7（或 1.7 或 2.0）吗？其他人/团体的这种努力不会被称为Java以外的东西吗？

于 2009-01-27T16:50:55.320 回答
2

如果您将这些结构的支持添加到 JVM（在必要时，例如闭包），然后在书面语言和编译器中创建必要的语法糖。当然，如果您希望保持向后兼容性，那么您需要做出设计决策，这就是 Java 泛型没有达到应有的水平的原因。我认为你会想要摆脱这种束缚以获得更完美的 Java，但需求会很少，因为兼容性就是它的所在。

而7可以直接走。我们在这里没有遇到软盘上的 FAT12 文件限制。

于 2009-01-27T17:04:25.683 回答
1

随着 java 正在成为开源，您可以获取源代码（如果全部可用）并制作您自己的 java 版本。如果这得到广泛采用，那就太好了，如果没有，那么它可能不需要一组功能。

于 2009-01-27T19:04:54.677 回答
1

Java 可以而且应该改进，但我认为不需要一种语言来满足所有需求。这通常是一个坏主意，就像死星一样。

很多程序员只是懒惰，不想学习新东西。他们宁愿坚持使用过去 10 年一直使用的一种语言。

如果您需要速度和对硬件的更多控制，您可以使用 C 之类的东西。如果您需要系统管理任务，您可能最终会使用 shell 脚本或 perl、python 或 ruby​​ 等脚本语言。如果你做很多数学特定的东西，Matlab 是一个不错的选择。等等。

使用最好的工具来完成任务，无论它是什么语言。一个好的程序员应该能够使用任何语言（至于我，我仍在努力）。

于 2009-01-27T19:30:37.543 回答
1

我建议看看Beyond Java。

Joel on Software有一篇很好的评论。

于 2009-01-28T08:03:55.727 回答
0

查看 Java 7 上可用的信息。我想您会发现它计划添加每个人都要求的几个特性，最值得注意的是闭包。

于 2009-01-27T16:51:16.880 回答
0

实际上，我真的同意您的观点，遇到了可以通过您的建议缓解的 Java 问题。

原则上，您可以编写自己的 javac 并使用现有的 Hotspot JRE。但是，如果没有 Sun 的帮助，您真的无法做到这一点。

问题实际上是双重的：1）Sun 的方法是支持“Java 平台”并且抵制新标准，甚至是超集；2）要对 Java 进行任何更改，您必须发布 JSR——而且通常需要企业赞助。公司往往有其他优先事项。

再说一次，我会敦促你推动它。毕竟，直到 2007 年，许多聪明人几乎从头开始重新制作 Java = GNU 类路径。所以就有了“二等JVM语言”的必备人才。

于 2009-01-28T05:57:55.717 回答
0

尽管我确实觉得 Java 已经过时了，但事实是，我认为我们都知道它作为一种语言仍然运行良好。当然，我们可以在其他语言中找到的许多更新的东西都不存在，但它仍然有效！你仍然可以做任何事情，只是有时需要更长的时间和更多的工作。我绝对期待它被取代的那一天，但我只是认为，对于所有用 Java 编写的现有代码和应用程​​序，目前没有办法，（几乎）没有人会转向 Java++。我认为我们正在等待真正的范式转变，就像 C++ 到 C 一样。也许函数式编程可能是下一个大事件，而 Scala 将是下一个 Java。

于 2009-01-28T08:30:49.247 回答
-1

C++ 是面向对象的 C。Java 已经是面向对象的，那么我们将如何进行另一个范式转换，使其成为 Java++？

在某种程度上，我认为情况正好相反。Java 远远领先于 C++。Java 具有高级库和框架，而 C++ 通常仍然是低级的并且与 ansi C 混合（因为我们可以）。

Java 有很好的单元测试可能性，以及都指向同一个方向的大型社区。

拥有更多“功能”并不会使语言变得更好。我认为有可能使情况变得更糟。

最后，将一种语言“放在”另一种语言之前并没有帮助。为工作选择最佳工具。我认为 Java 作为一门语言是相当不错的。然而，C++ 可以使用一些更好的库，例如 Spring 的一个端口。

于 2009-01-27T20:40:03.003 回答