每当一种新的编程语言变得流行起来，它的粉丝们就会通过到现有的项目中提交像这样的 bug 报告来开始传播新编程语言的优势。
如果真按说的这样来做，则似乎会显得这个人没有脑子。Y语言在Z功能上是更有优势，那么真的应该让每个人都将他们的项目都转向Y语言来开发么。
最近Gnome相关软件项目用到的工具正在进行转换运动，将shell、Awk、Perl编写的大杂烩转成Python3代码。主要原因是，唯一的“脚本”依赖于现代的、维护良好的项目，可以简化使用Gnome技术在诸如Windows的平台上编译应用程序的过程，在项目之间切换也更加容易。
GTK-doc就是一个正在转换中的工具，它是主要用Perl编写的文档生成工具。我跟上游团队一起将他转成Python 3。从很多方面讲，这是个具有教育意义的体验。首先学到的是，在两种语言间转换通常可以分为三个独立的阶段。
1.手动语法转换
2.修复转换错误导致的bug
3.将代码转换成目标语言惯用的方式
对gtk-doc来说，从Perl到Python的转换相对简单。因为主要处理的是正则表达式、数组、字典，这三者在两种语言中基本相同，所以步骤一主要是体力活。步骤二包含修复步骤一引入的bug和行为变化（behavioural changes，多数由于步骤一的拼写、粗心导致的问题）。这个阶段主要是调试。步骤三是将正则表达式、全局变量转成对象、其他合理并可读的结构。
在进行转换时，我一直主要在关注第一步，因为gtk-doc维护者已经证实过步骤二和三了。在转换6000多行gtkdoc-mkdb文件时，我做了一些测量，结果是我可以以每小时500行的峰值速度进行转换，意思是每行代码大约需要7秒。
这只是在易于转换的代码上能达到的，并且基本上是Emacs原型中的一个练习。每一行“花哨”的Perl 代码，转换时都需要10x、100x、甚至高达1000x的时间。如果迁移需要架构返工（比如，这在将编译器中一个宽松的语言转换为编译过程具有生命周期检查的语言时是会发生的），这种情况下转换会更慢。
我不知道有多少工作需要在步骤2和3中完成，但是根据某些IRC频道发表的评论，可能有相当多的事情。让我们乐观估计下，总的来说经过完整的三步，每小时可以转化250行代码。
现在是真正悲伤的一部分。这种转换速度是不可持续的。将代码从一种格式手动转换为另一种格式是你难以想象的最无聊的、耗费精力的和怀疑人生的工作。我每天最多只能做几个小时，然后我就不得不停下来，因为我能看到的只是一大堆美元符号、分号和大括号。基于此，我们可以估计，一个人可以维持的持续转换率是每小时大约100行代码（如果项目持续了几个星期，那么这个速度是不可能持久的，但由于没有实际度量，让我们先忽略它）。
根据Ohloh统计，cURL项目包括大约10万行的C代码。如果我们假设将其转换为其他一些语言就像简单的Perl转换为Python一样简单（这似乎不太可能），转换将需要1000个小时。每天8小时，大约5个月的全职工作。一旦完成这些，你还需要将所有在trunk中进行的更改都移植完，毕竟你揽上这活儿了。将整个项目从一种语言转换到另一种语言不是一个合适的选择。
这给了我们一个明确的针对为什么人们不只是将他们的项目从一种语言转换到另一种语言的解释：
这并不存在所谓的“简单使用X语言重写之”。
结束语
有一些工具可以自动从一种语言转换为另一种语言。 他们可以帮助解决一些问题，但只能停留在第一步。 第二步和第三步的问题仍然存在，并且可能需要比手动转换代码带来更多的工作，因为通常手动转换会写出更多的人性化的代码。 令人遗憾的是图灵完备向我们揭示了不能有十全十美的事情。
文章转载自 开源中国社区[https://www.oschina.net]
