Зачем кому-то вкладывать время в Microsoft «Рослин»?

37

Я только что прочитал некоторые официальные документы и примеры от Microsoft "Roslyn", и концепция кажется очень интересной. Из того, что я могу сказать, он открывает черный ящик, являющийся компилятором, и предоставляет интерфейс, который мы можем использовать для получения информации и метрик о коде, написанном в Visual Studio.

Похоже, что у Roslyn есть возможность «писать сценарии» кода и компилировать / исполнять его «на лету» (аналогично CodeDom), но в моем опыте я сталкивался только с ограниченным использованием этого типа функций.

Хотя элемент анализа кода и метрик является интересным пространством ... он существует очень давно, и есть многочисленные провайдеры, которые уже вложили много денег в инструменты анализа кода и рефакторинга (например, ReSharper, CodeRush). , nCover и т. д.), и они делают это довольно хорошо!

Почему любая компания изо всех сил старается внедрить что-то, что может быть предоставлено за небольшую плату, купив лицензию на один из существующих инструментов?

Может быть, я упустил некоторые ключевые функции проекта Roslyn, которые размещают его вне домена упомянутых инструментов ...

Ричард Хупер
источник
4
Суть Roslyn в большей степени заключается в стажере Microsoft - создании простого расширяемого управляемого компилятора C #. Таким образом, команда может легче внедрить и опробовать новые языковые функции. Также внедрение новых алгоритмов оптимизации станет проще.
JustAnotherUserYouMayKnowOrNot
1
Да, Пенфолд - я подозреваю, что вы, возможно, пропустили несколько вещей. Вы смотрели интервью Дастина Кэмпбелла на 9 канале? channel9.msdn.com/Events/Ch9Live/…
Джеймс Снелл
3
Это риск разработки удачных / прибыльных надстроек к продуктам Microsoft, они могут включить его в следующую версию.
Джеффо
10
Кроме того, вы можете быть уверены, что ребята из ReSharper обманывают себя при мысли о дополнительной функциональности, которую они могут подключить. Да, они написали анализатор / анализатор C #, но цена за функцию значительно упадет, если они смогут использовать актуальный движок MS C #.
Двоичный беспорядок
2
Проверьте скриптки для интересного использования Roslyn. github.com/scriptcs/scriptcs
Эшли Дэвис,

Ответы:

53

Похоже, что у Roslyn есть возможность «писать сценарии» кода и компилировать / исполнять его «на лету» (аналогично CodeDom), но в моем опыте я сталкивался только с ограниченным использованием этого типа функций.

Компиляция и исполнение на лету является ключевым преимуществом Roslyn. Я думаю, что вы, возможно, недооцениваете преимущества этой функции, потому что вы никогда не сталкивались с примером использования в своем опыте, где он действительно сияет. И это имеет смысл; потребность в динамической компиляции, вероятно, является нишевой функцией, но ее наличие обеспечивает некоторые мощные приложения, которые были бы намного сложнее без нее.

Вот несколько примеров из головы, где динамическая компиляция была бы весьма полезна. Есть и другие способы выполнить все эти вещи, но Рослин делает их проще.

  • Наличие файлов плагинов, которые загружаются во время выполнения, компилируются и включаются в выполнение «родительского» приложения.
  • Создание DSL, который затем транслируется в C # во время выполнения и компилируется с использованием Roslyn.
  • Создание ориентированного на программиста приложения, которое принимает C #, анализирует его, переводит и т. Д.
  • Сравнение двух частей кода на предмет их различий после компиляции, а не просто «поверхностных» различий, таких как пробелы. Это известно как Semantic Diff .

Итак, подведем итог: вы можете никогда не найти применения Roslyn, в зависимости от того, какое программное обеспечение вы тратите на написание своего времени. Тем не менее, есть много вариантов использования, где Roslyn приносит много на стол. Ни один из упомянутых вами инструментов не предоставляет эту функцию. И при этом они не могли основываться на их архитектуре и цели.

