Dlaczego ktoś miałby inwestować czas w Microsoft „Roslyn”?

Właśnie czytałem niektóre białe księgi i przykłady z Microsoft „Roslyn” i koncepcja wydaje się bardzo interesująca. Z tego, co mogę powiedzieć, otwiera czarną skrzynkę, która jest kompilatorem i zapewnia interfejs, którego możemy użyć do uzyskania informacji i metryk dotyczących kodu napisanego w Visual Studio.

Wydaje się, że Roslyn ma także możliwość „skryptowania” kodu i kompilowania / wykonywania go w locie (podobnie jak CodeDom), ale z mojego doświadczenia spotkałem się tylko w ograniczonym zakresie dla tego rodzaju funkcjonalności.

Chociaż element analizy i metryk kodu jest interesującą przestrzenią ... istnieje już od bardzo dawna i istnieje wielu dostawców, którzy zainwestowali już dużo pieniędzy w narzędzia do analizy i refaktoryzacji kodu (np. ReSharper, CodeRush , nCover, itp.) i robią to całkiem nieźle!

Dlaczego którakolwiek firma miałaby się starać wdrożyć coś, co można by zaoferować za ułamek kosztów, kupując licencję na jedno z istniejących narzędzi?

Może przegapiłem kluczową funkcjonalność projektu Roslyn, która umieszcza go poza domeną wspomnianych narzędzi ...

Wydaje się, że Roslyn ma także możliwość „skryptowania” kodu i kompilowania / wykonywania go w locie (podobnie jak CodeDom), ale z mojego doświadczenia spotkałem się tylko w ograniczonym zakresie dla tego rodzaju funkcjonalności.

Kompilacja i wykonywanie w locie to podstawowa zaleta Roslyn. Myślę, że możesz nie doceniać korzyści płynących z tej funkcji, ponieważ nigdy nie spotkałeś się z przypadkiem użycia, w którym naprawdę świeci. I to ma sens; potrzeba dynamicznej kompilacji jest prawdopodobnie niszową funkcją, ale posiadanie jej zapewnia pewne zaawansowane aplikacje, które bez niej byłyby znacznie trudniejsze.

Oto kilka przykładów z mojej głowy, w których kompilacja dynamiczna byłaby całkiem przydatna. Są inne sposoby na osiągnięcie tych wszystkich celów, ale Roslyn je ułatwia.

• Posiadanie plików wtyczek, które są ładowane w czasie wykonywania, kompilowane i włączane do wykonywania aplikacji „nadrzędnej”.
• Tworzenie DSL, które jest następnie tłumaczone na język C # w czasie wykonywania i kompilowane przy użyciu Roslyn.
• Tworzenie aplikacji zorientowanej na programistę, która pobiera język C #, analizuje go, tłumaczy itp.
• Porównywanie dwóch fragmentów kodu pod kątem różnic po kompilacji, w przeciwieństwie do różnic „powierzchniowych”, takich jak białe znaki. Jest to znane jako Semantic Diff .

Podsumowując, możesz nigdy nie znaleźć zastosowania dla Roslyn, w zależności od oprogramowania, które spędzasz na pisaniu. Istnieje jednak wiele przypadków użycia, w których Roslyn wnosi wiele do stołu. Żadne z wymienionych narzędzi nie udostępnia tej funkcji. Nie mogli też opierać się na swojej architekturze i celu.

Jestem pewien, że firmy dostarczające narzędzia (np. JetBrains *) są bardzo zainteresowane Roslyn. Microsoft chce ułatwić tworzenie narzędzi, ponieważ dobre narzędzia zachęcają do korzystania z ekosystemu Microsoft.

* Na blogu JetBrains ( ten wpis ) JetBrians ogłosił, że nie będzie używać Roslyn. Wyobrażam sobie jednak, że każdy nowy konkurent JetBrains (który nie ma wcześniejszej bazy kodu do pracy) użyje Roslyn; daje im to przewagę.

Pytanie 6 na 10 pytań, 10 odpowiedzi na Roslyn :

6: Jakie są praktyczne zastosowania Roslyn? Jak pomoże mi to jako programista?

Jednym z pierwszych zastosowań Roslyn, które przychodzą na myśl, jest silnik reguł biznesowych. Przed Roslyn ewaluacja makr użytkownika zwykle polegała na implementacji języka Visual Basic for Applications (VBA), wywoływaniu DLR z wyrażeniami Ruby lub wysyłaniu powłoki do kompilatora wiersza poleceń z dynamicznie generowanym kodem Visual Basic lub C # i uzyskiwanie wyniku działania ten kod. Te metody były mniej niż idealne.

Roslyn z łatwością pozwoli na dynamiczną kompilację i wykonywanie kodu C # i (ewentualnie) kodu Visual Basic za pomocą funkcji Evaluate (), jak pokazano w artykule Erica Vogela „Korzystanie z Roslyn Scripting API w C #”. Makra użytkownika napisane w tym samym języku co aplikacja ułatwią programistom obsługę makr użytkownika reprezentujących reguły biznesowe.

Refaktoryzacja kodu staje się znacznie łatwiejsza dzięki Roslyn. Przed Roslyn twórcy takich narzędzi, jak DevExpress CodeRush i Refactor Pro oraz JetBrains ReSharper musieli odtworzyć wiele operacji kompilatora jako podstawę swoich produktów. Dzięki Roslyn deweloperzy refaktoryzacji mogą bezpośrednio skorzystać z istniejących możliwości kompilatora. Mogę sobie wyobrazić wygląd pakietów NuGet do instalowania indywidualnych reguł refaktoryzacji, gdy Roslyn będzie powszechnie dostępna.

Z niecierpliwością czekam na dzień, w którym wszystkie kompilatory rutynowo oferują Compiler as a Service (CaaS). Musimy przestać myśleć, że kompilatory emitują tylko kod wstępnego linkera i zacząć myśleć, że kompilatory emitują drzewa, które można przekształcić w wiele celów. Wszystkie kompilatory powinny mieć funkcję do emitowania drzew i opcjonalnie JSON / XML. Dane wyjściowe można następnie przekształcić w wiele typów obiektów docelowych, takich jak upiększony ten sam język, C, źródło IL, IL binarny, Java, JavaScript, LLVM, plik wykonywalny PIC, a nawet kod pre-linkera.

Piszę kompilatory na życie. Moi klienci są sprzedawani na CaaS, ponieważ otwiera to drogę do fantastycznej elastyczności, przenośności i analizy.

Jestem naprawdę rozczarowany, że Microsoft nie wdrożył CaaS dawno temu. Na przykład można go użyć jako ścieżki migracji dla VB6 do czegoś innego lub .Net do C ++.

Prosta odpowiedź na pytanie, dlaczego MSFT inwestuje w Roslyn, polega na tym, że ich obecna baza kodu dla kompilatora C # ma teraz 5 wersji - 11 lat. To długi czas na zarządzanie bazami kodu. Ponadto, ponieważ przepisują tekst, postanowili zainwestować w to, aby wszystkie jego elementy wewnętrzne były widoczne jako interfejsy API.