java - "language converters"的经验？

Question

我读过几篇提到从一种语言到另一种语言的转换器的文章。

我对使用这种工具有点怀疑。有没有人知道或有经验让我们谈谈 Visual Basic 到 Java 或 vs 转换器？仅举一个例子

http://www.tvobjects.com/products/products.html ，声称是这方面的“世界领导者”左右，但是如果阅读此内容:

http://dev.mysql.com/tech-resources/articles/active-grid.html

作者在那里说:

“MySQL 用户的共识是 MS Access 的自动转换工具不起作用。例如，将现有 Access 应用程序转换为 Java 的工具通常会产生 80% 的完整解决方案，其中完成最后 20% 的工作比从开始需要更长的时间划痕。”

我们知道我们需要 80% 的时间来实现前 80% 的功能，另外 80% 的时间用于其他 20%....

那么有没有人尝试过这样的工具并发现它们值得？

Answer 1

试过了？不，实际上构建了(不止一个)语言转换器。

这是我(和我的同事)为 B2 Spirit Stealth Bomber 构建的一个将使用传统语言 JOVIAL 编码的任务软件转换为可维护的 C 代码，并实现 100% 的自动转换。要求之一是不允许我们看到实际的源代码。不是开玩笑。

您是对的:如果您只获得中等高的转化率(例如 70-80%)，那么完成转化的努力仍然非常重要，如果您确实可以做到的话。我们的目标是 95% 以上，当被告知要更加努力时，我们会做得更好，就像 B2 的情况一样。人们接受中高速转换器的唯一原因是他们找不到(或不会资助!)更好的转换器，坚持现在开始，并接受这样的转换可能会很痛苦的事实(通常他们不会)不知道多少)但实际上比从头重建它更痛苦。 (我碰巧同意这个评估:一般来说，尝试从头开始重新编码大型系统的项目通常会失败，而使用中高转换率工具进行的转换没有那么高的失败率。)

那里有很多糟糕的转换工具，一些东西与大量 PERL 代码对文本字符串执行正则表达式，或者一些基于 YACC 的解析器，其代码生成基本上是一对一的，用于编译单元中的每个语句。前者是由从天而降的皈依者 build 的。后者通常由没有良好编译器背景的善意工程师构建。

对于一个非常糟糕的例子，请参阅我对这个关于 COBOL 迁移的 SO 问题的回答:Experience migrating legacy Cobol/PL1 to Java ，这正是一个直接的语句翻译器......产生了产生术语“JOBOL”的东西。

要获得如此高精度的转换率，您需要高质量的解析器，以及构建高质量翻译规则的方法，这些规则保留语义，并针对目标语言属性和特殊情况进行优化。本质上，您需要可配置的编译器技术。恕我直言，我们成功的原因是我们的 DMS Software Reengineering Toolkit ，旨在完成这项工作。 (我是建筑师；查看我的 SO 图标/生物)。

许多仔细的测试也有帮助。

DMS“知道”编译器对代码的了解，因为它为感兴趣的语言提供类似编译器的前端，并且能够构建 AST、符号表、控制和数据流、调用图。它使用了编译器社区在过去半个世纪中发明的大部分编译器技术，因为这些东西已被证明在翻译中很有用!

DMS 比大多数编译器知道的更多，因为它可以一次读取/分析/转换整个应用程序；大多数编译器坚持使用单个编译单元。因此，可以编写依赖于整个应用程序而不是仅依赖于当前语句的翻译规则。我们经常添加特定于问题或应用程序的知识来改进翻译。这通常出现在转换语言的特殊功能或调用库时，人们必须将库调用识别为特殊习语，并将它们转换为对目标库和语言结构组合的调用。

此功能用于构建翻译器(例如，JOVIAL 翻译器)或特定于域的代码生成器。

更多的时候，我们构建复杂的自动化软件工程工具来解决特定于客户的问题，例如程序分析工具(死代码、重复代码、风格损坏的代码、度量、架构提取等)和大规模变更工具(平台 [...]不是语言] 迁移、数据层插入、API 替换，...​​)