微软是如何重写C#编译器并使它开源的

译者：王亮
作者：Mads Torgersen (C# Language PM at Microsoft)
原文：http://t.cn/EPOG96O

译者的一些话：

看了大家的评论，有园友说我翻译的不好，这我是认同的。我必须得承认，我翻译的确实很生硬，这点我自己也能很明显得感觉得到。以前没有翻译过文章，这个国庆期间翻译了几篇，发现还是挺吃力的，容易理解的英文句子组合成中文总觉得别扭，我的经验和水平还有待很大的提高。非常真诚地感谢大家给出的反馈，这是对我最好的鞭策，以后一定努力给大家带来优质的内容。

Roslyn 是 C# 和 Visual Basic.NET 的开源编译器的代号。以下是它如何在过去十年微软公司最暗淡的环境中开始，并成为开源、跨平台、公共语言引擎的，这一切都是为了 C#（和 VB，下文同）。

当我在 2005 年加入微软的时候，第一次谈话就开始讨论了关于 Roslyn 将来会是什么样子——那时还是 .NET 2.0 发布之前。那次谈话是关于用 C# 重写 C#。这是编程语言的一种常规做法，是语言成熟一个标志证明。但是还有一个更实际和重要的动机：我们作为 C# 的创造者并不是用 C# 编程，而是用 C++ 编程！每天用 C# 工作让你对 C# 有不同的看法：这是“dogfooding”的力量。（译注：dogfooding 是内部试用或内部测试的意思。）

客户依赖新编译器的行为与旧编译器将完全相同。为 C# 编写新的编译器意味着尝试 bug-for-bug 地适配旧的编译器 。

重写客户多年来一直掌握的编译器的挑战在于，这些客户对新编译器的依赖行为与旧编译器完全相同。为 C# 编写新的编译器意味着尝试 bug-for-bug 地匹配旧的编译器。我说的不只是已知的 Bug，而是那些开发人员发现并开始依赖的未知和无意的行为，这些行为常常是在不知不觉中发生的。

多年来，这一挑战的巨大规模甚至阻止了我们开始这个项目。

另外，虽然使用 C# 编写的新 C# 编译器在语言团队内部会有很多好处，但对客户的价值主张更具挑战性：新的编译器如何帮助现有客户？也许唯一关心用 C# 编写 C# 的人是编译器团队的成员。

与此同时，另一个问题却越来越大：基于 C# 代码工作的不同工具之间的重复劳动。除了编译器，我们的隔壁团队还在 Visual Studio 中构建对 C# 的 IDE 支持，他们也需要编写大量的代码(当时也是用 C++ 编写的)来理解 C# 语法和语义。

除此之外，还有越来越多的来自微软和其他公司的工具，如 StyleCop, CodeRush 等，所有这些工具都必须从简单的 C#源码文本开始实现有意义的基于代码的工具。所有这些都有微妙和不同的 Bug，不同的理解层次，不同的妥协和权衡。所有的一切都将花费大量的精力来重新开始：理解代码。

到这，最后是我们的价值主张：只需世界上有一个理解 C# 的代码库，每个想在代码之上构建工具的人都可以共享它！

到这，最后是我们的价值主张：只需世界上有一个理解 C# 的代码库，每个想在代码之上构建工具的人都可以共享它！客户的价值将来自于可用工具的增加，特别是现有工具的质量。我们将把所有的语言正确性和性能需求都放在一个代码库上，并花费一次精力使其具有一流的质量和广泛的通用性。我们将建立一个语言引擎！C# 代码的统一公共 API：我们将重新定义“编译器”的含义。

当然，一旦你为庞大的 C# 社区构建了一个 API，那么它应该是一个用 C# 中实现的 .NET API，这是一种 slam-dunk（译注：指有大回报的行为）。因此，用 C# 中实现“启动”C#的旧梦想几乎只是一个偶然的附带好处。

Roslyn 诞生于一种开放的思想：共享 C# 的内部工作机制，让世界以编程的方式消费。这本身就是一个大胆的步骤，在这个仍然普遍封闭的文化中。

Roslyn 诞生于一种开放的思想：共享 C# 的内部工作机制，让世界以编程的方式消费。这本身就是一个大胆的步骤，在微软这个仍然普遍封闭的文化中：我们会免费分享这些知识产权吗？我们会授权那些不所于我们的工具制造商更好地与我们竞争？

关于加强生态系统和成为地球上最好的工具语言的辩论使我们赢得了今天成就。它们关注的是 C# 和 .NET 的长期增长，而不是微软的短期盈利和资产保护。因此，即使没有提到开源，注册 Roslyn 项目的成本和风险对微软来说也是一个巨大而大胆的步骤。

当然，你不能只做这样的东西。Roslyn 的设想雄心勃勃，也充满了技术挑战，我们花了五年时间才实现，但这是后面的故事。

自从 2009 年正式开始这个项目以来，我们就有了让编译器开源的想法，但是微软还没有准备好。

在我们构建初始版本的大部分时间里，Roslyn 仍然是一个闭源项目。自从 2009 年正式开始这个项目以来，我们就有了让编译器开源的想法，但是微软还没有准备好。在你的原始代码周围进行私有开发和申请专利的文化代表了微软自 20 世纪 70 年代以来的工作方式——尽管变化正在发生，但它发生的速度比我们团队希望的要慢。

事实上，有一段时间，公司似乎在朝着完全相反的方向发展。

Windows 8 项目基本上占据了整个公司。凭借其新的编程模型，它的触角深入到开发工具和语言团队，所有事情都笼罩在极度机密之中，不仅是对外部，甚至也对公司内部亦是如此。例如，我们当时正在开发的 async 特性与 Windows 8 编程模型是协调的，我甚至不敢在内部发布它的设计说明，因为我害怕不小心泄露了 Windows 8 的信息，这会给我带来麻烦！这为创新创造了一种可怕的氛围，这显然对我们开源 C# 编译器的希望来说并不是一个好兆头。

最终，在 Windows 8 运行完毕后，微软开始转型，找到了新的方向，朝着新的领导班子和非常不同的核心理念前进：我们今天所知道的微软。开源运动现在迅速在微软内部生根发芽。

F# 已于 2010 年发布，拥有开源许可和自己的基金会——F# 软件基金会。在它周围成长起来的充满活力的社区很快成为我们大家羡慕的对象。我们的团队大力推动为 Roslyn 提供开源生产许可证，以至最终在公司范围内的基础设施得以实现。

到 2012 年，微软创建了 Microsoft Open Tech：专门关注开源项目的组织。Roslyn 在微软开放技术公司的领导下，正式成为开源软件。开源是它的一个强有力的候选：开发资源都是内部的和众所周知的，并且项目本身独立存在，没有多少可能产生许可冲突的依赖关系。

2014 年 4 月，在旧金山举行的微软开发者构建大会上，Anders Hejlsberg 展示了 Roslyn 是一个开源项目，而 Roslyn 是在 Apache 2.0 许可下通过 CodePlex（已经退役的微软开源托管平台）发布的。

与此同时，.NET 基金会被宣布为 .NET 项目的大本营，包括 Roslyn。

开源是一股清新的空气！尽管我们已经开始从 CodePlex 上获得开源的好处，但微软仍然存在一些程序上的开放源码障碍。今天，开放源码是我们在团队中工作的一个直接而完整的部分。

我们不再把 GitHub 当作一个出版场所——它只是我们工作的地方。

另外在其他方面，公司确实意识到我们不需要控制一切。很明显，CodePlex 出现在世界上并没有什么好的理由，Roslyn 加入了其他的项目，从 CodePlex 迁移到 GitHub，那时它实际上就是开源项目的大本营。不仅源代码，而且构建它的过程也都在 GitHub 上：我们不把它当作发布场所——它只是我们工作的地方。

C# 语言设计和编译器实现过程现在是完全开放，有很多非微软的人参与，包括外部贡献者构建的整个语言特性。C# 的价值与日俱增，不仅体现在功能和 Bug 修复的贡献，更体现在我们通过开放源码提供的即时、每日循环反馈所获得的洞察和过程的改进。

这是一个漫长而疯狂的旅程，对我来说，这是微软在过去十年经历的巨大变化的象征。Roslyn 的“金块”是在黑暗中诞生的，它是在开放思想的基础上发展起来的，如今通过开放源码的力量，它已经有了上百万种不同的用途。

你想亲自探索 Roslyn，或致力于 C# 语言设计吗？请访问：

https://github.com/dotnet/roslyn
https://github.com/dotnet/csharplang