刘军连看皮肤病好吗 https://m.39.net/disease/a_9393598.html“我们把所有对于语言正确性和性能的要求都集中在一份代码中，使其拥有最佳的质量和最好的多样性——我们将重新定义“编译器”这个词。”Roslyn是C#和VisualBasic.NET的开源编译器的项目名。十年来它从微软的封闭中走出来，变成现在的开源、跨平台、公开的语言引擎，支持一切使用C#的东西（包括VB，我认为它是C#带来的馈赠）。在我年加入微软的时候，有过一次关于Roslyn项目的讨论，当时刚好是.NET2.0发布前夕。那次讨论的内容是用C#重写C#。这种事情在编程语言中很常见，也是语言成熟的一个标志。但这样做还有个更现实、更重要的动机：作为C#的缔造者的我们竟然用的不是C#，而是C++！日常使用C#能改变你对C#的看法，这就是使用自家产品的好处。客户期待新的编译器行为与旧编译器完全一致。使用C#重写编译器意味着连bug都要与旧编译器完全一致。重写一个客户已使用多年的编译器有很多难点：新的编译器必须拥有完全一致的行为。编写新的C#编译器意味着连bug都要与旧编译器完全一致。而且这里说的还不仅仅是已知的bug，还有许多未知的bug和无意的编译器行为，由于被程序员发现并且利用（而且通常人们意识不到自己利用了这些行为），所以也必须原样实现才行。这种级别的难度使得我们很多年来都不敢碰这个项目。此外，尽管使用C#编写新的C#编译器可能会有很多好处，但其价值却很难展示给客户：新的编译器对现有客户有什么好处呢？也许，唯一在乎C#编译器是否用C#编写的人只有编译器团队自己了吧。但同时，另一个问题也越来越明显，即所有使用了C#代码的工具都需要进行修改，尽管这部分工作具有重复性。除了编译器之外，我们的兄弟团队在开发VisualStudio中的C#IDE支持，他们也需要写一些代码（当时也是C++代码）来理解C#的语法和语义。除此之外，微软和其他第三方如StyleCop、CodeRush等工具也越来越多，所有工具都要根据C#源代码文本实现。这些工具都有不同的bug，对C#的理解程度也不尽相同，也都做了不同的妥协和权衡取舍。这一切都需要越来越多的努力，只为了解决一个问题：理解源代码。到此，我们终于能够提出项目的价值了：全世界只需要一份理解C#的代码，任何想开发代码工具的人都可以共享这份代码！这样，客户价值就能体现在工具数量的增加，特别是现有工具的质量提高。我们把所有对于语言正确性和性能的要求都集中在一份代码中，使其拥有最佳的质量和最好的多样性。我们需要构建一个语言引擎！一个通用的、公开的C#代码API！我们将重新定义“编译器”这个词。当然，要想为广义的C#社区开发API，很显然必须开发成.NETAPI，因此要用C#实现。所以，用C#自我编译C#的梦想可以作为意外收获顺带实现了。于是，Roslyn从一个开放的思想中诞生了：将C#的内部工作共享给世界，使之可以通过程序访问。在一个无处不在封闭式文化中，这种想法是一个非常大胆的决定：我们要把知识产权无偿分享？我们要给那些不属于我们的工具开发商提供支持让他们跟我们竞争？最后我们得出的结论是：增强生态环境，使之成为全世界最好的工具语言。这是为了C#和.NET的长期增长，而不是只为了眼前的利益和保护微软的财产。所以，就算不谈开源，考虑到成本和风险，Roslyn项目的通过对于微软也是件不容易的事儿。当然，Roslyn项目并不是这么简单。Roslyn的愿景充满了野心，也充满了技术挑战，我们花了五年时间才实现。但这是另一个话题了。我们花费了很多时间来构建初始版本，而此时Roslyn依然是个闭源项目。从年早期这个项目伊始，我们就制定了将编译器开源的愿景，但微软显然还没做好准备。私下开发再提交专利，这是微软从上世纪七十年代开始一贯如此的做法。尽管现在有所改变，但改变的速度显然比我们期待的要慢得多。实际上，有段时间我们似乎觉得公司会完全走向相反的方向。Windows8项目似乎占用了整个公司的精力。随着新编程模型的出现，Windows8的触角伸到了开发工具和语言团队中，每个人都被要求高度保密，不仅要对外部保密，而且在公司内部也要保密。比如，我们当时开发的异步功能需要协调Windows8的编程模型，因此我甚至都不敢在内部发表设计上的说明，以免不小心泄露Windows8的消息给自己带来麻烦！这种氛围非常不利于创新，当然对于我们希望让C#编译器开源也不是好兆头。但最终，在Windows8完成开发之后，公司开始转变到新的方向上，新的领导团队带来了完全不同的价值观，即我们今天的微软。开源活动像雨后春笋般在微软内部生根发芽。F#于年以开源授权发布，并且成立了自己的基金会——F#软件基金会（