我最近花了几年时间把遗留的FORTRAN代码翻译成Java。在此之前，我发现自己不得不将FORTRAN翻译成C（为此，我编写了一个简单的翻译工具）。经过所有这些工作，我想知道有多少其他人正在进行类似的语言到语言的翻译工作，是否自动化的方式会有益。
我了解F2C、For_C、F2J等等，以及一些翻译网站，但似乎没有一个非常成功。从For_C的输出结果来看，我可以理解为什么它没有起飞。虽然技术上是正确的，但很难维护。
所以，我想知道如果有一种工具可以产生比我看到的代码更易于维护、更易懂的代码，开发人员会使用它吗？还是像许多帖子所表明的那样，开发人员变得麻木不仁，不愿意使用生成的代码，因为它永远无法像手动翻译的代码那样好？
这个问题在Fortran 77代码转换为C ++中已经有所涉及，但我会在这里尝试一下。
我认为将遗留代码翻译成新语言是浪费大量时间和精力的。这需要极大的时间和精力，并且在这样做时会引入新的错误。
Joel在永远不要做的事情第一部分中提到了为什么从头开始重写是一个可怕的想法，虽然我意识到将某些东西翻译成新语言并不完全等同于从头开始重写，但我认为它们足够接近：
自动翻译工具并不理想，因为它们无法生成可维护的代码。你几乎必须了解旧代码才能理解新代码，那样你又得到了什么呢？对于Fortran来说，我现在工作的地方有数百万行遗留的Fortran代码，没有人会重写它。风险太大了。旧的漏洞必须重新修复，而且已经花费了数百年的时间来解决数学问题。没有人想引入这些类型的漏洞，这可能是非常不安全的。
我们采用混合代码而不是移植。毕竟，你可以链接Fortran和C/C++，如果你在你的Fortran代码周围创建一个C接口，你可以从Java中调用它。现代代码中有C/C++组件，可以调用旧的Fortran例程，如果你这样做，你还可以获得额外的好处，因为Fortran编译器非常快，所以旧代码继续以最快的速度运行。
我认为处理这个问题的最佳方式是逐步进行任何需要移植的工作。在你的旧Fortran代码周围创建一个轻量级接口并调用所需的部分，但只在新部分需要时移植它们。还有一些组件框架可以集成多语言应用程序，使这个过程更容易，但你可以查看将Fortran 77代码转换成C ++了解更多信息。
由于编程很难，因此不存在这样的工具。
如果将一种语言转换为另一种语言是微不足道的，那么“编译器”的概念就没有意义了。你只需要将你喜欢的语言映射到硬件的语言中，按下按钮就可以完成。
然而，事情从来都没有那么简单。每个虚拟机、每种语言、每个 API 库都会添加一些细微差别，这些差别是无法自动化的。
“我能理解为什么它没有流行起来。虽然技术上是正确的，但很难维护。”
对于 F2C 和 Fortran 到机器语言也是正确的。大多数编译器生成的目标代码不能轻松地被人读取。它要么很糟糕，要么高度优化。无论哪种方式，它看起来都不像一个专家人类为该硬件编写汇编语言的样子。
如果只能将编译简化为类似 XSLT 的转换，以保留旧语言在新语言中的清晰度。如果只有一种计算机的通用“通用语言”，它将成为编程的罗塞塔石碑。
除非有人发明了计算机的这种“通用语言”，否则每个语言翻译工作都将很难，并且会导致在新语言中“难以维护”的代码。
