我不是編譯器專家

2021-02-25 嵌入式Linux

王垠,四川大學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 公司,也是為了在精神上支持其它程式設計師。我希望他們不要被編譯器的「難度」迷惑了,不要被編譯器人嚇唬和打壓。你們做的並不是更低級,更無聊的工作。正好相反,真正可以發揮創造力的空間並不在底層的編譯器一類的東西,而在更接近應用和現實的地方。

每當有人向我表示編譯器高深莫測,嚮往卻又高攀不上,我都會給他打一個比方:做編譯器就像做菜刀。你可以做出非常好的菜刀,然而你終究只是一個鐵匠。鐵匠不知道如何用這菜刀做出五花八門,讓人心曠神怡,米其林級別的菜餚,因為那是大廚的工作。要做菜還是要打鐵,那是你自己的選擇,並沒有貴賤之分。

相關焦點

  • 華為方舟編譯器完整開源為何要10年?看看專家怎麼說
    華為方舟編譯器完整開源為何要10年? 都在用的報告小程序 寫文章、做研究、查資料【必備】 微信掃一掃,我知道了
  • 方舟編譯器帶來更多話語權,國產編譯器仍需提高自主性
    劉新銘:我的第一個觀點是編譯器一定要做。編譯器是世界上第一個電腦軟體。在沒有編譯器之前,只能靠會寫彙編的人去編譯電腦軟體。這需要很大的工作量,而且需要很高的專業技術能力。所以編譯器的存在是非常有必要的。有了編譯器才會有作業系統,才會有生態。所以如果國內不做好自己的編譯器,就很難在這個生態中紮根。
  • C語言初學者該如何選擇編譯器?哪個編譯器好用?
    剛開始學C語言,很多人都不知道該如何選擇一個編譯器。C語言相對其他程式語言來說,編譯器比較多,網上眾說紛紜,在這裡,我以親身學習經歷說明新手該如何選擇編譯器。我學習C語言一共只用了兩個編譯器,一個是VC++6.0,另一個是Dev C++。什麼時候用?
  • C編譯器小家族之C編譯器各顯神通
    C/C++編譯器有哪些?Pgi編譯器……其實有一大串,我們只要熟悉常用的最強大的幾款就可以了。和GCC的關係:Cygwin是讓Windows擁有Unix-like環境的軟體而不是編譯器,GCC是安裝在Cygwin上的編譯器。優點:可以比MingW移植更多的軟體到Windows上,對Linux接口模擬比MingW全面。缺點:軟體運行依賴cygwin1.dll,速度受點影響。
  • 第一個 C 語言編譯器是怎樣編寫的?
    可是問題來了,不知道你有沒有想過,大家都用C語言或基於C語言的語言來寫編譯器,那麼世界上第一個C語言編譯器又是怎麼編寫的呢?這不是一個「雞和蛋」的問題……還是讓我們回顧一下C語言歷史:1970年Tomphson和Ritchie在BCPL(一種解釋型語言)的基礎上開發了B語言,1973年又在B語言的基礎上成功開發出了現在的C語言。
  • Intel的「霸道」:深究編譯器對CPU性能的影響-Intel,AMD,編譯器...
    全文內容非常多,基礎原理、SSE/AVX指令集特點、編譯器優化歷史等等都有涉及,這部分內容就不再翻譯了,因為內容過於專業,大部分人都不是專業人士,讀起來晦澀難懂,同行超能網為我們選取了其中的重點內容。首先,AMD也參與了GCC編譯器工程,而微軟開發VS時也會跟AMD及Intel保持合作以便對他們的CPU作出公正(微軟語)而又統一的優化支持。另外,AMD贊助並推廣了Open64編譯器,它脫胎於一個編譯器研究計劃,後者最早是Intel贊助的、針對安騰架構所優化的編譯器項目。
  • C語言編譯器哪個好_6款好用的C語言編譯器推薦
    C語言編譯器哪個好其實win tc是款很不錯的軟體。去用一下你就知道了,因為我自學c時就是用的那個軟體,真的向你推薦它!
  • C語言編譯器的來源
    /解釋器(以下統稱編譯器)都是用C語言編寫的。可是問題來了,不知道你有沒有想過,大家都用C語言或基於C語言的語言來寫編譯器,那麼世界上第一個C語言編譯器又是怎麼編寫的呢?這不就是一個「雞和蛋」的問題嗎?
  • C語言編譯器哪個好?6款好用的C語言編譯器推薦
    一些剛開始接觸C語言編譯的網友想下載一款C語言編譯器來使用,不過,網絡上有不少C語言編譯器相關的軟體,讓人很難抉擇。那麼,C語言編譯器哪個好?今天的文章裡,小編給大家整理了6款好用的C語言編譯器推薦給大家,需要下載C語言編譯器的網友,不妨了解一下!
  • Python編譯器與解釋器
    計算機不是人,沒有10個手指頭可以掰,所以它用不了十進位。那麼它用幾進位?二進位!二進位是用0和1兩個數碼來表示的數,也就是形如010101010的樣子。它的基數為2,進位規則是「逢二進一」,借位規則是「借一當二」。為什麼計算機要使用二進位作為自己的機器語言也就是數據的表示方式呢?
  • 大佬專用的十大在線編譯器
    網上十大編譯器網站名稱:1)Ideone.com | 在線IDE和調試工具>> C / C ++,Java,PHP,Python,Perl和40+編譯器和解釋器在線IDE和調試工具www.ideone.com2)鍵盤codepad.org是一個在線編譯
  • 什麼是C語言的編譯器?從計算機原理的角度談編譯器
    早期的機器語言沒有編譯器的概念,因為機器語言不過是很多的0和1,CPU(處理器)能夠直接識別機器語言,C語言本身是為了提高開發效率而開發出的新語言,語義上幾乎和現實世界表達意思一致,但是這樣高級的語義可就難倒了計算機,它不認識像if-else、while等單詞,那麼計算機怎麼識別C程序的呢,這就引出編譯器的概念了。
  • 編譯器 | 五款好用的C/C++編譯器(IDE利器)
    應一些看官老爺的後臺留言需要說一些編譯器和應對的環境,這篇文章屬於編譯器專題,這次我們討論的是的語言: C 和 C++,它們有著許多卓越的特性。後面會帶來不同種類語言的不同使用環境中所使用的編譯器 or IDE。前三個集成 IDE +個 VS 是一些工作中常使用的,後面兩個是一些使用到 C/C++語言的比賽中經常使用的。
  • 實現一個簡單的編譯器
    簡單的說 編譯器 就是語言翻譯器,它一般將高級語言翻譯成更低級的語言,如 GCC 可將 C/C++ 語言翻譯成可執行機器語言,Java 編譯器可以將
  • 你真的了解Linux下gcc編譯器的工作過程嗎?
    小豆丁:我錯了,老張,不該笑話你,你就跟我說說吧!老張:看在你態度還算誠懇的態度上,就跟你說說吧!可執行程序,實際上就是計算機可以執行的指令的集合,我們在電腦上寫好的程序代碼,經過編譯器的編譯,最終形成的就是可執行程序,這樣計算機就可以按照代碼中想要表達的功能進行工作了。
  • C語言編譯器電腦版
    C語言編譯器電腦版 資訊閱讀 大小: 6.89M 版本: 4.3
  • 解讀| 華為方舟編譯器的革命性到底體現在哪裡?
    針對這個問題,餘承東在 8 月 6 日推薦了一篇由「菊廠搞機」發表的一篇題為《華為新貴!方3、Android 虛擬機的編譯器受限於手機硬體和代碼優化模板單一,代碼優化空間有限。這四個問題,也是華為試圖通過方舟編譯器解決的問題。華為方舟編譯器是如何解決問題的?在回答這個問題之前,先看一下華為從事方舟編譯器工作的時間線:2009 年,華為啟動 5G 基礎技術研究的同時,開始創建編譯組,第一批海內外研究人員加入。2013 年,華為推出面向基站領域的自研編譯器 HCC,並正式提出編譯器框架構想。
  • C語言C++編程學習常用的編譯器
    不過我認為這款軟體已經過時了,而且現在主流的win7和win8都不兼容這款軟體,所以建議大家不要用,當然如果你是為了應付計算機二級,那就算了,不過這時你得下載兼容性比較好的軟體,不然根本在win7運行不了。Code::Blocks
  • c編譯器so easy,gcc c編譯器生成、使用動靜態庫
    第一章程序開發人員大多接觸過c編譯器,請注意,不要將c編譯器和編輯器弄混淆哦。本文對c編譯器的講解,同樣基於gcc c編譯器,本文主要目的在於對linux環境下gcc c編譯器生成和使用靜態庫和動態庫予以介紹。此外,本文為系列教程第一篇——基本概念篇,之後將帶來另外兩篇。
  • 華為方舟編譯器開源了哪些內容?
    華為方舟編譯器開源官網8月31日正式上線,方舟編譯器代碼正式出現在華為開源平臺HUAWEIOpenSource上。方舟編譯器是華為自研作業系統鴻蒙OS的重要組成部分,本次方舟編譯器框架代碼的正式上線,也意味著華為鴻蒙OS向開源走近了一步。