自1995年以来，我一直在构建工具（DMS Software Reengineering Toolkit）来进行通用程序操作（语言翻译是一个特例），并得到了一个强大的计算机科学家团队的支持。DMS提供通用解析，AST构建，符号表，控制和数据流分析，翻译规则的应用，带有注释的源文本的再生等，所有这些都通过计算机语言的明确定义进行参数化。
你需要做这个的机器数量是巨大的（特别是如果你想能够以一般的方式为多种语言做到这一点），然后你需要可靠的解析器来解析定义不可靠的语言（PHP就是一个很好的例子）。
你考虑建立一个语言到语言的翻译器或尝试它没有错，但我认为你会发现，对于真正的语言来说，这是一项比你预期的要大得多的任务。我们仅在DMS上投入了大约100个人年，在每个“可靠”语言定义（包括我们为PHP痛苦地构建的语言定义）中还有6-12个月，对于C++等令人讨厌的语言，则更多。这将是一次“地狱般的学习经历”;它一直适合我们。（您可能会发现上述网站上的技术论文部分很有趣，可以快速开始学习）。
人们经常试图通过从他们熟悉的一些技术开始来构建某种通用的机器，这些技术可以完成一部分工作。（Python AST就是很好的例子）。好消息是，部分工作已经完成。坏消息是，机器内置了无数的假设，其中大部分你都不会发现，直到你试图把它变成做别的事情。在这一点上，你发现机器被连接到做它最初做的事情，并且会真正，真正地抵制你让它做其他事情的尝试。（我怀疑尝试让Python AST对PHP进行建模会很有趣）。
我最初开始构建DMS的原因是构建很少内置此类假设的基础。它有一些让我们头疼的问题。到目前为止，还没有黑洞。（在过去的15年里，我工作中最困难的部分是试图防止这种假设悄悄进入）。
很多人也犯了一个错误，认为如果他们能够解析（也许得到AST），他们就可以很好地做一些复杂的事情。其中一个难教训是，您需要符号表和流分析来进行良好的程序分析或转换。AST是必要的，但还不够。这就是为什么Aho&Ullman的编译器书没有停在第2章的原因。（OP有这个权利，因为他计划在AST之外建造更多的机器）。有关此主题的详细信息，请参阅解析后的生命周期。
关于“我不需要完美的翻译”的评论很麻烦。弱翻译者所做的是转换“简单”的80%的代码，而将困难的20%留给手工完成。如果您打算转换的应用程序非常小，并且您只打算转换一次，那么20%是可以的。如果您想转换许多应用程序（甚至是随时间变化而发生微小变化的应用程序），这并不好。如果您尝试转换100K SLOC，那么20%是20，000行原始代码行，这些代码在另外80，000行您已经不理解的已翻译程序的上下文中难以翻译，理解和修改。这需要付出巨大的努力。在百万线水平上，这在实践中根本不可能。（令人惊讶的是，有些人不信任自动化工具，坚持手工翻译数百万行系统;这更难，他们通常会痛苦地发现长时间的延迟，高成本和经常彻底的失败。
要翻译大型系统，您必须追求的是高九十年代的转化率，或者您可能无法完成翻译活动的手动部分。
另一个关键考虑因素是要翻译的代码的大小。即使使用良好的工具，构建一个工作强大且强大的翻译器也需要花费大量精力。虽然构建一个转换器而不是简单地进行手动转换似乎既性感又酷，但对于小型代码库（例如，在我们的经验中，高达大约100K SLOC），经济学根本无法证明这一点。没有人喜欢这个答案，但如果你真的只需要翻译10K SLOC的代码，你可能最好咬紧牙关去做。是的，这很痛苦。
我认为我们的工具非常好（但是，我非常有偏见）。而且要培养一个好的译者还是很难的。这需要我们大约1.5-2人年，我们知道如何使用我们的工具。不同之处在于，有了这么多的机器，我们成功的频率要比失败的次数高得多。
