首先我认为，大型系统指的是，团队里面的人你认识和沟通不超过5%、没有文档就无法理解大多数人当初写那几行代码的意图、代码具有或者接近8位数行、而且需要长期维护、具有完善的自动化测试，所以制度本身和（面试、考核或certification等的）高门槛才是保证项目本身可以健康的生存下去的最重要的因素的系统。也不要以为这种代码不多，windows、office、maya、cad软件、战斗机控制程序、还有出了bug就可以吧杨利伟杀死的这些要命的程序——这些通常都复杂。完成这种系统，需要这个团队在根需求无关的、跟开发有关的几乎所有方面都实行独裁统治。
所以这种系统需要语言提供什么样的功能呢？我们知道，因为这几千万行都是同一个软件的代码，所以里面必然具有无数的互相依赖的模块，一万多人开发十几年下来，什么是什么都基本上理不清楚了。所以这个时候你做一个修改，最重要的是要保证不要把别人的代码搞烂。就算你跑完了所有自动化测试，如果存在一些东西是自动化测试所无法覆盖的，那你觉得你可以靠人肉排除来保证所有已知的、修过的bug不再出现吗？
这当然是不可能的，尽管不能100%解决问题，但是一个强大的静态分析软件是可以帮我们解决95%的问题（就是那些不能被自动化测试所覆盖的问题里面的95%）。于是这就要求这个语言必须要有一个强大的静态分析软件，或者potentially你可以写一个强大的静态分析软件。
写一个静态分析软件面临的最大的困难有两个，一个是name resolving，另一个是reference resolving。name resolving的意思就是，你得到了这个名字，你知不知道他究竟代表的是你源代码里面的哪一个函数或者变量。reference resolving的意思就是，你得到了两个指针，你知不知道运行到某一行确定的代码的时候，这两个指针是否指向同一个对象？
于是为了让静态分析软件更容易的做出来，我们需要语言本身可以让我们很轻松的分析出这两个resolving的内容。很难分析name resolving的一般是动态类型语言，譬如python、javascript、ruby这些。很难分析reference resolving的一般是带指针和引用的静态类型语言语言，譬如C/C++、java、C#这些。
我们知道，两个都容易的一般指的是那些在语法上要求你明确副作用的语言，譬如Haskell。如果世界上大部分人都是从lisp/scheme/ocaml/haskell开始学习的话，其实学习Haskell并没有那么难（一旦你习惯了C语言那一套你就晚了）。只要你招得到足够多的人，并且让那些人满足你制作出来的规章制度的话，Haskell是可以用来做大型系统的。
只不过这个事情在现实里面一般比较难满足，那name resolving和reference resolving取舍哪个好呢？因为解决reference resolving是在name resolving解决了的基础上才可以解决的，所以你只能保留name resolving。如果一个语言没有name resolving的困难，那你的静态分析软件的难度瞬间就下降了许多。根据上面的描述，这方面的代表自然是静态类型语言。
==========================================================
参考了@庄表伟 的评论，我觉得只要一个具有programming language背景的人，大概都知道什么语言的特性是在分析的时候跟name resolving或者reference resolving相关的。我可以狙击个简单的例子。
prototype：难以做name resolving
指针：难以做reference resolving，但是还好，因为那种超大的系统一般你不敢滥用指针，所以静态分析软件就算不能完全解决这个问题（本来也是无法完全解决的），也只会让他们成为corner case，落进5%里面。
dynamic dispatch：跟reference resolving有关
static dispatch：跟两者无关
pure：跟两者无关
等等。feature的列表实在是太多了，不想一个一个列出来。
============================================================
下面还有一个匿名用户提到了communication cost的问题。的确沟通成本是一个问题，但是语言根本不会对沟通成本有什么影响，因为你一个组有一万个人，就算你什么都不干，你能沟通多少东西。
还有编译时间。sqlserver这么大的程序也只需要10分钟，因此这个故事告诉我们，提高编译时间，不能靠语言，而要靠砸钱呀。你买得起一个大集群，我们微软的MSBuild就可以帮你把剩下的事情做完。
至于说C++的string和TMP这种变态，STL是不是半吊子类库我就不评论了，至于TMP——如果你不喜欢，只要你强制大家不要用，review的时候肯定会让所有用了TMP的人无法checkin，如果他们坚持使用，他们就会没有delivery，年底就会没有成绩，就会被末位淘汰，然后你就没有这种烦恼了。你想通过降低语言的自由度来起到什么帮助基本没什么用的，只要你把制度写清楚了就行了。
— 完 —
本文作者：vczh
【知乎日报】
你都看到这啦，快来点我嘛 Σ(▼□▼メ)
此问题还有 14 个回答，查看全部。
延伸阅读：
一个强大、优美的编程语言应该具备哪些特性？
在大型项目上，Python 是个烂语言吗？
