编程语言之争是开发者们热议的永恒话题，在不同语言的选择和设计决定上也都观点不一。那么在面对大型项目时该如何选择具体实现呢？本文的作者借课程项目之机，比较了Rust、Haskell、OCaml、C++、Python、Scala等语言编写的编译器差异，最终发现，这些语言在代码量和功能实现上简直千差万别！
作者
TristanHume
译者
弯月，责编
郭芮
以下为译文：
我在滑铁卢大学的最后一个学期选了CS：编译原理这门课程，课程项目是编写一个编译器，将Java语言的子集编译成x86代码，三人结组，语言自由选择。
这是个难得的机会，我可以在同样的大型项目下比较不同的实现，而且我的朋友们的水平也跟我很相近，所以我可以借这个机会看看不同的设计和语言选择。我从这个项目中获得了不少心得，尽管这个比较并不完美，但比那些仅靠个人观点来比较编程语言的人要好多了。
我们的编译器是用Rust写成的，首先与另一个使用了Haskell的组进行了比较。我认为他们的编译器应该更简洁，但实际的代码行数差不多。与另一个使用了OCaml的团队的比较也得到了同样的结果。然后我与一个使用了C++的团队比较，结果如我预料的那样，由于有头文件，以及缺乏汇总类型和模式匹配的支持，导致他们的编译器大了30%。下一个是跟我一个朋友的Python实现进行的比较，他的代码量不到我们的一半，这要归功于元编程和动态类型。另一个朋友的团队使用了Scala，实现的编译器代码量也小于我们。最让我惊讶的比较就是与另一个同样使用Rust的团队的比较，他们的代码量是我们的三倍，因为他们采用了不同的设计决定，这最终导致了同样的功能需要的代码量产生了巨大差异！
本文中首先我会来解释一下此次比较的意义，介绍各个项目的基本情况，然后再解释引发编译器大小差异的部分原因。最后，我会谈一谈从各个比较中学到的东西。
比较的意义
你也许会认为，代码行数（我同时比较了代码行数和字节数）是个很糟糕的度量，但我认为在这个项目中这种度量可以给出很有用的信息。在我看来，至少代码行数是各个不同的团队在同一个大型项目上工作时最可控的一个变数。
直到我们的项目完成之前，没有任何人（包括我）知道我会统计代码行数，所以没有人在行数度量上做手脚，每个人都尽最大努力来快速、正确地完成项目。每个人（除了后面我会谈到的使用Python的项目之外）都在实现同一个程序，目的只有一个，就是在同样的截止日期之前通过同样的自动化测试套件，所以也不会有某个组试图解决不同的问题，或者解决更难的问题的情况。每个组都在这个项目上花了数月的时间，大家都在逐步地添加功能，从而通过已知和未知的测试。这意味着代码整洁易读，没有任何取巧的地方。
除了要通过的课程测试之外，代码不会被用于任何其他用途，也没人会阅读它，而且由于它只能编译Java语言的一个子集，所以它也没有任何其他用途。除了标准库之外也不允许使用任何库，甚至连辅助解析的库都不允许（如果标准库中没有包含此功能的话）。这意味着也不会出现任何仅有部分团队使用的、强大的编译器库来干扰比较。
在最终的提交截止日期之后，会运行一次秘密的测试（我们看不到该测试），也就是说，自己编写测试用例并测试代码，可以保证编译器的健壮、正确，也可以处理边界情况。
尽管参与的每个人都是学生，但我讨论的这些团队都是我认为非常优秀的程序员。每个人都至少有两年全职的实习经验，大多数都在高端的科技公司，一些公司甚至还在开发编译器。几乎每个人都有7-13年的编程经验，都十分热衷在网上阅读课程之外的东西。
自动生成的代码没有统计在内，但生成的语法文件和代码被统计了。
因此我认为，就各个项目需要花费的精力，以及如果是长期项目的话需要花费多少精力去维护而言，代码量是一个很不错的近似统计。我认为，微小的差异也能反映出巨大的问题，比如上面说过的用Haskell编写的编译器代码量不到C++的一半。
Rust（比较基准）
我和团队里的另一名成员以前分别写过1万多行的Rust代码，另一个成员在某次编程马拉松项目上写过大约行Rust。我们的编译器用wc-l统计的结果是行，其中包括代码行（不包括空行和注释），wc-c的结果为kb。
我发现的一个问题是，这几项度量的比例在其他项目中也是相似的，只有一些微小的差异（过会儿我会介绍）。下文中提到代码行数时，我指的都是wc-l的结果，但上述结论表明，代码行数按照哪个规则进行统计其实是无所谓的（除非特别指出），你可以通过比例进行换算。
我写过另一篇关于设计的文章（