Tại sao mọi người sẽ đầu tư thời gian vào Microsoft ngay Roslyn '?

Tôi mới đọc qua một số sách trắng và ví dụ từ Microsoft "Roslyn" và khái niệm này có vẻ rất thú vị. Từ những gì tôi có thể nói, nó mở ra hộp đen là trình biên dịch và cung cấp một giao diện mà chúng ta có thể sử dụng để lấy thông tin và số liệu về mã được viết trong Visual Studio.

Roslyn dường như cũng có khả năng "viết mã" và biên dịch / thực thi nó một cách nhanh chóng (tương tự như CodeDom) nhưng tôi chỉ gặp phải những hạn chế sử dụng cho loại chức năng đó theo kinh nghiệm của tôi.

Trong khi yếu tố phân tích & số liệu mã là một không gian thú vị ... đó là một thứ đã có từ rất lâu và có rất nhiều nhà cung cấp đã đầu tư rất nhiều tiền vào các công cụ phân tích & tái cấu trúc mã (ví dụ ReSharper, CodeRush , nCover, v.v.) và họ làm rất tốt công việc đó!

Tại sao bất kỳ công ty nào sẽ cố gắng thực hiện một cái gì đó có thể được cung cấp với một phần chi phí thông qua việc mua giấy phép cho một trong những công cụ hiện có?

Có lẽ tôi đã bỏ lỡ một số chức năng chính của dự án Roslyn đặt nó bên ngoài miền của các công cụ được đề cập ...

Roslyn dường như cũng có khả năng "viết mã" và biên dịch / thực thi nó một cách nhanh chóng (tương tự như CodeDom) nhưng tôi chỉ gặp phải những hạn chế sử dụng cho loại chức năng đó theo kinh nghiệm của tôi.

Biên soạn và thực hiện nhanh chóng là lợi ích chính của Roslyn. Tôi nghĩ rằng bạn có thể đánh giá thấp lợi ích của tính năng này bởi vì bạn chưa bao giờ gặp trường hợp sử dụng trong trải nghiệm của bạn khi nó thực sự tỏa sáng. Và điều này có ý nghĩa; nhu cầu biên dịch động có lẽ là một tính năng thích hợp, nhưng việc cung cấp nó cho một số ứng dụng mạnh mẽ sẽ khó khăn hơn nhiều nếu không có nó.

Dưới đây là một vài ví dụ ngoài đỉnh đầu của tôi, nơi biên dịch động sẽ khá hữu ích. Có nhiều cách khác để thực hiện tất cả những điều này, nhưng Roslyn làm cho chúng dễ dàng hơn.

• Có các tệp plugin được tải trong thời gian chạy, được biên dịch và được bao gồm trong quá trình thực thi ứng dụng "cha mẹ".
• Tạo DSL sau đó được dịch sang C # khi chạy và được biên dịch bằng Roslyn.
• Tạo một ứng dụng định hướng lập trình viên lấy C #, phân tích nó, dịch nó, v.v.
• So sánh hai đoạn mã cho sự khác biệt của chúng sau khi biên dịch, trái ngược với sự khác biệt chỉ "bề mặt" như khoảng trắng. Điều này được gọi là khác biệt ngữ nghĩa .

Vì vậy, để tóm tắt, bạn có thể không bao giờ tìm thấy việc sử dụng cho Roslyn, tùy thuộc vào phần mềm bạn dành thời gian để viết. Tuy nhiên, có rất nhiều trường hợp sử dụng mà Roslyn mang lại rất nhiều cho bàn. Không có công cụ nào bạn đề cập cung cấp tính năng này. Họ cũng không thể dựa trên kiến ​​trúc và mục đích của họ.

Tôi chắc rằng các công ty cung cấp dụng cụ (ví dụ: JetBrains *) rất quan tâm đến Roslyn. Microsoft muốn làm cho nó dễ dàng để tạo ra công cụ, bởi vì công cụ tốt khuyến khích việc sử dụng hệ sinh thái của Microsoft.

