我在一個程序語言的研究室做軟件工程的研究，平時讀到的都是程序語言的文章。這次讀了一下Alexander的文章，發現軟件工程社區和程序語言社區在論文的寫作風格上還是有很大差異的。

?

Alexander是軟件工程領域如日中天的人物，他在博士畢業后幾年就做到了ASE的Chair，畢業后不到十年就成為了奧地利的教授。我以前考慮traceability的時候就一直關注他的文章，這次發現他也做了和我相關的inconsistency-resolving，就把這個系列的幾篇論文都找來讀了一下。

?

ICSE06:

Instant Consistency Checking for the UML

?

ICSE07:

Fixing Inconsistencies in UML Design Models

?

ASE08:

Generating and Evvaluating Choices for Fixing Inconsistencies in UML Design Models

?

閱讀的過程非常有意思。首先論文的標題都很吸引人。然后往下讀Introduction討論問題但不介紹具體的解決方案，非常吸引人想繼續看下去。再往后的討論也很精彩，但各種語法拼寫錯誤就出來了，甚至有一篇論文的running example我懷疑是錯的。之后的解決方案只講概要不講細節，但看完后還是讓人感嘆：原來不過如此。

?

如果是程序語言領域，這樣的文章甚至可能不會被一個二流會議接收。方法沒有細節，沒有詳細的證明，怎么說明方法的正確性？作者的文章有那么多語法錯誤甚至錯誤的例子，怎么能表明作者是在嚴謹的做科研。

?

但是這些文章卻被軟件工程最好的會議接收了。是軟件工程的審稿都不認真嗎？是Alexander地位太高大家不敢拒嗎？我覺得情況不會這么簡單。一系列文章都被接受，這個工作肯定有它的出彩之處。軟件工程領域的專家們所看重的地方肯定與程序語言領域不一樣。那么，他的文章優秀之處究竟在哪兒呢？抱著這個問題，我仔細分析了他的文章，總結出下面幾點：

?

論文中說的每一句話都有證據證明
程序語言的文章，或者可能更多的是我自己的文章，在一些顯而易見的假設面前就不多做討論，但Alexander的文章幾乎對論文中從Introduction開始的每一句話都提供了數據一類的證據支持。比如，在論文中有一句，如果采用另一個UML模型元素的Attribute來提供選項，那么通常會有不超過10個選項。然后下面就是一副圖，顯示他對工業界的幾百個UML模型的分析結果，其中90%的都不超過10個。雖然有時對于一些顯而易見的事實進行證明顯得有些傻，但這樣卻保證了論文中的每一條假設都是正確的。

在更高的層次討論方法的選擇
程序語言領域常常是花很多篇幅描述一個方法的細節。而一個方法即使沒有非常優秀的特征，但只要它提供了解決舊問題的不同方法，也認為是很有意義的。但Alexander的論文更多的是在更高的層面討論方法的選擇。對于每一個設計決策，他都列舉數據說明：根據我們的統計，由于工業界的模型具有XX特征，所以我們只能采用A方法，不能采用B方法。而對于方法的細節，大概只描述到了程序語言領域的Introduction的程度。
軟工圈子里都是工程師，這種對設計決策的探討可能更容易讀。而工程師是不嚴謹的。只要程序能跑，那程序就是正確的。所以方法的細節就顯得太瑣碎了。

用強烈的詞語和句子
在水木上有人去了美國發帖子說：words are cheap。我讀Alexander的論文也是這個感覺。類似Significant improvement, very difficult problem的描述比比皆是。這樣的應用詞語，讓我這樣的東方謙虛國度出來的人很不適應。

用大量的數據對方法進行驗證和討論
幾乎每一篇論文最后列舉數據的驗證和討論section都達到了兩頁。每個section中都是大量的圖表證明多次實驗的結果。而且值得注意的是，這些實驗并不僅僅是為了驗證方法的正確和有效性，方法用在不同場景的各種特性、方法的缺點和不足也都表示了。

對不同的重點的關注可能來自于軟工領域的工程師和語言領域的數學家們的不同背景。我不想評論說軟件工程領域看重的重點和程序語言領域相比哪個更好。所有這些都是有意義的點，都在一定程度上保證了我們論文更有效更正確更能被讀者使用。如果我們自己的論文能把每一方面都做得很好了，當然接收的可能性很大。但是往往由于篇幅和精力等原因不能把所有方面都做得很好。那么就在投軟工的會議的時候關注軟工的點，投語言的會議的時候關注語言的點吧。

?

?

總結

以上是生活随笔為你收集整理的从Alexander Egyed的论文看程序语言和软件工程的论文写作风格差异的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。