我去过构建工具（DMS 软件重组工具包） http://www.semanticdesigns.com/Products/DMS/DMSToolkit.html自 1995 年以来，在强大的计算机科学家团队的支持下，进行通用程序操作（语言翻译是一个特例）。 DMS 提供通用解析、AST 构建、符号表、控制和数据流分析、翻译规则的应用、带注释的源文本重新生成等，所有这些都通过计算机语言的显式定义进行参数化。
完成此操作所需的机械数量well是巨大的（特别是如果您希望能够以通用方式对多种语言执行此操作），然后您需要可靠的解析器来处理具有不可靠定义的语言（PHP 就是一个完美的例子）。
你考虑构建一个语言到语言的翻译器或尝试它并没有什么问题，但我认为你会发现对于真正的语言来说这是一个比你预期的更大的任务。我们仅在 DMS 上就投入了约 100 个人年，在每种“可靠”语言定义（包括我们为 PHP 辛苦构建的语言定义）上又投入了 6-12 个月的时间，对于 C++ 等讨厌的语言则投入更多。这将是一次“地狱般的学习经历”；这对我们来说是好事。 （您可能会发现上述网站上的技术论文部分对于快速开始学习很有趣）。
人们经常尝试从他们熟悉的某些技术开始构建某种通用机械，这些技术可以完成部分工作。 （Python AST 就是一个很好的例子）。好消息是部分工作已经完成。坏消息是，机器内置了无数的假设，其中大部分假设只有在你尝试让它做其他事情时才会发现。那时你会发现这台机器是用来做它最初做的事情的，并且会非常非常抵制你让它做其他事情的尝试。 （我怀疑尝试使用 Python AST 来建模 PHP 将会很有趣）。
我最初开始构建 DMS 的原因是为了构建很少内置此类假设的基础。它有一些让我们头疼的问题。到目前为止，还没有黑洞。 （过去 15 年我工作中最困难的部分就是努力防止此类假设的蔓延）。
许多人还错误地认为，如果他们能够解析（并且可能获得 AST），他们就可以很好地完成一些复杂的事情。惨痛的教训之一是您需要符号表和流程分析来进行良好的程序分析或转换。 AST 是必要的，但还不够。这就是 Aho&Ullman 的编译器书没有停在第 2 章的原因。（OP 拥有这项权利，因为他计划在 AST 之外构建额外的机制）。有关此主题的更多信息，请参阅解析后的生活 http://www.semanticdesigns.com/Products/DMS/LifeAfterParsing.html.
“我不需要完美的翻译”这句话很麻烦。弱翻译者所做的就是转换“简单”的 80% 代码，而将困难的 20% 留给手工完成。如果您打算转换的应用程序非常小，并且您只想将其转换一次，那么 20% 就可以了。如果您想要转换许多应用程序（甚至是同一个应用程序，随着时间的推移进行微小的更改），这并不好。如果您尝试转换 100K SLOC，那么 20% 就是 20,000 行原始代码，这些代码在您已经不理解的另外 80,000 行翻译程序的上下文中很难翻译、理解和修改。这需要付出巨大的努力。在百万行级别，这在实践中根本是不可能的。 （令人惊讶的是，有些人不信任自动化工具并坚持手动翻译百万行系统；这甚至harder他们通常会因为长时间的延误、高昂的成本和经常的彻底失败而痛苦地发现。）
翻译大型系统必须追求百分之九十的高转化率，否则您可能无法完成翻译活动的手动部分。
另一个关键考虑因素是要翻译的代码的大小。即使使用良好的工具，构建一个可用的、强大的翻译器也需要花费大量的精力。虽然构建一个翻译器而不是简单地进行手动转换似乎很性感且很酷，但对于小型代码库（例如，根据我们的经验，最多约 100K SLOC），从经济角度来看根本不合理。没有人喜欢这个答案，但如果你真的只需要翻译 10K SLOC 代码，那么你最好还是硬着头皮去做。是的，这很痛苦。
我认为我们的工具非常好（但是，我有很大的偏见）。而培养一名优秀的翻译人员仍然非常困难；我们大约需要 1.5-2 人年的时间，并且我们知道如何使用我们的工具。不同的是，有了这么多机器，我们succeed http://www.semdesigns.com/Products/Services/NorthropGrummanB2.html比我们失败的次数要多得多。
