爲什麼我們不願意讀論文,原來都是作者害的

今天在頭條 沈向陽:讀論文的三個層次 文章中,對 沈向陽 博士於5月14日在 全球創新學院(GIX) 所做的一場線上公開課“You are how you read”,分享了一些他對於科研論文閱讀、撰寫的有趣的經驗。對於閱讀,特別是科研論文的閱讀,他強調一是要保持閱讀的持續質疑的狀態。

不過,在他的演講中引用了 Jonathan Shewchuk 教授的一篇博文: ** Three Sins of Authors in Computer Science and Math ** 透露了一個困擾很多學者的一個祕密:爲什麼我們不願意讀論文,原來都是作者害的

▲ Jonathan Shewchuk | 圖片來自於他的博客

▲ Jonathan Shewchuk | 圖片來自於他的博客

Jonathan Shewchuk總結了他過去七年期間所讀過的大約四百篇論文(計算機科學與數學領域的),也就是大概三十篇左右他覺得寫的還不錯,除此之外的其他論文,若想真正搞明白到底論文的意義所在,比讓一頭駱駝通過針眼還難,在沒有比這更令人醍醐灌頂的比喻了。

通常我們都是通過耳濡目染學習論文寫作的,當看過百八十篇論文之後,我們就會下意識比着葫蘆畫瓢,模仿着寫作。大部分情況這樣做是有意的,但還有一些令人作嘔的寫作模式被毫無質疑地廣泛採用。下面給出他總結提煉的幾個在計算機科學與數學專業論文的惱人的寫作模式,不過這些模式也在其它論語論文中也存在。

瞭解一下這些模式,或許在幫助你不再爲此煩惱,或者你也不會犯同樣的錯誤去煩別人了。

 

01碎碎念1的老祖母模式


論文一開始的綜述部分,也許是論文中最重要的一部分,你希望通過這段文字抓住讀者的眼球,使他們能夠進一步吧論文讀下去。但不知爲什麼,很多作者卻在此部分廢話連篇。比如下面這段關於高性能計算會議論文的綜述摘錄:

具有可擴展性的大規模並行計算機平臺可用於解決所謂巨大挑戰問題。這些可擴充分佈式內存系統可以在不改變基本架構的情況下成比例的提高性能。爲了充分發揮硬件的可擴展性優勢,應用軟件也同樣需要具有可擴展性的從而適應計算性能的增加。

如果你發現在看這段綜述摘要的時候已經走神了,別怕,實際上論文作者本身也心不在焉了。這段碎碎唸的文字除了磨磨唧唧告訴你一些早已熟知的概念之外,沒有任何意義。也許你不知道這些事情,但這段文字也不會幫助你有更多的瞭解。對於“可擴展性”、“巨大挑戰問題”等常用語如果你已經瞭解,那麼上段話就是碎碎念1,反之你也許就不再有勇氣繼續把論文讀下去了。

在這裏我並不想告訴你如何能夠將你的綜述寫作打磨到能適應每位讀者,如果真有這樣的方法也許就不會出現這些問題了。我想說直奔主題可以節省你的時間。

在上面的範例中,作者本應通過這些文字解釋論文的主旨,引逗讀者入坑。但作者卻將它都做一個必須寫的一段文字放在那兒,而卻不敢直奔論文核心內容,也許之前他從看到別人這麼幹過。那麼這樣跟着別人的模式寫作就一定好嗎?

下面這段來自線性代數會議的論文摘要則將碎碎念念到了極值:

近年來,對來自於解決數值物理計算靜態邊界約束值進行離散化所形成的大規模線性系統方程的迭代求解起始條件的研究,成爲數值分析工程人員的主要關注對象…

這段文字對於領域的門外漢來講太不合適了,這就是爲什麼論文如此煩人的原因,一大堆這在文章只能被熟悉該領域的專家所閱讀。你本來是要說你的文章是講什麼有趣有意義的問題,卻在這裏很違心的說什麼:這個問題是衆多數據分析工程人員所關注的主要問題,這種老王賣瓜習慣可能適得其反。

記住,你的每一句碎碎念都是對專業讀者生命的無情消耗。

 

02賬房的記事本模式


越來越多的文章在開始簡介段略之後,不經意之間長出一個囊腫,就像下面這段垂死狀態的範例:

本文內容組織如下:在第二部分我們描述k維局部轉換方法;第三部分,我們給出基於局部轉換的k-維Delaunay三角構建的增量方法;第四部分,我們證明該方法所構建的屬於Delaunay 三角劃分;第五部分,我們給出了三種方法以及基於該方案的數據構建模式。第六部分,我們討論算法的複雜性並展示我們所提出方法的實驗結果。

這不就是一段文字描述的文章目錄嗎?囉裏囉嗦,嘰嘰歪歪。除了將文章各段主題重複之外,毫無用處。這一點,只要略微往後瞟一眼就一清二楚了。然而這段令人眼瞳的文字居然成爲慣例了,很多研究人員將它視爲技術文章的標配。

也許有人認爲我對別人的文章要求太苛刻了。上面引用的範文來自於一篇有兩頁前言的文章,我承認文章的邏輯主線在前言清晰展開會幫助讀者掌握文章脈絡,但這種笨拙的精細記事模式不敢恭維。

再者,敘述的時候需要按照“有趣信息是什麼?在哪兒能找到?”認知模式,先講段落內容,再給出段落序號。像“第五部分,我們balabala”的模式令人討論。

除非你有新奇的看法,否則不要將讀者自己能夠看出的結論在最後當做結論單獨寫出來。

 

03掛羊頭賣狗肉模式


你看看下面這段文章最後的“結論”一段中的摘錄有何不妥?

我們證明了除了一個常量之外,三角劃分方法在局部特徵尺寸和最小角度基的邊界是緊的。我們同樣也展示了具有相同局部特徵尺寸的三角劃分的基數也相同,之間只相差一個1/α1/\alpha因子。

你的答案是? 沒錯,這兩句話哪叫結論呢!這分明是兩句簡介,可以在文章前言,或者摘要中看到。我一讀到這種將前言中的句子只是修改了動詞時態之後就直接放在結論中,氣就不打一處來。

很多作者都認爲文章最後需要有一個結論,應了那句名言:“告訴他們你要講什麼,然後開始講,最後再告訴他們你講了什麼。”。好的,是的,對吧,嗯? 不!

結論的意義應該是給讀者更多的信息,將文章結果重新總結並保留最核心的結論,從發展的角度看待你的結果。

如果讀者在沒有看你的文章之前,只看結論這一節,如果能夠完全理解,就說明你的結論寫的有問題了。好的結論應該是把文章讀完之後,原來的那些次要問題變得更加重要起來的部分,對未來發展有意義,或者是一些開放的問題。

如果你實在想不出什麼有意義的結論的話,那就老老實實的別寫結論了。不寫結論而結束一篇論文,並不丟人。這總比掛羊頭賣狗肉,濫竽充數一個結論要好。

Johnnathon Shewchuk最後還補充了一點技術論文中令人不悅的習慣,那就是不恰當的縮寫,比如像FNPLs, FTMPS,NUMAchine等等。像Infectoid、Puggsley,Vomitsauce這類既好聽又好記的縮寫,其中的智慧和優雅遠非FTMPS能夠比擬的。


  1. 碎碎念:是從閩南語裏面的“踅踅念(seh-seh-liām)”音譯過來的。有時表示:老是重複說着一些瑣碎沒有意義的事情,形容說話的這個人很嘮叨,屬於貶義詞。 ↩︎ ↩︎

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章