首先我特别赞同
@vczh关于大型系统的定义,而在这个定义下,他的答案似乎已经没有太多可以补充的了。但遗憾的是发现还是有很多人把这个问题看成了有哪些语言特性有助于让程序员更爽。我想说的是,其实让程序员更爽的特性,有助于开发大型系统的特性,几乎是两码事儿。
@vczh的答案很抽象,抽象的东西总是很NX的,也就是几句话能涵盖一篇十万字文章所说的东西,我没打算把这篇文章展开来。在他讨论的范畴之外,我来补充一点偏门些的东西。
1、C语系或者类C语言风格。
vczh也谈到了这一点:
如果世界上大部分人都是从lisp/scheme/ocaml/haskell开始学习的话,其实学习Haskell并没有那么难(一旦你习惯了C语言那一套你就晚了)
而事实上遗憾的是世界上大部分人都是从C语言或者很像C的语言(Java啥的)开始学习的。所以选择一个非C风格的语言,那么首先,你可能根本就招不到做这个项目所需要的人手,,,,,,
甚至于即使你选择了一个类C风格的语言,仍然可能招不到足够的人员,事实上你的选择可能只有:C、C++、C#、Java,,,,,
2、尽可能多的编译器检查。
强类型检查是最基本的,可见性(也就是封装),只读性(const、readonly、final)以及等等等等,在人和编译器之间,你应当无条件的相信后者,因为后者出错的可能性和前者完全不是一个量级的。
一个合格的程序员和菜鸟的区别就在于合格的程序员永远不会怀疑编译器错了,而是怀疑自己错了。这是无数次对编译器的误解之后得到的宝贵经验。
3、足够大官方文档和类库。
足够大的官方文档可以避免两个程序员对某个函数所实现的功能和限制理解的完全不一致,足够大的类库可以避免当你制定了一个规范的时候需要去给程序员解释为什么使用这个开源项目而不是另一个。
这些,都可以大幅降低隐性的communication cost。
4、单元测试和IDE支持。
据我的个人研究统计,人犯错的概率比机器至少高出一百倍,事实上即使写程序超过十几年,在各种语言之间转悠一会儿之后,每年总有一次犯诸如把相等运算符写成赋值运算符的错误。即使戴了合适的眼镜,偶尔也会分不清分号和冒号,以及逗号和句点。
而机器即使运行一百年,也绝对不会把赋值运算符当作相等运算符。