转载

我为什么不再做PL人

我不做程序语言（PL）的工作已经半年了。在这半年里，我变得快乐了很多，对世界也有了新的观点。现在我想来讲一讲，我为什么不想再做PL的工作和研究。我只希望这些观点可以给正在做PL，或者考虑进入这个领域的人们，作为一份参考。

学校里的PL人：炒冷饭

PL看似计算机科学最精髓的部分，事实确实也是这样的。没有任何一个其它领域，可以让你对程序的本质形成如此深入的领悟，然而这并不等于你就应该进入PL的博士班。这是为什么呢？

这是因为，PL领域在几十年来，已经发展到了非常成熟的阶段。这里面的问题，要么在20年前已经被人解决掉了，要么就是类似“ 停机问题 ”一样，不可能解决的问题。然而，博士毕业却要求你发表“创新”的论文，那怎么办呢？于是你就只有扯淡，把别人已经解决的问题换个名字，或者制造一些看似新鲜却不管用的概念，在大会上煞有介事的宣讲。俗话说就是“炒冷饭”。

最开头进入这个领域的时候，你可能不觉得是这样，因为似乎有那么多的东西可以学习。那么多的新鲜名词，什么“类型系统”啊，“类型理论”啊，各种各样的“逻辑”啊，“语义”啊…… 可是时间久了，看透了，你就发现一些这个圈子里的规律。

几乎每篇PL的论文，里面必有一页弯弯曲曲，让人匪夷所思的逻辑公式。程序语言的论文，不是用程序来描述，而是使用一些老古董的逻辑符号。绝大部分PL领域的专家们，似乎都酷爱逻辑符号，视逻辑学家高人一等。这种崇尚古人的倾向，使得PL专家们看不见这些符号背后的，类似电路一样的直觉，所以他们也许能够发展和扩充一个理论，却无法创造一个全新的。

如果你看透了那些公式，自己动手实现过各种解释器，你就会发现PL论文里的那些公式，其实绝大部分相当于一段解释器代码，只不过是用一种叫做“逻辑”的语言写出来的。一阶逻辑，其实本质上是一种相当落伍的程序语言。如果你精通解释器的代码，也许就会发现，这些公式其实用非常蹩脚的方式，实现了哈希表等数据结构。是的，哈希表一般就隐藏在这些公式最显著的部分，你自己去找找吧。

所以当你看透了所有这些，就会发现PL的学术界，其实反反复复在解决一些早已经解决了的问题。有时候好几个子领域，其实解决的是同一个问题。然而每一个子领域的人，却都说自己的问题在本质上是不一样的，然后号称自己是那个子领域的鼻祖。甚至有人在20多年的时间里，制造出一代又一代的PhD和教授职位。他们的理论一代一代的更新，最后却无法解决实际的问题。所谓的“控制流分析”（control-flow analysis，CFA），就是这样的一个子领域。

公司里的PL人：过度工程

PL人在学校里跟着教授炒冷饭，毕业进入了公司之后，他们的行为方式还是非常类似。他们喜欢在公司里做的一件事情，叫做“过度工程”。本来很直接，很容易解决的一个问题，非要给你扯到各种炫酷的PL名词，然后用无比复杂的方案来解决。

有一些PL人喜欢推广他们认为高大上的语言，比如Haskell，OCaml，Scala等。这些语言在PL学术界很受尊重，所以他们以为这些语言能够奇迹般的解决实际的问题，然而事实却不是这样的。事实是，这些学术界出来的语言，其实缺乏处理现实问题的机制。为了能够在学术上证明程序的所谓“正确性”，这些语言往往被设计得过于简单，过于具有约束性。

最后，你发现用这些语言来写代码，总是这也不能做，那也不能做，因为你要是那么做了，编译器就无法发现它们自称可以发现的“类型错误”。到最后你发现，这些语言的约束，其实是无需有的。如果放宽这些约束，其实可以更优雅，更简单的对问题进行建模。对正确性的过分关注，其实导致了PL人选择蹩脚的语言，写出绕着弯子，难以理解的代码。

还有一类PL人，喜欢设计不必要存在的语言。因为他们认为设计语言是PL人的“特殊能力”，所以随时随地都想把问题往“语言设计”的方向上靠。这样的趋势是非常危险的，因为像我这样真正有原则的PL高手，其实都明白一条重要的原则：不到万不得已的时候，千万不要制造语言。

很多PL人在公司里盲目的制造新的语言，导致的问题是，到最后谁也无法理解这种新语言写出来的代码。这一方面是新的语言必然导致的结果，另一方面是由于，并不是每一个PL人都有很好的“品味”。比如有些PL人，可能盲目的模仿Go语言，Haskell或者Python的特性，设计出非常蹊跷难用的语法。这些新的语言，其实让其他人苦不堪言。最后你发现，他们声称新语言能解决的问题，其实用像Java一样的老语言，照样可以很容易的解决。

喜欢钻牛角尖，把问题搞复杂，就是很多公司里的PL人的共同点。