* Theo blog JetBrains ( mục này ), JetBrians đã thông báo rằng họ sẽ không sử dụng Roslyn. Tuy nhiên, tôi tưởng tượng rằng bất kỳ đối thủ cạnh tranh mới nào với JetBrains (những người không có cơ sở mã sẵn có để làm việc) sẽ sử dụng Roslyn; nó cho họ một khởi đầu.

Câu hỏi 6 trong 10 câu hỏi, 10 câu trả lời trên Roslyn :

6: một số sử dụng thực tế cho Roslyn là gì? Làm thế nào nó sẽ giúp tôi như một nhà phát triển?

Một trong những ứng dụng đầu tiên của Roslyn xuất hiện trong tâm trí là công cụ quy tắc kinh doanh. Trước Roslyn, việc đánh giá các macro người dùng thường liên quan đến việc triển khai Visual Basic for Application (VBA), gọi ra DLR bằng các biểu thức Ruby hoặc trình bày ra trình biên dịch dòng lệnh bằng mã Visual Basic hoặc C # được tạo động và nhận được kết quả chạy mã đó Những phương pháp này ít hơn lý tưởng.

Roslyn sẽ dễ dàng cho phép biên dịch động và thực thi mã C # và (cuối cùng) Visual Basic với chức năng Evalu (), như bài viết của Eric Vogel đã trình bày "Sử dụng API Roslyn Scripting trong C #". Các macro người dùng được viết bằng cùng ngôn ngữ với ứng dụng sẽ giúp các nhà phát triển hỗ trợ các macro người dùng đại diện cho các quy tắc kinh doanh dễ dàng hơn.

Tái cấu trúc mã trở nên dễ dàng hơn nhiều với Roslyn. Trước Roslyn, các nhà phát triển của các công cụ như DevExpress CodeRush và Refactor Pro và JetBrains ReSharper đã phải tạo lại nhiều hoạt động của trình biên dịch làm nền tảng cho các sản phẩm của họ. Với Roslyn, các nhà phát triển tái cấu trúc có thể trực tiếp tận dụng các khả năng của trình biên dịch hiện có. Tôi có thể tưởng tượng sự xuất hiện của các gói NuGet để cài đặt các quy tắc tái cấu trúc riêng lẻ một khi Roslyn được phổ biến rộng rãi.

Tôi háo hức chờ đợi ngày mà tất cả các trình biên dịch thường xuyên cung cấp Trình biên dịch dưới dạng Dịch vụ (CaaS). Chúng ta cần ngừng suy nghĩ rằng trình biên dịch chỉ phát ra mã liên kết trước và bắt đầu nghĩ rằng trình biên dịch phát ra các cây có thể chuyển đổi thành nhiều mục tiêu. Tất cả các trình biên dịch nên có một tính năng để phát ra cây và tùy chọn JSON / XML. Đầu ra sau đó có thể được chuyển đổi thành nhiều loại mục tiêu như ngôn ngữ được làm đẹp, nguồn C, IL, nhị phân IL, Java, Javascript, LLVM, thực thi PIC và thậm chí mã liên kết trước.

Tôi viết trình biên dịch để kiếm sống. Khách hàng của tôi được bán trên CaaS vì nó mở ra cơ hội cho tính linh hoạt, tính di động và phân tích tuyệt vời.

Tôi thực sự thất vọng vì Microsoft đã không triển khai CaaS từ lâu. Ví dụ, nó có thể đã được sử dụng làm đường dẫn di chuyển cho VB6 sang một thứ khác, hoặc .Net sang C ++.

Câu trả lời đơn giản cho lý do tại sao MSFT đầu tư vào Roslyn là cơ sở mã hiện tại của họ cho trình biên dịch C # hiện có 5 phiên bản - 11 năm nay. Đó là một thời gian dài cho bất kỳ cơ sở mã hóa nào vẫn có thể quản lý được. Thêm vào đó, vì họ đang viết lại, họ đã quyết định đầu tư vào việc đó để tất cả các phần bên trong của nó được hiển thị dưới dạng API.