程式設計龍書的兩位作者憑藉編譯器技術獲得2020年圖靈獎

banq發表於2021-04-01

Alfred Aho和Jeffrey Ullman憑藉開創性的編譯器和演算法工作而獲得2020年圖靈獎。

週三,全球最大的計算機專業人士協會電腦科學協會表示,Aho博士和Ullman博士將因其在支援計算機程式語言的基本概念方面所做的工作而獲得今年的圖靈獎。Ullman和Aho之間的合作是開創編譯器技術的先河,該合作始於1967年在AT&T的傳奇研究中心貝爾實驗室。

在過去的五十年中,電腦科學家已經建立了越來越直觀的程式語言,使人們越來越容易地為桌上型電腦,膝上型電腦,智慧手機,汽車甚至超級計算機建立軟體。編譯器的工作是將這些語言指令轉換成處理器真正理解的機器程式碼,也就是將這些語言有效地轉換為計算機可以理解的一和零。Aho和Ullman幫助找出了將高階程式轉換為低階機器程式碼的編譯器技術。

Aho和Ullman還共同撰寫了2篇經典的CS書籍:綠色和紅色的“龍書”(1977年和1986年)。

程式設計龍書的兩位作者憑藉編譯器技術獲得2020年圖靈獎

程式設計龍書的兩位作者憑藉編譯器技術獲得2020年圖靈獎

 

黑客新聞網友評論:

龍書今年獲得了圖靈獎!想象一下,您在40年前所做的事情贏得了大獎。

 

十年後,我開始閱讀《龍書》,並意識到如何修改NFA正規表示式搜尋演算法,以解決我在數字取證和電子資料展示中遇到的問題。

 

我經常看到龍書被當作一個出氣筒的時候。似乎在某些時候,這本書與K&R一起成為了毫無根據的批評的目標。

 

《龍書》在解析上花費了太多時間,而在優化上卻花了不多的時間。公平地說,本書的第一版是1986年出版的。看起來第二版(2006年)增加了3章有關資料流分析和並行化的章節。

 

《龍之書》的第一版就表明了Aho和Ullman當時就領先了很多嗎?

  

從事正規表示式引擎工作的人不多。

 

我的碩士論文是為Haskell進行程式碼生成的,其中我花了相當長的時間來學習樹模式匹配,AST操作,暫存器分配等。通過理解程式碼生成的這些不同階段,可以大大提高速度。

在編譯器的上下文中,另一個原因是通過微優化詞法分析和解析沒有太多收穫。畢竟,一個程式碼只被編譯一次並執行多次。因此,您知道很多樂趣在哪裡。不幸的是,本科生通常會錯過編譯器課程中最複雜的部分。

 

過去,詞法分析是編譯器最熱的部分,因為它必須接觸原始碼的每個位元組,並且後​​續階段沒有太多資料需要處理。但是在1990年代,隨著優化編譯器成為主流技術,這種情況不再成立。

 

儘管我在大學期間真的很喜歡編譯器,但我從沒想過出於實際原因會構建一個編譯器。我最終將這些知識用於兩個非常有趣的專案。其中一個是Java中的模板引擎,用於將變數轉換為SQL查詢中的子句。另一個是PL / SQL的直譯器,該直譯器有助於提取過程和功能以對生產環境中的軟體包進行部分更新(使用者可以選擇將哪些過程傳送到生產環境,而不必更新整個軟體包)。

 

很奇怪,我記得這本書太笨拙,晦澀難懂,當我最初閱讀它時,沒有足夠的說明性文字來編寫編譯器課程……也許我記錯了。

 

我實際上認為前端(詞法分析,語法分析,語義分析)對大多數軟體工程師而言更為重要。

想象一下:在大多數職業中,您都不需要在後端工作。但是,如果您想解析某些內容(例如配置檔案),則Lexing和解析非常有價值。這類事情在日常工作中比在程式碼生成和優化中更常見。

 

建議大多數軟體工程師避免發明新的配置或其他DSL及其解析器/詞法分析器。這很容易導致難以除錯的程式和長期的技術債務。始終首先研究現有的和經過測試的解決方案(甚至是JSON!)。即使您不發明語言,也可以避免使用高階格式(例如無上下文語法)來編寫低階解析器/詞法分析器(請參閱Lark https://github.com/lark-parser/lark)。定義和維護語法要容易得多。

 

在“資料結構和演算法”是我們最先進的教科書的黑暗時代,我們將Aho,Hopcroft和Ullman的作者三人稱為“三個智者”。很高興看到Aho和Ullman得到了更多的重視。

 

真正的“弦論”大師

 

獎金沒有發給React創作者嗎?好吧,也許明年。

 

相關文章