RationalGeek
источник
+1 для семантической разницы Для интереса вот ссылка на разрабатываемый коммерческий продукт, который использует Roslyn для семантического сравнения. (Полное раскрытие - я не имею к ним никакого отношения, я только что увидел их продукт в блоге Джона Скита )
MarkJ
@RationalGeek - Спасибо за примеры, я не рассматривал пример маршрута DSL => C # ... Я могу представить несколько вариантов, где это было бы очень полезно в бизнес-приложениях. Многие другие примеры, которые я видел (не только ваш), во многом совпадают с инструментами рефакторинга, которые я упоминал ранее. Другая часть моего первоначального вопроса состояла в том, почему кто-то вкладывает деньги в разработку инструментов для выполнения этого анализа, когда есть какой-то превосходный, предварительно свернутый за небольшую часть стоимости ... но я предполагаю, что всегда есть место для другого (надеюсь, лучше) набор инструментов! :)
Ричард Хупер
@Penfold всегда есть место для новых инструментов для разработчиков ... :-)
RationalGeek
1
Семантическая разница не только для целей компиляции. Каждая система контроля версий нуждается в разнице, и большинство использует глупую разность. Просто поменяйте местами 2 функции и посмотрите, как устроен беспорядок, когда разница считает, что она может соответствовать нескольким (и {.
MSalters
Вот один из них: автоматическая перекомпиляция при написании приложений ASP.NET БЕЗ необходимости перестраивать и повторно развертывать веб-приложение. Наконец, объявленный в ASP.NET vNext, он в буквальном смысле сделает работу в C # такой же, как язык сценариев ... за исключением того, что он безопасен для типов и является производительным. Я рассматриваю это как самое начало этого общего подхода, в конечном итоге он перейдет к приложениям с расширенными возможностями (мобильным, настольным), чтобы вы могли изменить свой код во время выполнения. С веб-приложениями намного проще, так как по определению каждый запрос не имеет состояния, но со временем он попадет и в другие архитектуры приложений.
Marchy
12

Я уверен, что компании, которые предоставляют инструменты (например, JetBrains *), очень заинтересованы в Roslyn. Microsoft хочет упростить создание инструментов, потому что хорошие инструменты стимулируют использование экосистемы Microsoft.

* Согласно блогу JetBrains ( эта запись ), JetBrians объявили, что они не будут использовать Roslyn. Однако я полагаю, что любые новые конкуренты JetBrains (у которых нет уже существующей базы кода для работы) будут использовать Roslyn; это дает им преимущество.

Вопрос 6 в 10 Вопросах, 10 Ответах на Roslyn :

6: Каковы некоторые из практических применений для Roslyn? Как это поможет мне как разработчику?

Одним из первых примеров использования Roslyn является механизм бизнес-правил. До Roslyn оценка пользовательских макросов обычно заключалась в реализации Visual Basic для приложений (VBA), обращении к DLR с выражениями Ruby или при передаче в компилятор командной строки с динамически генерируемым кодом Visual Basic или C # и получении результата выполнения. этот код. Эти методы были не идеальными.

Roslyn легко разрешит динамическую компиляцию и выполнение кода C # и (в конечном итоге) кода Visual Basic с функцией Evaluate (), как продемонстрировала статья Эрика Фогеля «Использование API сценариев Roslyn в C #». Пользовательские макросы, написанные на том же языке, что и приложение, облегчат разработчикам поддержку пользовательских макросов, представляющих бизнес-правила.

Рефакторинг кода становится намного проще с Roslyn. До появления Roslyn разработчики таких инструментов, как DevExpress CodeRush и Refactor Pro и JetBrains ReSharper, должны были воссоздать большую часть операций компилятора в качестве основы для своих продуктов. С Roslyn разработчики рефакторинга могут напрямую воспользоваться существующими возможностями компилятора. Я могу представить себе появление пакетов NuGet для установки индивидуальных правил рефакторинга, когда Roslyn станет широко доступным.

Брайан
источник
4
«Пользовательские макросы, написанные на том же языке, что и приложение, облегчат разработчикам поддержку пользовательских макросов, представляющих бизнес-правила». - Что возможно могло пойти не так!
gbjbaanb
10

Я с нетерпением жду того дня, когда все компиляторы будут регулярно предлагать компилятор как услугу (CaaS). Нам нужно перестать думать, что компиляторы испускают только код перед компоновщиком, и начать думать, что компиляторы испускают деревья, которые могут быть преобразованы в несколько целей. Все компиляторы должны иметь возможность генерировать деревья и, необязательно, JSON / XML. Затем выходные данные могут быть преобразованы во многие типы целей, такие как украшенный один и тот же язык, C, исходный код IL, двоичный код IL, Java, Javascript, LLVM, исполняемый файл PIC и даже код предварительного компоновщика.

Я пишу компиляторы для жизни. Мои клиенты продаются на CaaS, потому что это открывает путь к фантастической гибкости, мобильности и анализу.

Я очень разочарован тем, что Microsoft давно не внедрила CaaS. Например, его можно было бы использовать в качестве пути миграции для VB6 к чему-либо другому или .Net к C ++.

BSalita
источник
1

Простой ответ на вопрос, почему MSFT инвестирует в Roslyn, заключается в том, что их существующей кодовой базе для компилятора C # сейчас 5 версий - 11 лет. Это долгое время для любой кодовой базы, чтобы оставаться управляемым. Кроме того, поскольку они переписывают, они решили инвестировать в это, чтобы все его внутренние компоненты были представлены в виде API.

Джон Таслер
источник