程式設計龍書的兩位作者憑藉編譯器技術獲得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創作者嗎？好吧，也許明年。