歡迎光臨
每天分享高質量文章

微軟是如何使用 C# 重寫 C# 編譯器並將其開源的

Roslyn 是 C# 和 Visual Basic.NET 開源編譯器的代號。這篇文章將介紹它是如何從微軟過去的十年至暗時刻走出來,成為開源跨平臺的 C# 和 VB 公共語言引擎。

我於 2005 年加入微軟,也就是在.NET 2.0 釋出之前,當時微軟內部已經開始在討論 Roslyn 專案,這個專案是關於使用 C# 重寫 C# 編譯器。這對於一門程式語言來說是一件很正常的事情,證明語言已經開始成熟。但我們的動機則更為實際:作為 C# 的建立者,我們並沒有使用 C# 程式設計,而是用 C++!

要重寫一個使用者已經使用了好幾年的編譯器,關鍵問題在於使用者會希望新編譯器的行為方式與舊編譯器完全相同。為 C# 開發新的編譯器意味著需要匹配舊編譯器的缺陷。我說的不只是已知的缺陷,也包括那些未知的缺陷,以及開發人員已經發現並嚴重依賴的無意識行為,這些通常是在不知情的情況下發生的。

多年來,這些挑戰導致我們無法開始這個專案。

雖然使用 C# 編寫新的 C# 編譯器會給語言團隊本身帶來很多好處,但這樣能給使用者也帶來價值嗎?新編譯器如何給現有的使用者帶來幫助?也許唯一關心是否使用 C# 編寫 C# 編譯器的人就是編譯器開發團隊本身。

但與此同時,我們面臨著另一個越來越嚴重的問題:基於 C# 的不同工具之間的存在大量的重覆性工作。除了編譯器,我們的姐妹團隊在為 Visual Studio 提供 C# IDE 支援,他們必須透過編寫大量的程式碼(他們當時主要也是在用 C++)來理解 C# 的語法和語意。

除此之外,還有很多來自微軟和其他公司的工具,如 StyleCop、CodeRush,等等。這些工具都需要實現與 C# 原始碼文字相關且對使用者來說有意義的功能,並且都存在一些微妙的錯誤。它們對一些概念的理解處於不同的水平上,而且需要做出不同的折中和權衡。所有人都需要花費大量的精力來理解程式碼。

最後,我們提出了我們的價值主張:我們只需要一個 C# 程式碼庫,並把它共享給任何一個想要基於程式碼庫構建工具的人!可用工具的增加將給使用者帶來價值,特別是現有工具質量的提升。我們將語言正確性和效能方面的需求集中在同一個程式碼庫上,並努力提升質量以及新增大量的功能。我們將會構建出一個語言引擎!這將為 C# 程式碼提供統一的公共 API:我們將重新定義“編譯器”的含義。

當然,既然你在為 C# 社群構建 API,它就應該是使用 C#實現的.NET API。因此,使用 C#“引導”C# 的老想法藉助這個機會得到了實現。

可以說,Roslyn 的誕生就是始於這種開放的心態:向世界開放 C# 語言的內部開發工作。在微軟的封閉文化中,這本身就是一個大膽的主張:我們會免費分享這個智慧財產權嗎?我們會助力那些工具開發商更好地與我們展開競爭嗎?

我們希望增強生態系統併成為世界上最好的工具語言的想法最終贏得了勝利。我們想要的是 C# 和.NET 的長期增長,而不是為了短期變現和保護微軟資產。因此,雖然說不上是開源,承擔 Roslyn 專案的成本和風險對於微軟來說也是一個重大的抉擇。

當然,你不一定只是構建這些東西。Roslyn 有著雄心勃勃的願景,充滿了技術挑戰,我們花了五年時間才實現。

在我們構建初始版本時,Roslyn 仍然是一個閉源專案。從 2009 年專案啟動以來,我們一直希望我們的編譯器是開源的,但微軟還沒有為開源做好準備。開發私有程式碼並提交專利的文化代表了微軟自 20 世紀 70 年代以來的工作方式——雖然變革已經在悄然發生,但速度比我們團隊所希望的要慢。

