“语言转换器”的经验？

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的情况一样。人们接受中等高速率转换器的唯一原因是因为他们找不到（或不会资助！）更好的转换器，坚持启动 now ，并接受以这种方式转换它的事实可能痛苦（通常他们不知道多少），但实际上比从头重建它更痛苦。 （我恰好同意这种评估：一般来说，尝试从头开始重新编码大型系统的项目通常会失败，使用中高转换率工具的转换不会有很高的失败率。）

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

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

要获得如此高精度的转换率，您需要高质量的解析器，并且需要构建保留语义的高质量转换规则，并针对目标语言属性和特殊情况进行优化。从本质上讲，您需要的是可配置的编译器技术。我们成功的原因，恕我直言，是我们的DMS Software Reengineering Toolkit，它是为了完成这项工作而设计的。 （我是建筑师;看看我的SO图标/生物）。

许多仔细测试也有帮助。

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

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

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

我们经常构建复杂的自动化软件工程工具来解决客户特有的问题，例如程序分析工具（死代码，重复代码，样式代码，指标，架构提取......）和批量更改工具（平台[not langauge]迁移，数据层插入，API替换，...​​）

Answer 2

Answer 3

影响跨语言转换成功或失败的几个问题是语言的相对语义丰富性及其语义模型。

• 从C ++到C的翻译应该相对简单，但是将C语言翻译成惯用语 C ++几乎是不可能的，因为几乎不可能将程序性程序自动转换为OO计划。

• 将Java转换为C会相对简单，但处理存储管理会很混乱。如果C程序执行时髦的指针算法或在整数和不同类型的指针之间进行转换，那么将C转换为Java几乎是不可能的。

• 将功能语言翻译成命令式语言会很容易，尽管结果可能效率低下，非惯用语。将命令式语言翻译成函数式语言可能超出了现有技术水平....除非你在函数式语言中实现命令式语言的解释器。

这意味着一些翻译人员必然在以下方面比其他人更成功：

• 翻译的完整性和准确性，
• 生成的代码的可读性和可维护性。

Answer 4

Joel Spolsky的

Things You Should Never Do, Part I

“......他们通过制造任何软件公司可能犯下的最严重的战略错误来做到这一点：

他们决定从头开始重写代码。“

我有list of MS Access converters on my website。在我每天阅读的Access相关新闻组中的任何帖子中，我从来没有听说过任何关于它们的任何好消息。我每天都会阅读很多帖子。

另请注意，Access中有大量功能，例如绑定的连续表单或子表单，这是在其他系统中重现的更多工作。不一定是很多工作，但更多的工作。分发和安装应用程序时会遇到更多麻烦。

Answer 5

我使用了从C＃到Visual Basic.NET的自动转换器。除了添加一些不必要的If True语句之外，它的效果非常好。

我也尝试使用Shed Skin转换Python-to-C ++，但由于缺乏对新式划分的支持而无法正常工作。

Answer 6

我已经使用工具将VB6项目转换为VB.Net - 您希望这可能是这类事情中较为简单的例子之一。我的经验是，所有东西都必须经过详细检查，而且有一半的东西丢失/错误。

当然，我会建议手动迁移，或者根据您所针对的语言，如果能让您有机会对代码库进行重大改进，我会考虑完全重写。

马丁

Answer 7

我只试过免费且基本付费的转换器。但主要问题是很难确信转换完全成功。

通常，它们最常用于手动转换代码部分，您可以在其中查看每段代码。通常根据我的经验，重写而不是转换是更好的选择。