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

2017-06-12 1252 1 編輯:深圳網站建設 來源:互聯網

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

專業的網站建設公司,深正互聯,如您有網站營銷需求,請您關注我們,或者致電13828884598

本站文章均為深正網站建設摘自權威資料,書籍,或網絡原創文章,如有版權糾紛或者違規問題,請即刻聯系我們刪除,我們歡迎您分享,引用和轉載,但謝絕直接搬磚和抄襲!感謝...
關注深正互聯
七星彩头尾