Навіщо хтось вкладати час у Microsoft «Рослін»?

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

Рослін також, здається, має можливість "скриптувати" код і компілювати / виконувати його на льоту (подібно до CodeDom), але я натрапив на обмежене використання для цього типу функціональних можливостей.

У той час як аналіз коду та метрики елемент цікавий простір ... це те, що існує вже дуже давно, і є численні постачальники, які вже вклали багато грошей у інструменти аналізу коду та рефакторингу (наприклад, ReSharper, CodeRush , nCover тощо), і вони роблять це досить непогано!

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

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

Рослін також, здається, має можливість "скриптувати" код і компілювати / виконувати його на льоту (подібно до CodeDom), але я натрапив на обмежене використання для цього типу функціональних можливостей.

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

Ось кілька прикладів у верхній частині моєї голови, де динамічна компіляція була б дуже корисною. Є й інші способи досягти всіх цих речей, але Рослін робить їх легшими.

• Маючи файли плагінів, які завантажуються під час виконання, компілюються та включаються до виконання програми "батьків".
• Створення DSL, яке потім переводиться на C # під час виконання та компілюється за допомогою Roslyn.
• Створення програмно-орієнтованої програми, яка бере C #, аналізує її, перекладає тощо.
• Порівнюючи два фрагменти коду за їх відмінностями після компіляції, на відміну від просто «поверхневих» відмінностей, таких як пробіли. Це відоме як семантична різниця .

Отже, підводячи підсумок, ви, можливо, ніколи не знайдете застосування для Рослін, залежно від того, на яке програмне забезпечення ви витрачаєте час на написання. Однак є чимало випадків використання, коли Рослін приносить багато до столу. Жоден із згаданих вами інструментів не забезпечує цю функцію. Вони також не могли базуватися на їх архітектурі та призначенні.

Я впевнений, що компанії, які надають інструменти (наприклад, JetBrains *), дуже зацікавлені в Росліні. Microsoft хоче полегшити виготовлення інструментів, оскільки хороший інструмент заохочує використання екосистеми Microsoft.

* У блозі JetBrains ( цей запис ) JetBrians оголосив, що не користуватиметься Рослін. Однак я гадаю, що будь-які нові конкуренти JetBrains (у яких не існує попередньої кодової бази для роботи) використовуватимуть Roslyn; це дає їм початок.

Запитання 6 з 10 питань, 10 відповідей на Рослін :

6: Які практичні користі використовує Рослін? Як це допоможе мені як розробнику?

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

Рослін легко дозволить динамічну компіляцію та виконання C # та (зрештою) коду Visual Basic з функцією Evaluate (), як продемонстрував статтю Еріка Фогеля "Використання API сценарію Roslyn у C #". Користувацькі макроси, написані на тій же мові, що і додаток, полегшать розробникам підтримку макросів користувачів, що представляють бізнес-правила.

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

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

Я пишу компілятори на життя. Мої клієнти продаються на CaaS, тому що це відкриває двері до фантастичної гнучкості, портативності та аналізу.

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

Проста відповідь, чому MSFT інвестує в Рослін, полягає в тому, що їх наявна база коду для компілятора C # вже має 5 версій - 11 років. Це довгий час, щоб будь-яка база даних залишалася керованою. Плюс, оскільки вони переписують, вони вирішили вкласти гроші в це, щоб усі його внутрішні організації були викриті як API.