根据很多年的经验,自从到 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 已有的框架小改一下,就号称自己做过编译器了。

函数式语言爱好者,则是另外一种奇葩。对于这个我也写过文章。

所以这两种人,在面试的时候一定要深刻了解他们的性格,态度,做事方式。否则牛逼轰轰的“编译器人”或者“函数式程序员”进了任何公司,都很可能对团队成为一种灾难。

相关文章