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

37

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 ...

.net visual-studio static-analysis

— Richard Hooper
fonte

4

O ponto principal de Roslyn é mais o estagiário da Microsoft - criando um compilador C # gerenciado extensível e fácil. Dessa forma, a equipe pode implementar e experimentar novos recursos de idioma com mais facilidade. Também implementar novos algoritmos de otimização se tornará mais fácil.

— JustAnotherUserYouMayKnowOrNot

11

Sim Penfold - Eu suspeito que você pode ter perdido algumas coisas. Você assistiu a entrevista de Dustin Campbells no Channel9? channel9.msdn.com/Events/Ch9Live/…

— James Snell

3

Esse é o risco de desenvolver complementos bem-sucedidos / lucrativos para os produtos da Microsoft; eles podem colocá-lo na próxima versão.

— Jeffo

10

Além disso, você pode ter certeza de que as pessoas por trás do ReSharper estão se molhando ao pensar na funcionalidade extra que podem conectar. Sim, eles criaram um analisador / analisador de C #, mas o custo por recurso diminuirá significativamente se puderem aproveitar o mecanismo real de MS C #.

— Preocupação binária

2

Confira scriptcs para um uso interessante de Roslyn. github.com/scriptcs/scriptcs

— Ashley Davis

53

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.

— RationalGeek
fonte

+1 para diferenças semáticas. De interesse, aqui está um link para um produto comercial em desenvolvimento que usa Roslyn para diferenças semânticas. (Divulgação completa - Não tenho nenhuma ligação com eles, eu só vi seu produto mencionado no blog de Jon Skeet )

— MarkJ

@RationalGeek - Obrigado pelos exemplos, eu não tinha considerado o exemplo de rota DSL => C # ... Eu posso imaginar alguns senários em que isso seria muito poderoso em aplicativos de negócios. Muitos dos outros exemplos que eu vi (não apenas o seu) se sobrepõem muito às ferramentas de refatoração que mencionei antes. A outra parte da minha pergunta original era por que alguém investiria o dinheiro no desenvolvimento de ferramentas para realizar essa análise quando há uma excelente e pré-processada por uma fração do custo ... mas suponho que sempre haja espaço para outra (espero melhor) conjunto de ferramentas! :)

— Richard Hooper

@Penfold, sempre há espaço para novas ferramentas de desenvolvedor ... :-)

— RationalGeek

11

O diff semântico não é apenas para fins de compilação. Todo sistema de controle de versão precisa de um diff, e a maioria usa um diff estúpido. Basta trocar 2 funções e ver a bagunça feita, quando o diff achar que pode corresponder a algumas (e {.

— MSalters

Aqui está um grande problema: recompilação automática ao escrever aplicativos ASP.NET SEM ter que reconstruir e reimplementar o aplicativo web. Finalmente anunciado no ASP.NET vNext, ele literalmente tornará o trabalho em C # o mesmo que uma linguagem de script ... exceto que ele é tipicamente seguro e com desempenho. Vejo isso como o início dessa abordagem geral e, eventualmente, chegará aos aplicativos de clientes ricos (móveis, computadores) para que você possa alterar seu código em tempo de execução. É muito mais fácil com aplicativos da Web, pois, por definição, cada solicitação é sem estado - mas, com o tempo, ela também entra em outras arquiteturas de aplicativos.

— Marchy

12

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.

— Brian
fonte

4

"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." - O que poderia dar errado!

— Gbjbaanb

10

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 ++.

— BSalita
fonte

1

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.

— John Tasler
fonte