每当一种新的编程语言变得流行起来，它的粉丝们就会通过到现有的项目中提交像这样的 bug 报告来开始传播新编程语言的优势。
嗨，我注意到这个项目是用[编程语言X]编写的,你真的应该用[编程语言Y]重写它，因为它在[某些功能Z]更好 . 网络语言!
如果真按说的这样来做，则似乎会显得这个人没有脑子。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行代码。
