Por que alguém iria investir tempo na Microsoft "Roslyn"?

Acabei de ler alguns dos white papers e exemplos da Microsoft "Roslyn" e o conceito parece muito interessante. Pelo que sei, ele abre a caixa preta que é o compilador e fornece uma interface que podemos usar para obter informações e métricas sobre o código escrito no Visual Studio.

Roslyn também parece ter a capacidade de "codificar" o código e compilá-lo / executá-lo rapidamente (semelhante ao CodeDom), mas só encontrei usos limitados para esse tipo de funcionalidade em minha experiência.

Embora o elemento de análise e métrica de código seja um espaço interessante ... é algo que existe há muito tempo e existem inúmeros provedores que já investiram muito dinheiro em ferramentas de análise e refatoração de código (por exemplo, ReSharper, CodeRush , nCover, etc) e eles fazem um bom trabalho!

Por que alguma empresa faria o possível para implementar algo que pode ser fornecido por uma fração do custo através da compra de uma licença para uma das ferramentas existentes?

Talvez eu tenha perdido algumas das principais funcionalidades do projeto Roslyn que o colocam fora do domínio das ferramentas mencionadas ...

Roslyn também parece ter a capacidade de "codificar" o código e compilá-lo / executá-lo rapidamente (semelhante ao CodeDom), mas só encontrei usos limitados para esse tipo de funcionalidade em minha experiência.

Compilação e execução rápidas são os principais benefícios do Roslyn. Acho que você pode estar subestimando o benefício desse recurso, porque nunca encontrou um caso de uso em sua experiência, onde ele realmente brilha. E isso faz sentido; a necessidade de compilação dinâmica é provavelmente um recurso de nicho, mas, com isso, ele fornece alguns aplicativos poderosos que seriam muito mais difíceis sem ele.

Aqui estão alguns exemplos em cima da minha cabeça onde a compilação dinâmica seria bastante útil. Existem outras maneiras de realizar todas essas coisas, mas Roslyn as torna mais fáceis.

• Ter arquivos de plug-in carregados em tempo de execução, compilados e incluídos na execução do aplicativo "pai".
• Criando uma DSL que é então traduzida para C # em tempo de execução e compilada usando Roslyn.
• Criando um aplicativo orientado a programadores que utiliza C #, analisa, converte etc.
• Comparando dois pedaços de código para suas diferenças após a compilação, em oposição a apenas diferenças "superficiais", como espaço em branco. Isso é conhecido como Diff Semântico .

Portanto, para resumir, você pode nunca encontrar um uso para Roslyn, dependendo do software que você gasta seu tempo escrevendo. No entanto, existem muitos casos de uso em que Roslyn traz muita coisa para a mesa. Nenhuma das ferramentas mencionadas fornece esse recurso. Nem eles poderiam basear-se em sua arquitetura e propósito.

Tenho certeza de que as empresas que fornecem ferramentas (por exemplo, JetBrains *) estão muito interessadas em Roslyn. A Microsoft quer facilitar a criação de ferramentas, porque boas ferramentas incentivam o uso do ecossistema da Microsoft.

* Pelo blog JetBrains ( esta entrada ), a JetBrians anunciou que não usará Roslyn. No entanto, imagino que qualquer novo concorrente do JetBrains (que não possua uma base de código pré-existente para trabalhar) usará o Roslyn; isso lhes dá uma vantagem inicial.

Pergunta 6 em 10 perguntas, 10 respostas sobre Roslyn :

6: Quais são alguns dos usos práticos para Roslyn? Como isso vai me ajudar como desenvolvedor?

Um dos primeiros usos de Roslyn que vem à mente é o de um mecanismo de regras de negócios. Antes de Roslyn, a avaliação de macros de usuário envolvia a implementação do Visual Basic for Applications (VBA), a chamada para o DLR com expressões Ruby ou o envio para o compilador de linha de comando com código Visual Basic ou C # gerado dinamicamente e obtenção do resultado da execução esse código. Esses métodos eram inferiores ao ideal.

Roslyn permitirá facilmente a compilação e execução dinâmicas de C # e (eventualmente) código do Visual Basic com a função Evaluate (), conforme demonstrado no artigo de Eric Vogel "Usando a API de scripts do Roslyn em C #". As macros de usuário escritas no mesmo idioma que o aplicativo facilitarão aos desenvolvedores o suporte a macros de usuário que representam regras de negócios.

A refatoração de código se torna muito mais fácil com Roslyn. Antes de Roslyn, os desenvolvedores de ferramentas como DevExpress CodeRush e Refactor Pro e JetBrains ReSharper precisavam recriar muitas das operações do compilador como base para seus produtos. Com o Roslyn, os desenvolvedores de refatoração podem tirar vantagem diretamente dos recursos existentes do compilador. Eu posso imaginar a aparência dos pacotes NuGet para instalar regras de refatoração individuais quando o Roslyn estiver amplamente disponível.

Aguardo ansiosamente o dia em que todos os compiladores rotineiramente ofereçam o Compiler as a Service (CaaS). Precisamos parar de pensar que os compiladores emitem apenas código pré-vinculador e começar a pensar que os compiladores emitem árvores que podem ser transformadas em vários destinos. Todos os compiladores devem ter um recurso para emitir árvores e, opcionalmente, JSON / XML. A saída pode ser transformada em vários tipos de destinos, como a mesma linguagem embelezada, origem C, IL, binário IL, Java, Javascript, LLVM, executável PIC e até mesmo código de pré-vinculador.

Eu escrevo compiladores para viver. Meus clientes são vendidos no CaaS porque abre a porta para uma fantástica flexibilidade, portabilidade e análise.

Estou muito decepcionado que a Microsoft não tenha implementado CaaS há muito tempo. Por exemplo, poderia ter sido usado como um caminho de migração para o VB6 para outra coisa, ou .Net para C ++.

A resposta simples para o motivo pelo qual a MSFT está investindo em Roslyn é que a base de código existente para o compilador C # agora tem 5 versões - 11 anos agora. É muito tempo para qualquer base de código permanecer gerenciável. Além disso, como eles estão reescrevendo, eles decidiram investir para que todos os seus componentes internos sejam expostos como APIs.