為什麼你不用更好的編程語言重寫它

每當一種新的編程語言變得流行起來，它的粉絲們就會通過到現有的項目中提交像這樣的 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行代碼。

現在是真正悲傷的一部分。這種轉換速度是不可持續的。將代碼從一種格式手動轉換為另一種格式是你難以想像的最無聊的、耗費精力的和懷疑人生的工作。我每天最多只能做幾個小時，然後我就不得不停下來，因為我能看到的只是一大堆美元符號、分號和大括弧。基於此，我們可以估計，一個人可以維持的持續轉換率是每小時大約100行代碼（如果項目持續了幾個星期，那麼這個速度是不可能持久的，但由於沒有實際度量，讓我們先忽略它）。

根據Ohloh統計，cURL項目包括大約10萬行的C代碼。如果我們假設將其轉換為其他一些語言就像簡單的Perl轉換為Python一樣簡單（這似乎不太可能），轉換將需要1000個小時。每天8小時，大約5個月的全職工作。一旦完成這些，你還需要將所有在trunk中進行的更改都移植完，畢竟你攬上這活兒了。將整個項目從一種語言轉換到另一種語言不是一個合適的選擇。

這給了我們一個明確的針對為什麼人們不只是將他們的項目從一種語言轉換到另一種語言的解釋：

這並不存在所謂的「簡單使用X語言重寫之」。

結束語

有一些工具可以自動從一種語言轉換為另一種語言。 他們可以幫助解決一些問題，但只能停留在第一步。 第二步和第三步的問題仍然存在，並且可能需要比手動轉換代碼帶來更多的工作，因為通常手動轉換會寫出更多的人性化的代碼。 令人遺憾的是圖靈完備向我們揭示了不能有十全十美的事情。

作者：Tony, Tocy, douxingxiang

譯文：https://www.oschina.net/translate/why-dont-you-just-rewrite-it-in-x

原文：http://nibblestew.blogspot.jp/2017/04/why-dont-you-just-rewrite-it-in-x.html

--- 廣告----

點擊展開全文

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！