事實上,曾經有一段時間,我們感覺公司正朝著完全相反的方向發展。

Windows 8 專案幾乎佔據了整個公司的資源。因為採用了新的程式設計模型,其觸角已經觸及到開發者工具和語言團隊的內部,所有的東西都被極端地保護起來,而且不僅僅針對外部,甚至也針對公司內部。例如,我們當時開發的非同步功能融合到 Windows 8 的程式設計模型中,我甚至不敢在內部發表設計說明,因為擔心會意外洩漏有關 Windows 8 的資訊讓自己陷入麻煩之中!這給創新造成了一個糟糕的環境,對於我們開放 C# 編譯器的願望來說,這當然不是什麼好兆頭。

最終,在 Windows 8 步入正軌之後,微軟開始轉型並找到了新的方向。它的核心理念變得與原來完全不一樣了,也就是我們今天所知道的微軟。開源運動現在開始在微軟內部佔據一席之地。

F# 已於 2010 年釋出,基於開源許可,並提供了自己的基礎——F# Software Foundation。圍繞它而成長起來的一個充滿活力的社群讓我們所有人都感到羨慕。我們的團隊強烈要求為 Roslyn 提供開源許可,最後,在公司範圍的出現了一個致力於實現這一標的的基礎設施。

2012 年,微軟成立了 Microsoft Open Tech,一個專門關註開源專案的組織。Roslyn 轉到了 Microsoft Open Tech 之下,並正式成為開源軟體。Roslyn 是一個非常適合開源的候選專案:開發者都是內部有名的開發者,而且專案本身很獨立,沒有太多的依賴,不太有可能造成許可衝突。

2014 年 4 月,在舊金山舉行的微軟“Build”開發者大會上,Anders Hejlsberg 將 Roslyn 作為開源專案進行展示,並於 4 月 3 日基於 Apache 2.0 許可釋出在了 CodePlex(微軟之前的開源託管平臺)上。

與此同時,.NET Foundation 成為包括 Roslyn 在內的.NET 專案的家。

開放為微軟帶來了是一股清新的空氣!在我們開始從 CodePlex 的開放性中獲得好處的同時,微軟也理順了其餘的開源障礙。今天,開源已經成為我們團隊工作的一個直接且不可或缺的部分。

此外,在其他方面,微軟意識到我們不需要控制一切。很明顯,我們可能不需要 CodePlex 了,Roslyn 加入到了從 CodePlex 遷移到 GitHub 的專案行列,GitHub 是當時事實上的開源之家。不僅僅是原始碼,就連構建過程都搬到了 GitHub 上:它不只是個釋出程式碼的地方,我們把它當成工作的地方。

C# 語言設計和編譯器實現的流程現在是完全開放的,有很多微軟以外的物體或個人參與,包括由外部貢獻者構建的全語言功能。C# 的價值是巨大的,不僅僅在於透過新增新功能和錯誤修複來發展專案,還包括我們透過開源提供的即時反饋閉環來獲得見解和發展路線修正。

這是一段漫長而瘋狂的旅程,在我看來,這是微軟在過去十年中所經歷的一個巨大的變化。Roslyn 從至暗時刻走出來,開放思想讓它茁壯成長,並透過開源的力量演化成了現在這種具有廣泛用途的專案。

Roslyn 和 C# 語言設計相關資源:

https://github.com/dotnet/roslyn

https://github.com/dotnet/csharplang

檢視英文原文:https://medium.com/microsoft-open-source-stories/how-microsoft-rewrote-its-c-compiler-in-c-and-made-it-open-source-4ebed5646f98

原文地址:https://www.infoq.cn/article/O9Gb9hGfpR2yEX_T2zto


.NET社群新聞,深度好文,歡迎訪問公眾號文章彙總 http://www.csharpkit.com


 

    閱讀原文

    贊(0)

    分享創造快樂