警惕“编译器人”和“函数式程序员”

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

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

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