王垠,四川大學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 公司,也是為了在精神上支持其它程式設計師。我希望他們不要被編譯器的「難度」迷惑了,不要被編譯器人嚇唬和打壓。你們做的並不是更低級,更無聊的工作。正好相反,真正可以發揮創造力的空間並不在底層的編譯器一類的東西,而在更接近應用和現實的地方。
每當有人向我表示編譯器高深莫測,嚮往卻又高攀不上,我都會給他打一個比方:做編譯器就像做菜刀。你可以做出非常好的菜刀,然而你終究只是一個鐵匠。鐵匠不知道如何用這菜刀做出五花八門,讓人心曠神怡,米其林級別的菜餚,因為那是大廚的工作。要做菜還是要打鐵,那是你自己的選擇,並沒有貴賤之分。