我不是编译器专家
這是王垠發表的一篇文章，轉給大家看看，希望有些收獲
王垠是誰？
王垠，四川大學97級本科畢業，保送到清華大學計算機系直博。期間曾在清華大學計算機系軟件所就讀，主要進行集成電路布線算法的研究。
在此期間，他因《完全用GNU/Linux工作》一文和對TeX的推廣等“非研究成果的業余東西”而出名。在只剩一年就要博士畢業的時候，他申請退學，并將1萬7千余字的“退學申請書”（題為清華夢的粉碎）公布在網上，引起輿論界一時對教育體制、理想主義等的熱議。
王垠的博客
https://www.yinwang.org/
王垠的微博
https://weibo.com/u/6347862377?is_all=1#_rnd1609678848556
我是從之前有個新聞說王垠準備去華為工作開始關注他的，他在微博上發表的觀點，我都會比較關注，很大的原因是因為他的很多觀點非常犀利。
這篇文章我詳細讀了下，王垠應該是一個非常高端的憤青，說他是憤青是因為可以從他的筆墨中感受到些許的無奈和吶喊，高端是因為他對很多事物的認知是比較深入的。
第一種觀點「為什么我就是沒有遇到一個識我的伯樂」。
我覺得王銀是有才的，只不過這個才，是在一個比較細分的領域，而且，不是在情商上。
工作多年，我認識很多厲害的人，他們大學都能考上很好的學校，工作上，他們也能快速的解決問題，更甚至的，能承擔企業非常重要的開發任務。
但是也僅僅是開發任務
就像文中寫道的一樣，跟上面交流的，還有一個或者兩個其他人，這幾個人，才是決定公司項目走向的人。
第二種觀點「別人都是垃圾」
不管是做什么，都是和人打交道，一個人的力量非常有限，如果能聯合很多人力量的人，那才是強者，王垠是一個強者，他可以是一個呂布，但是絕對不是曹操、劉備、孫權這樣的人物。
—— 以下是文章原文
工作多年以來，我深刻體會到一個現象，那就是做過“編譯器”工作的人，哪怕只做了點皮毛，都容易產生高人一等的心理，以至于在與人合作中出現各種問題。由于他們往往也存在偏執心理和理想主義，所以在惡化人際關系的同時，也可能設計出非常不合理的軟件構架，浪費大量的人力物力。
我曾經提到的?DSL?例子，就是這樣的兩個人。他們都自稱做過編譯器，成天在我面前高談闊論，甚至在最基礎的概念上班門弄斧，顯示出一副“教育”其他人的姿態。其實他們只有一個人做過?parser，還不算是真正的編譯器工作，卻總顯示出高深莫測的模樣。哲人一樣捋捋胡子，搖搖腦袋，慢條斯理，嗯…… 另外一個完全就是外行，只是知道一些術語，成天掛在嘴邊。每次他一開口，我都發現這個人并不知道他自己在說什么，卻仍然洋洋得意的樣子。
我是被他們作為專家請來這個公司的，來了之后卻發現他們最喜歡的事情，是在我面前顯示他們才是“專家”。他們也問過我問題，可是每一次我都發現他們并不想知道答案，因為我說話的時候他們并沒有在聽。不管說什么問什么，他們似乎只想別人覺得他們是最聰明的人。
雖然對其他人趾高氣昂，全懂了的樣子，對于 Brendan Eich（JavaScript 語言的創造者）這樣有權勢的人物，卻是各種跪舔，顯示出各種“賤”來。我雖然尊重 Brendan Eich 個人和他的語言，然而很明顯他是半路出家，對語言設計并沒有很深的造詣。對語言稍微有點研究的人，都不會對這種人物顯示出諂媚的態度。
“Yin，你知道 X 嗎？” 當然他期望的是你說不知道，這樣他就能像大師一樣，把這個剛學到的術語給你講半天。每當這個時候，我就想起一個前同事喜歡說的一句話：“你問我，是因為你不知道，還是因為你知道？” 其實他問的這個概念 X，常常是我很多年前熱心過，試驗過，到最后發現嚴重問題，拋棄了的概念。
更糟的事情是，這其中一人還是 Haskell 語言的忠實粉絲，他總是有這樣的雄心壯志，要用“純函數式編程”改寫全公司的代碼……
遇到這樣的人是非常鬧心的，到了什么程度？他們經常雄心勃勃用一種新的語言（Scala，Go 之類）試圖改寫全公司的代碼，一個月之后開始唾罵這語言，兩個月之后他們的項目不了了之，代碼也不知道哪里去了。然后換一種語言，如此反復……
后來實在沒做出什么有用的東西，這兩個人又突發奇想，開始做?DSL，鬧得團隊不得安寧，有點資歷的工程師（包括我和一位早期 Netscape 的資深工程師）都極力反對，向大家指出更容易，更省力的解決方案。然而由于管理層根本不懂，所以任憑這兩個人拍胸脯，沒有困難制造困難也要上。因為煩于他們在我面前高談闊論，而且對這個 DSL 的事情實在看不下去了，我干脆換了一個部門，不再做跟語言和編譯器相關的事情。
現在這個 DSL 做了好幾年了，仍然很垃圾，然而公司人傻錢多，居然請到了 Java 界的資深人物來給這 DSL 寫 specification。這兩人也分別升職為 Principal Engineer 和 Distinguished Engineer。當看到“Distinguished Engineer”這個 title，我覺得太好笑了。當然，我相信有資歷的 PL 人都會明白這 DSL 的問題，我想象著這位 Java 人跟這兩人將會發生的沖突。如果他對此沒意見的話，那他的水平還真是值得懷疑了。
在 Coverity 和其它公司遇到的編譯器人，基本是差不多的問題。他們下意識里把自己看成是最高檔次的程序員，所以對其他人顯示高高在上的氣勢。
Coverity 有一個 ABC 工程師，因為自己寫過完整一點的靜態分析，比較會折騰 C++，總是趾高氣昂的對待其他人，甚至直接對別人說：“你寫的這是什么代碼啊？我絕對不會寫出這么爛的代碼！” 還有一個從斯坦福編譯器教授 Alex Aiken 那里畢業的 PhD，在 Coverity 做構架師，平時一行代碼不寫，也不看其他人寫的，說不出見解深刻點的話，因為與實際工程脫節，盡在瞎指揮。地位最高的 Distinguished Engineer，成天優哉游哉，看一些關于?parser?的話題，似乎 parser 是他終身的研究方向，也不做什么實事。
我所在的每一家公司，只要工作跟編譯器沾邊，總是不免遇到這樣的人。其它的我就不細講了。
有些美國公司在招人的時候表示，對簡歷里提到“做過編譯器”的求職者有戒備心理，甚至直接說“我們不招編譯器專業的人”。以至于我也曾經被過濾掉，因為我做過編譯器相關工作。編譯器專業的人本來可以做普通的程序員工作，為什么有公司如此明確不要他們呢？我現在明白為什么了，因為自認為是“編譯器專業”的人，有大概率是性格很差的團隊合作者，喜歡顯示出高高在上，拯救世界的姿態，無法平等而尊重的對待其他人。
有些人也把我叫做“編譯器專家”，喜歡在我面前提“編譯器”這個詞。我一直聽著別扭，卻沒有正式拒絕這個稱呼。每每遇到“真正”的編譯器專家，我總覺得自己不是那個圈子的。不是我不能做編譯器的工作，而是編譯器領域人士的認識水平，理念和態度和我格格不入。
所以我應該明確表個態：我不是編譯器專家，而且我看不起編譯器這個領域。我一般不會居高臨下看低其它人，然而對于認識膚淺卻又自視很高的人，我確實會表示出藐視的態度。現在我的態度是針對編譯器這整個領域。真的，我看這些人不順眼很多年了。
就最后研究的領域，我是一個編程語言（PL）研究者，從更廣的角度來看，我是一個計算機科學家。有人聽了“科學家”一詞總是誤以為我在抬高自己，而在我心目中“科學家”僅僅是一個職業，就像“廚師”一樣，并不說明一個人的水平和地位。PL 研究者被叫做“計算機科學家”是很恰當的，因為 PL 領域研究的其實不只是語言，而是計算的本質。通常人公認的計算機科學鼻祖?Alan Turing?也可以算是一個 PL 研究者，雖然他認識水平比較一般。
IT 業人士經常混淆編程語言（PL）和編譯器兩個領域，而其實 PL 和編譯器是很不一樣的。真懂 PL 的人去做編譯器也會比較順手，而編譯器專業的卻不一定懂 PL。為什么呢？因為 PL 研究涵蓋了計算最本質的原理，它不但能解釋語言的語義，而且能解釋處理器的構架和工作原理。當然它也能解釋編譯器是怎么回事，因為編譯器只不過是把一種語言的語義，利用另外一種語言表達出來，也就是翻譯一下。PL 研究所用的編程范式和技巧，很多可以用到編譯器的構造中去，但卻比編譯器的范疇廣闊很多。
深入研究過 PL 的人，能從本質上看明白編譯器里在做什么。所以編譯器算是 PL 思想的一種應用，然而 PL 的應用卻遠遠不止做編譯器。每次有人說我是做編譯器的，我都覺得是一種貶低。我只不過拿精髓的理念稍作轉換和適應，做了點編譯器的事情，就被人叫做“編譯器專家”，而我根本不是局限在這個方向。
專門做編譯器的人，一般是專注于“實現”別人已經設計好的語言，比如 C，C++。他們必須按照語言設計者寫好的語言規范（specification）來寫編譯器，所以在語言方面并沒有發揮的空間，沒有機會去理解語言設計的微妙之處。
許多做編譯器的人并不是從零開始寫的，而是拿現成的編譯器來修改，所以他們往往被已經存在的，具體的構架限制了想象力。極少有編譯器人完整實現過一個語言，都是在已有的基礎上小改一下，優化一些局部的操作。這大大限制了他們可以獲得的全局洞察力。
很多編譯器工程師并沒有接受過系統的 PL 理論教育，有些甚至是半路出家，在學校里根本沒碰過編譯器，也沒研究過 PL。比如我的第一個公司 Coverity，招進去的很多人從來沒碰過編譯器，也不懂 PL。我進去不久，Coverity 的 VP 滿口牛氣向新人宣布：“我們會教會你們一切！” 然而很可惜，PL 的精華根本不是一個公司在短期能夠傳授的。Coverity 沒有這個能力，Google，Facebook，Intel，微軟…… 都沒有這個能力。
很多半路出家的編譯器工作者以為在公司跟著做項目，折騰下 LLVM 之類，就會明白所有的原理。然而事實是很多人這樣做了十幾年，仍然不明白最基礎的原理，因為他們被具體的實現限制了想象力。PL 理論聯系著計算的本質，不明白這些原理就只能看到膚淺的表面，死記硬背，遇到新的現象就沒法理解了。跟 LLVM 專家聊天，我很多時候發現他們的知識是死的，僵化在 LLVM 具體的實現里了。
由于缺乏對 PL 理論的深入研究，編譯器人往往用井底之蛙的眼光來看待語言，總以為他們實現過的語言（比如 C++）就是一切。一個語言為什么那樣設計？不知道。它還可以如何改進？不知道。“它就是那個樣子！” 這是我常聽編譯器人說的話。當然很多編譯器人連 C++ 都沒法完整實現，只是在已有基礎上做了很小的改動。
許多編譯器人把 C++ 的創造者 Bjarne Stroustrup 奉為神圣，卻不知道 Stroustrup 在 PL 領域并不是閃耀的明星。Stroustrup 曾經在 2011 年 11 月 11 日來到 IU 進行關于 C++11 的演講，IU 的資深 PL 教授們都有到場。Stroustrup 謙卑的說：“我需要向你們學習很多東西來改進 C++。” 看似“謙虛”，其實他說的是實話，因為 IU 的教授們在語言設計上確實比他強很多。
Stroustrup 的整場演講，我沒有看到任何新穎的突破，全都是幾十年早已出現，我天天都在用的東西。然而這些 C++ 的改進被編譯器人看作是重大的歷史性的突破，因為他們很多人根本沒用過其它語言，甚至不知道它們的存在。
后來我的一個能力比較弱的 PL 同學進入了 C++ 委員會，為改進 C++ 做一些事情。從她的描述和表現，我感覺 C++ 委員會氣氛十分的官僚，古板和愚鈍。她進了 C++ 委員會之后，感覺整個人都傻了一樣，很膚淺的小事也說得眉飛色舞，好像什么重大的突破一樣。真懂 PL 的一些同學，很少有混進 C++ 委員會的，因為那意味著要利用另外的關系網，讓一些自己根本看不起的人騎在自己頭上，必須先幫他們做一些瞎扯淡的事情。
編譯器人所膜拜的大師，在真正的 PL 研究者眼里其實不算什么。編譯器人與 PL 研究者在見識上的差距是非常明顯的。PL 人因為看透了很多東西，比較謙虛，往往不想揭穿編譯器人的差距。但編譯器人卻因為在“工業界”有地位，趾高氣昂以為自己懂了一切一樣，結果遇到深刻點的 PL 問題就各種稀里糊涂。
實際上做編譯器是很無聊的工作，大部分時候只是把別人設計的語言，翻譯成另外的人設計的硬件指令。所以編譯器領域處于編程語言（PL）和計算機體系構架（computer architecture）兩個領域的夾縫中，上面的語言不能改，下面的指令也不能改，并沒有很大的創造空間。
編譯器領域幾十年來翻來覆去都是那幾個編程模式和技巧，玩來玩去也真夠無聊的。起初覺得新鮮，熟悉了之后也就那個樣了。很多程序員都懂得避免“低水平重復”，可是由于沒有系統的學習過編譯器，他們往往誤以為做編譯器是更高級，更有趣的工作，而其實編譯器領域是更加容易出現低水平重復的地方，因為它的創造空間非常有限。
同樣的編譯優化技巧，在 A 公司拿來做 A 語言的編譯器，到了 B 公司拿來做 B 語言的編譯器…… 大同小異，如此反復。運氣好點，你可能遇到 C，C++，Java。運氣不好，你可能遇到 JavaScript，PHP，Ruby，Go 之類的怪胎，甚至某種垃圾 DSL。但公司有要求，無論語言設計如何蹩腳，硬件指令設計如何繁瑣，你編譯出來的指令必須能正確運行所有這語言寫出來的代碼。你說這活是不是很苦逼？
我在 Cornell 的時候，有一個很有權勢的編譯器教授，從未發表有理論價值的 paper，卻老在 Java 上面做文章。他和他的博士生們總是把一些其它語言幾十年前已經有的“新特性”搬到 Java 上面，老酒換新瓶，發 paper 拉 funding。由于拉了很多錢，所以在系里很受寵，他的學生們在其它人面前都趾高氣昂的樣子。
后來這教授的一個學生去了 Facebook，幫他們做 HipHop，一個從 PHP 到 C++ 的“編譯器”。其實這種“源到源”編譯器做起來不算難，但給 PHP 這樣劣質的語言做編譯器，實在是狗血的工作，繁瑣而頭痛。沒有任何理論價值不說，在工業界有什么價值也難說。我的一個前同事曾經對 Facebook 的這個項目發表了一個尖銳而幽默的評價：“Facebook 現在不但給母豬涂上了口紅，而且真的開始 f.. 它了！”
后繼的還有 PHP VM 一類的東西，越來越離譜。后來這位同學可能也受不了，換組去做其它跟語言無關的事情了。在 PL 研究者看來，VM 也并沒有什么稀奇。PL 領域有各種各樣的“抽象機”（abstract machine），比如 CEK machine，它們揭示了計算的方方面面。我自己都設計實現過好幾個“可逆抽象機”，它們可以進行所謂“可逆計算”。所以一個 PL 研究者很容易就能設計出一個 VM 來，它們只不過是一種經過部分優化的解釋器。
每每看到編譯器人說到“VM”這個詞的時候那種榮耀而敬畏的神情，好像只有他們明白 VM 是什么，我就覺得好笑，外加一種說不出的滋味。編譯器人雖然知道一個具體的 VM 怎么實現，知道一些死板的細節和術語，卻不知道 VM 的本質是什么，不知道一個全新的，具有新特性的 VM 要怎么設計出來。
在《Chez Scheme 的傳說》一文中，我提到在 Cornell 的時候選過一門編譯器課程，后來在半學期的時候 drop 掉了。現在回想起這段歷史，發現它對“教育理念”這件事挺有啟發意義。教育是什么，是為了什么？Cornell 的這門課給了我一個很好的反面教材。
這個編譯器課程那一年的教授是 Tim Teitelbaum，他也是 GrammaTech 公司的創始人。GrammaTech 是與 Coverity 類似的靜態分析工具，不過 GrammaTech 還能分析二進制代碼。Tim Teitelbaum 是 Donald Knuth 的崇拜者，他經常提到 Knuth 提出的一些“偉大概念”，比如 attribute grammar。總是把 Knuth 那些東西說成是最偉大的發明。
這門課不知道最初是誰設計的。Andrew Myers 和 Tim Teitelbaum 以前交替著講這個課。
那么我為什么會 drop 這門課，而且是在學校允許 drop 課程的 deadline 之后呢？因為它的教育理念非常的落后和不合理，可以說就是坑人的。
從課程的大綱你可以看出來，它是很傳統的編譯器課程，一開頭花很多時間精力去折騰 parser。源語言是一種類似 Java 的語言，parser 是使用類似 lex，yacc 的工具生成的。這種盲目重視 parser 的誤區，我已經在另外一篇文章批評過，但還這不是我鄙視的重點。
這門課最讓人受不了的事情，發生在我成功完成 parser，開始編譯代碼的第一個 pass 之后。當得到那次作業分數的時候，我驚呆了。我從來沒有得過這么差的分數！仔細看原因，說我的代碼沒通過好些“測試”。我到那個時候才明白，原來提交后的代碼，會被助教拿來跑一些我毫不知情的測試（test），然后他簡單的根據這些測試的結果給出分數。
作業本身的要求是用大段大段的英語寫下來的。你需要按照這些英語描述從零實現編譯器。真的是從零開始，沒有任何的框架或者示例代碼，完全從白紙開始。經過許多努力，你寫出了編譯器，還自己寫了一些小測試，你覺得完全滿足了作業的要求。可是提交之后，你的編譯器代碼卻要被一整套你手里沒有的“測試”進行檢驗。所以最后你驚訝的發現，自己以為做對了，而助教那里的測試有那么多沒通過！
最讓人無語的事情是，學生手里是沒有這套測試的，而且他們不給你。也就是說，你提交作業的時候，無法用最后給你評分用的那些測試來跑你的編譯器，所以你無法知道提交之后會有多少測試失敗。
當我向助教和教授抗議，說這樣不合理，要求得到那些測試的時候，我受到粗暴的拒絕和鄙視。那種語氣，好像是在說我是一個不合格的學生，提一些無理要求。用來打分的測試怎么可能給你，你是太笨了吧？
很多其它 Cornell 學生被這樣對待，可能都以為沒什么，按照他們的要求做就行了，然而這是完全不合理的。按照合理的教學理念，學生應該有權得到自己學習狀態的反饋。如果學生做這種編程作業，就應該能從實際的測試中得到反饋，知道自己的編譯器是否符合要求。要知道，大段大段的英語描述，是很容易漏看或者誤解的。只有大量的測試才能正確的抓住“要求”本身。所以不給測試，就相當于不給你準確的要求，到后來卻要拿這套測試來給你打分。
課程本來應該把測試連同英語描述一起給學生，他們實現之后，自己跑通所有測試，再提交代碼。這樣學生就能準確的把握作業的“要求”，而不是看著那些混淆不堪的英語段落自己在那里猜。
因為這個原因，而且由于教授和助教的傲慢態度。我最終決定在課程都快進行到一半的時候 drop 這門課程。當然，要進行這個操作是需要系主任簽字特許的，為此我還在系主任那里留下一筆“污點”。
在我看來，Cornell 教授們的這種做法，根本就不是合格的教育者，可以說就是在坑人，整人，害人。在他們的理念里，教育是單方面的，學生必須通過作業和考試，而教授卻不需要為教學方法負責，可以隨便怎么教，作業和考試想怎么整都行。
很多 Cornell 教授有類似的現象，教學不用心，光是各種拉 funding，耀武揚威，完全不顧學生死活。也許這就是為什么 Cornell 總是有學生自殺。我走了之后有一年，在一個星期之內有三個學生從學校里瀑布旁邊的吊橋跳下去自殺，新聞轟動了全美國。
后來在網上看到有人罵 Cornell，說：“Cornell 想教你游泳，于是他把你推進池塘里，等你撲騰上岸。等你快上來的時候，他又朝你扔一塊大石頭，然后繼續等你游上來。等你又快上岸了，他又拿起一個榔頭往你頭上猛砸。這樣你就可以死了，可是 Cornell 仍然在那里等著你游上岸來……”
這段話恰到好處的描述了我的在 Cornell 的經歷。
轉學到 IU 之后，我參加了 Kent Dybvig 的編譯器課程，發現我所設想的編譯器課程原來早已被他實現了，而且實現的如此友好。編譯器的每一個 pass，都會把所有的“官方測試”發給學生。學生按照要求實現每個編譯器 pass，在自己電腦上跑通所有測試，充分檢查，然后才提交作業。而且作業的網站會自動測試你提交的代碼，在提交的當時就給你反饋：“你有 N 個測試沒通過，請修改后重新提交。”
這才是正確的教育方法，因為它給予學生合理的反饋，讓他們清晰的知道自己的表現是否符合預期，主動進步，而不是拿一些學生事先不知道的標準在那里瞎坑人，光是給人打分。
Cornell 沒有明白教育的目的是培養人，而不只是給人發文憑。Dybvig 教授不但技術和學術水平遠高于傳統的編譯器人，而且他的課程也設計得如此科學和友好。這才是真正的教育者。
雖然苦逼，編譯器人往往自高自大，高估自己在整個 IT 領域里的地位，看低其它程序員。編譯器人很多認為自己懂了編程語言的一切，而其實他們只是一知半解。
編譯器領域最重要的教材，龍書和虎書，在我看來也有很多一知半解，作者自己都稀里糊涂的內容。而且花了大量篇幅講?parser?這種看似高深，實則膚淺的話題，浪費讀者太多時間，誤導他們認為 parser 是至關重要的技術。以至于很多人上完編譯器課程，只學會了寫 parser，對真正關鍵的部分沒能理解。龍書很難啃，為什么呢，因為作者自己都不怎么懂。虎書號稱改進了龍書，結果還是很難啃，感覺只是換了一個封面而已。
我曾經跟虎書作者 Andrew Appel 的一個門徒合作過，當時這人在 IU 做助理教授。借著一次我跟她做 independent study 的機會，逼我寫毫無意義的論文，而且對人非常的 push 和虛偽。作為普林斯頓大學畢業的 PhD，學識水平跟 IU 的其他教授格格不入，卻在待人接物方面顯示出各種“賤”，對編譯器領域的“牛人”各種跪舔，隨時都在顯示自己以前在某某人身邊工作過。那是我在 IU 度過的最難受的一個學期，這使我對“編譯器人”的偏見又加深一層。
編譯器領域的頂級人物如此，其它聲稱做過編譯器的人也可想而知了。大部分自稱做過編譯器的人，恐怕連最基本的的編譯器都沒法從頭寫出來。利用 LLVM 已有的框架做點小打小鬧的優化，就號稱自己做過編譯器了。許多編譯器人士死啃書本，膚淺的記憶各種術語（比如 SSA），死記硬背具體實現細節（比如 LLVM 的 IR），看不透，無法靈活變通。
所以我常說，編譯器是計算機界死知識最多，教條主義最嚴重的領域。經常是某人想出一個做法，起個名字，其他人就照做，死記硬背，而且把這名字叫得特別響亮。你要是一時想不起這名字是什么意思，立馬被認為是法國人不知道拿破侖，中國人不知道mz x。你不是做編譯器的！
現在因為 AI 的泡沫，很多人轉向所謂“AI 框架”，“AI 編譯器”。這類職位如此之多，以至于很多人根本沒碰過編譯器，也搖身一變成為了“深度學習編譯器工程師”。
半路出家的“AI 框架工程師”和“AI 編譯器工程師”們，在別人寫出來的框架上小打小鬧優化一下，就以為自己做的是世界上最前沿的工作，卻不知道深入研究過 PL 的人其實很容易就看破了那些東西。很多 AI 框架工程師嘴里各種奇怪的術語，卻看不透所謂“AI 框架”只不過是“可求導編程語言”，完全不能從高級語言和邏輯的角度去看問題。
AI 框架和編譯器里面的原理和本質很容易被 PL 理論解釋，PL 研究者能夠為這些項目指出正確的方向，避免不必要的彎路，然而這些自詡為“編譯器人”的 AI 框架工程師們完全意識不到這一點。自高自大，膜拜權威，完全沒有去聽 PL 研究者在說什么，甚至覺得能“教育”比自己看得透的人。
每一個大公司都要趁著 AI 這個熱度做自己的“AI 框架”，“AI 編譯器”，唯恐不做自己的框架，就會在業界丟面子，所以一窩蜂而上。一定要聘用名聲很大的 AI 框架專家來公司站臺，雖然也不知道他最后能做出什么來。所有 AI 框架和編譯器都大同小異，屬于無謂的重復勞動。有些人搗鼓一下這個框架，然后用同樣的技巧去搗鼓另外一個，中間都是一些工程性的臟活。這種事情真是非常無聊。
AI 的熱潮正在褪去，大部分 AI 公司會在一年之內失敗。“AI 編譯器”的工作也會瀕臨滅絕。所以任憑他們自己瞎蒙亂撞吧，反正堅持不了多久了。
這就是為什么雖然有多次編譯器的工作機會，包括 Apple 的 LLVM 部門，我最后都沒去。進入 Intel 的時候，本來編譯器部門也歡迎我，可是再三考慮之后還是選擇了其它方向。因為我很清楚的記得，每一次做編譯器相關工作都是非常壓抑的，需要面對一些沉悶古板而自以為是的人，而且內容真的是重復，無聊和枯燥。
我唯一敬佩的編譯器作者是?Kent Dybvig，但我也不想跟他一起做編譯器。最近很多芯片公司的“AI 編譯器”部門找我，我全都拒絕了。我不喜歡身邊圍繞著這些人，做著這些事。我寧愿去賣燒餅也不想做編譯器。
由于編譯器人的性格特征，除非一個公司專門要做編譯器，否則對于曾經做過編譯器，想換個方向的求職者，在面試的時候最好深刻了解他們的性格，態度和做事方式，看他們是否能看淡這些，能否平等對待其他人，能否理性而實在的對待工程。否則自視很高的“編譯器人”進了公司，很可能對團隊成為一種災難。
我寫這篇文章是為了警醒廣大 IT 公司，也是為了在精神上支持其它程序員。我希望他們不要被編譯器的“難度”迷惑了，不要被編譯器人嚇唬和打壓。你們做的并不是更低級，更無聊的工作。正好相反，真正可以發揮創造力的空間并不在底層的編譯器一類的東西，而在更接近應用和現實的地方。
每當有人向我表示編譯器高深莫測，向往卻又高攀不上，我都會給他打一個比方：做編譯器就像做菜刀。你可以做出非常好的菜刀，然而你終究只是一個鐵匠。鐵匠不知道如何用這菜刀做出五花八門，讓人心曠神怡，米其林級別的菜肴，因為那是大廚的工作。要做菜還是要打鐵，那是你自己的選擇，并沒有貴賤之分。
推薦閱讀：
專輯|Linux文章匯總
專輯|程序人生
專輯|C語言
我的知識小密圈
總結
- 上一篇： 18位华人当选2022年加拿大工程院院士
- 下一篇： python爬取网易云音乐视频_用Pyt