为什么你不用某某更现代化的语言重写所有代码

最近Gnome相关软件项目用到的 工具 正在进行转换运动，将 shell 、Awk、 Perl 编写的大杂烩转成 Python 3代码。主要原因是，唯一的“脚本”依赖于现代的、维护良好的项目，可以简化使用Gnome技术在诸如Windows的平台上编译应用程序的过程，在项目之间切换也更加容易。

GTK-doc 就是一个正在转换中的工具，它是主要用Perl编写的文档生成工具。我跟上游团队一起将他转成Python 3。从很多方面讲，这是个具有教育意义的体验。首先学到的是，在两种语言间转换通常可以分为三个独立的阶段。

1. 手动语法转换

2. 修复转换错误导致的bug

3. 将代码转换成目标语言惯用的方式

对gtk-doc来说，从Perl到Python的转换相对简单。因为主要处理的是正则表达式、数组、字典，这三者在两种语言中基本相同，所以步骤一主要是体力活。步骤二包含修复步骤一引入的bug和行为变化（behavioural changes，多数由于步骤一的拼写、粗心导致的问题）。这个阶段主要是调试。步骤三是将正则表达式、全局变量转成对象、其他合理并可读的结构。

现在是真正悲伤的一部分。这种转换速度是不可持续的。将代码从一种格式手动转换为另一种格式是你难以想象的最无聊的、耗费精力的和怀疑人生的工作。我每天最多只能做几个小时，然后我就不得不停下来，因为我能看到的只是一大堆美元符号、分号和大括号。基于此，我们可以估计，一个人可以维持的持续转换率是每小时大约100行代码（如果项目持续了几个星期，那么这个速度是不可能持久的，但由于没有实际度量，让我们先忽略它）。

根据Ohloh统计，cURL项目包括大约10万行的C代码。如果我们假设将其转换为其他一些语言就像简单的Perl转换为Python一样简单（这似乎不太可能），转换将需要1000个小时。每天8小时，大约5个月的全职工作。一旦完成这些，你还需要将所有在trunk中进行的更改都移植完，毕竟你揽上这活儿了。将整个项目从一种语言转换到另一种语言不是一个合适的选择。

这给了我们一个明确的针对为什么人们不只是将他们的项目从一种语言转换到另一种语言的解释：

这并不存在所谓的“简单使用X语言重写之”。