根據很多年的經驗，自從到 Coverity 工作，一直到 Shape Security，微軟，Intel，直至跟阿里面試，我都深刻的體會到，做了點編譯器工作的人，似乎很容易產生一種牛逼轟轟，高人一等的心理，以至於在與人合作中出現各種問題。由於他們往往存在偏執心理和理想主義，所以在產生人際關係問題的同時，也可能設計出非常不合理的軟件構架，浪費大量的人力物力。

我曾經提到的DSL 例子，就是這樣的兩個人。都自稱“做過編譯器”，所以成天在我面前高談闊論，甚至在最基礎的概念上班門弄斧，做出一副可以“教育”我的姿態。而其實他們只有其中一人曾經做過一個parser，根本還不算是真正的編譯器工作，就上了天的姿態。另外一個完全就是外行，只是知道一些嚇人的術語，成天掛在嘴邊。只要他一開口，我就發現他並不知道自己在說什麼。

更糟的事情是，這其中一人還是 Haskell 語言的忠實粉絲，總是有這樣的雄心壯志，要用“純函數式編程手法”改寫全公司的代碼……

遇到這樣的人是非常鬧心的，到了什麼程度？我乾脆換了一個團隊。

我在美國的時候，有些公司在招人的時候明確表示，對簡歷裏提到崇尚“函數式編程”或者做過“編譯器”的人有戒備心理，甚至表示“我們不招編譯器專業的人”。以至於我也被作爲 false positive 刷下來，因爲我在 Coverity 做過編譯器相關工作。編譯器專業的人本來可以做普通的程序員工作，爲什麼有公司如此明確不要他們呢？我現在明白爲什麼了，因爲他們可能是性格非常差的團隊合作者，無法平等而尊重的對待其他人，總是一副高高在上，拯救世界的姿態。

現在經歷了所有這些之後，我可以很明確的表態，我其實看不起編譯器這個領域，而且我本來就不是屬於這個領域的人。PL 和編譯器其實是很不一樣的，真懂 PL 的人也能做編譯器，而做編譯器的卻不一定懂 PL。爲什麼呢？因爲做編譯器的一般專注於別人已經設計好的語言，比如 C，C++。他們必須按照別人寫好的語言的設計規範（specification）來設計編譯器，所以沒有發揮的空間。他們並不需要理解語言設計的各種方面來設計編譯器。實際上編譯器是如此無聊的工作，他們大部分時候只是把別人設計的語言，翻譯成另外一些人設計的硬件指令。所以編譯器領域其實處於 PL 和計算機體系構架（computer architecture）兩個領域的夾縫中。

編譯器領域幾十年來翻來覆去都是那幾個編程模式和技巧，玩來玩去也真夠無聊的。很多程序員都懂得避免“低水平重複”，可是很多程序員由於沒有系統學習過編譯器，誤以爲做編譯器是更高級的工作，而其實編譯器領域是更加容易出現低水平重複的地方，因爲創造的空間非常有限。

然而編譯器領域的人往往認識不到自己在整個 IT 領域裏的地位，做過編譯器的人總是以爲自己懂了編程語言的一切，而其實他們絕大部分只是一知半解。這些你從我之前懟 Chris Lattner 的一些文章（鏈接1，鏈接2）就可以看出來。雖然是編譯器領域聲名顯赫的人物，卻對語言有如此謬誤的理解，甚至在設計 Swift 語言的早期犯下我一眼就看出來的低級錯誤。

編譯器領域最重要的教材，龍書和虎書，在我看來也有很多一知半解，作者自己都沒搞懂的內容，而且花了大量篇幅只是在寫parser。我曾經跟虎書作者 Andrew Appel 的一個門徒合作過，她當時是 IU 的助理教授，讓我寫各種扯淡而毫無意義的論文，而且對人非常的 push 和虛僞。那是我在 IU 度過的最難受的一個學期，這使我我對“編譯器人”的偏見又加深一層。

頂級人物如此，其它的聲稱做過編譯器的人，也可想而知了。大部分所謂“編譯器領域”的人，其實連最基本的的編譯器都沒法從頭寫出來。大部分都是利用 LLVM 已有的框架小改一下，就號稱自己做過編譯器了。

函數式語言愛好者，則是另外一種奇葩。對於這個我也寫過文章。

所以這兩種人，在面試的時候一定要深刻了解他們的性格，態度，做事方式。否則牛逼轟轟的“編譯器人”或者“函數式程序員”進了任何公司，都很可能對團隊成爲一種災難。