水星探索項(xiàng)目中一段Fortran代碼里的逗號(hào)被寫(xiě)成了點(diǎn)號(hào)，影響了運(yùn)算的準(zhǔn)確性，導(dǎo)致太空探測(cè)器無(wú)法到達(dá)更遠(yuǎn)的軌道。出現(xiàn)這種事情的幾率有多大？一種編程語(yǔ)言的設(shè)計(jì)在多大程度上會(huì)影響程序正確性和導(dǎo)致相似的事件？最近發(fā)表在第四屆International Workshop on Evaluation and Usability of Programming Languages and Tools上的一篇論文中，我展示了一些研究發(fā)現(xiàn)：通過(guò)往由各種不同語(yǔ)言編寫(xiě)的類似程序中隨機(jī)的制造一些干擾信息，看編譯器或運(yùn)行系統(tǒng)能否發(fā)現(xiàn)由這些干擾引起的錯(cuò)誤，或者最終導(dǎo)致了程序輸出了錯(cuò)誤的結(jié)果。
在由我和我的同事 Vassilios Karakoidas、Panagiotis Louridas共同指導(dǎo)的這項(xiàng)研究中，我們首先選擇了10中流行的編程語(yǔ)言，以及用它們寫(xiě)出的一批程序。我們選擇這些語(yǔ)言的條件是基于一篇IEEE Spectrum文章里提供的數(shù)據(jù)(由軟件研究公司TIOBE建立的一個(gè)索引目錄)、出現(xiàn)在Powell’s Books書(shū)名中的數(shù)量、IRC在線討論中引用的數(shù)量，以及Craigslist中招聘職位的數(shù)量。在這樣一個(gè)流行語(yǔ)言的大集合中，由于一些可操作性的原因，部分語(yǔ)言被排除在外。根據(jù)流行度索引，這個(gè)集合大概能覆蓋所有語(yǔ)言的71%到86%。
然后我們從Rosetta Code wiki中尋找我們研究的這10種語(yǔ)言寫(xiě)成的執(zhí)行相同任務(wù)的各種源代碼。用Rosetta Code這個(gè)網(wǎng)站的創(chuàng)辦人自己的話，這個(gè)網(wǎng)站的目的就是搜集用不用的各種語(yǔ)言來(lái)完成同一種任務(wù)的代碼，展示它們的相似和不同，幫助那些研究基礎(chǔ)工作的人了解問(wèn)題的另一種解決方案。
我們的下一步是要制造一個(gè)代碼干擾器：一個(gè)能系統(tǒng)的往代碼里隨機(jī)引入各種隨機(jī)混亂的工具。干擾器能替換標(biāo)志符，把一些數(shù)字加一，隨機(jī)改變字符或把字符串替換成相似的東西或隨機(jī)的串。最后，我們把干擾器應(yīng)用到我們搜集的代碼里，檢查這些被修改后有錯(cuò)誤的代碼是否能被編譯器或運(yùn)行環(huán)境檢測(cè)到，或是否導(dǎo)致了錯(cuò)誤的輸出。
理論上，我們?nèi)斯ひ氲倪@些錯(cuò)誤是模擬現(xiàn)實(shí)生活中的很多具體表現(xiàn)。錯(cuò)誤拼寫(xiě)——“胖手指”——就是一個(gè)很常見(jiàn)的例子。另外的場(chǎng)景包括馬虎大意，自動(dòng)重構(gòu)錯(cuò)誤(特別是在像C和C++這些語(yǔ)言里，自動(dòng)重構(gòu)是很難正確無(wú)誤的實(shí)現(xiàn)的)，復(fù)雜的編輯器命令導(dǎo)致的意外失誤，或搜索-替換操作造成的錯(cuò)誤，甚至還包括貓踩著鍵盤(pán)上產(chǎn)生的后果。
總計(jì)我們一共測(cè)試了136個(gè)任務(wù)實(shí)現(xiàn)，嘗試了2萬(wàn)8千種干擾操作，其中成功的有261,667 (93%)個(gè)。被干擾的程序中有90,166 (32%)個(gè)編譯通過(guò)或語(yǔ)法上沒(méi)有發(fā)現(xiàn)異常。60,126 (67%, 或 總共被干擾的數(shù)量的23%)個(gè)能正常的結(jié)束運(yùn)行。 18,256個(gè)輸出了完全無(wú)異的結(jié)果，表明干擾沒(méi)有對(duì)程序產(chǎn)生任何影響。其余的，41,870 個(gè)程序 (能運(yùn)行的70%, 總數(shù)的16%)編譯和運(yùn)行都沒(méi)有問(wèn)題，但輸出了結(jié)果錯(cuò)誤。
上圖顯示了對(duì)各種語(yǔ)言的統(tǒng)計(jì)結(jié)果，是按失敗情況統(tǒng)計(jì)：成功的編譯或執(zhí)行，沒(méi)有捕獲程序中的錯(cuò)誤，導(dǎo)致輸出了錯(cuò)誤的結(jié)果。上圖驗(yàn)證了我們一些非常直覺(jué)的看法。強(qiáng)靜態(tài)類型語(yǔ)言(Java, Haskell, C++)比那些弱的或動(dòng)態(tài)類型語(yǔ)言(Ruby, Python, Perl, PHP, 和 JavaScript)能在編譯器捕獲更多的錯(cuò)誤。稍微有點(diǎn)意外的是，C語(yǔ)言出現(xiàn)在了中間位置，驗(yàn)證了一個(gè)被很多人相信的觀點(diǎn)：C語(yǔ)言的類型系統(tǒng)并不像它的眾多追隨者(包括我)認(rèn)為的那樣強(qiáng)。然而，C語(yǔ)言在運(yùn)行期卻拋出了大量的錯(cuò)誤，導(dǎo)致最終它的不正確輸出結(jié)果的比率跟那些強(qiáng)類型語(yǔ)言的相似。
這還有一副類似的統(tǒng)計(jì)圖，統(tǒng)計(jì)的是運(yùn)行時(shí)各種語(yǔ)言的表現(xiàn)。同樣，相比起強(qiáng)類型語(yǔ)言，弱類型語(yǔ)言更傾向于仍能無(wú)異常(崩潰或拋出異常)的運(yùn)行。根據(jù)這兩個(gè)統(tǒng)計(jì)表可以看出，弱類型語(yǔ)言在輸出結(jié)果上將會(huì)有更高的錯(cuò)誤率。相比起C++或C#，PHP的錯(cuò)誤率是36%，而C++的是8%，C#是10%，用像PHP這樣語(yǔ)法上不是很嚴(yán)格的語(yǔ)言寫(xiě)成的應(yīng)用，雖然充分利用了這些弱類型語(yǔ)言帶來(lái)的方便性，但不經(jīng)意的拼寫(xiě)錯(cuò)誤也會(huì)很容易溜進(jìn)產(chǎn)品代碼里?？偟目磥?lái)，動(dòng)態(tài)腳本語(yǔ)言跟強(qiáng)靜態(tài)類型語(yǔ)言比起來(lái)差距很大。這可能是我們只在較高層面測(cè)試這些腳本語(yǔ)言特征有關(guān)。
我們對(duì)這些數(shù)據(jù)做了進(jìn)一步分析，發(fā)現(xiàn)了下面一些事情。
- 這些在靜態(tài)語(yǔ)言和動(dòng)態(tài)語(yǔ)言干擾測(cè)試對(duì)比結(jié)果在統(tǒng)計(jì)學(xué)上有重要意義。這驗(yàn)證了靜態(tài)語(yǔ)言比動(dòng)態(tài)語(yǔ)言更容易發(fā)現(xiàn)錯(cuò)誤。
- C#的表現(xiàn)更像C和C++，而不是Java，盡管它外觀上跟后者更相似。
- Haskell 的表現(xiàn)跟Java很相似。
- 統(tǒng)計(jì)數(shù)據(jù)顯示在靜態(tài)類型語(yǔ)言間被干擾表現(xiàn)有明顯不同，比如C和C++間，C++和Java間，Haskell和Java間等。然而，動(dòng)態(tài)語(yǔ)言間卻沒(méi)有一個(gè)可比較的模式。借用托爾斯泰的一句話，它們看起來(lái)各有各不同。
然而，我想我們的研究最重要的成果是，通過(guò)對(duì)具有可比性的語(yǔ)言進(jìn)行干擾測(cè)試，提供了對(duì)編程語(yǔ)言的設(shè)計(jì)進(jìn)行評(píng)價(jià)的數(shù)據(jù)資料。
