¿Por qué alguien invertiría tiempo en Microsoft "Roslyn"?

Acabo de leer algunos de los libros blancos y ejemplos de Microsoft "Roslyn" y el concepto parece muy interesante. Por lo que puedo decir, abre el cuadro negro que es el compilador y proporciona una interfaz que podemos usar para obtener información y métricas sobre el código escrito en Visual Studio.

Roslyn también parece tener la capacidad de "codificar" el código y compilarlo / ejecutarlo sobre la marcha (similar al CodeDom), pero en mi experiencia solo he encontrado usos limitados para ese tipo de funcionalidad.

Si bien el elemento de análisis de código y métricas es un espacio interesante ... es algo que ha existido durante mucho tiempo y hay numerosos proveedores que ya han invertido mucho dinero en herramientas de análisis de código y refactorización (por ejemplo, ReSharper, CodeRush , nCover, etc.) y hacen un buen trabajo.

¿Por qué una empresa haría todo lo posible para implementar algo que se puede proporcionar a una fracción del costo mediante la compra de una licencia para una de las herramientas existentes?

Tal vez me haya perdido alguna funcionalidad clave del proyecto Roslyn que lo coloca fuera del dominio de las herramientas mencionadas ...

Roslyn también parece tener la capacidad de "codificar" el código y compilarlo / ejecutarlo sobre la marcha (similar al CodeDom), pero en mi experiencia solo he encontrado usos limitados para ese tipo de funcionalidad.

La compilación y ejecución sobre la marcha es el beneficio clave de Roslyn. Creo que puede estar subestimando el beneficio de esta característica porque nunca ha encontrado un caso de uso en su experiencia donde realmente brille. Y esto tiene sentido; La necesidad de compilación dinámica es probablemente una característica de nicho, pero tenerla proporciona algunas aplicaciones poderosas que serían mucho más difíciles sin ella.

Aquí hay un par de ejemplos fuera de mi cabeza donde la compilación dinámica sería bastante útil. Hay otras formas de lograr todas estas cosas, pero Roslyn las hace más fáciles.

• Tener archivos de complemento cargados en tiempo de ejecución, compilados e incluidos en la ejecución de la aplicación "principal".
• Crear un DSL que luego se traduce a C # en tiempo de ejecución y se compila con Roslyn.
• Crear una aplicación orientada al programador que tome C #, lo analice, lo traduzca, etc.
• Comparar dos fragmentos de código para sus diferencias después de la compilación, en lugar de solo diferencias "superficiales" como el espacio en blanco. Esto se conoce como diferencia semántica .

En resumen, es posible que nunca encuentres un uso para Roslyn, dependiendo del software que pases escribiendo. Sin embargo, hay muchos casos de uso en los que Roslyn aporta mucho a la mesa. Ninguna de las herramientas que menciona proporciona esta función. Tampoco podían basarse en su arquitectura y propósito.

Estoy seguro de que las empresas que proporcionan herramientas (por ejemplo, JetBrains *) están muy interesadas en Roslyn. Microsoft quiere facilitar la creación de herramientas, porque una buena herramienta fomenta el uso del ecosistema de Microsoft.

* Según el blog de JetBrains ( esta entrada ), JetBrians ha anunciado que no usarán Roslyn. Sin embargo, imagino que cualquier nuevo competidor de JetBrains (que no tenga una base de código preexistente para trabajar) usará Roslyn; les da una ventaja inicial.

Pregunta 6 en 10 preguntas, 10 respuestas sobre Roslyn :

6: ¿Cuáles son algunos de los usos prácticos de Roslyn? ¿Cómo me ayudará como desarrollador?

Uno de los primeros usos de Roslyn que viene a la mente es el de un motor de reglas de negocios. Antes de Roslyn, la evaluación de las macros de usuario generalmente implicaba implementar Visual Basic para Aplicaciones (VBA), llamar al DLR con expresiones Ruby o enviar al compilador de línea de comandos con código Visual Basic o C # generado dinámicamente y obtener el resultado de la ejecución ese código Estos métodos fueron menos que ideales.

Roslyn permitirá fácilmente la compilación dinámica y la ejecución de C # y (eventualmente) código de Visual Basic con la función Evaluar (), como lo demuestra el artículo de Eric Vogel "Uso de la API de secuencias de comandos de Roslyn en C #". Las macros de usuario escritas en el mismo idioma que la aplicación facilitarán a los desarrolladores la compatibilidad con macros de usuario que representan las reglas de negocio.

La refactorización de código se vuelve mucho más fácil con Roslyn. Antes de Roslyn, los desarrolladores de herramientas como DevExpress CodeRush y Refactor Pro y JetBrains ReSharper tuvieron que recrear gran parte de las operaciones del compilador como base para sus productos. Con Roslyn, los desarrolladores de refactorización pueden aprovechar directamente las capacidades existentes del compilador. Puedo imaginar la aparición de paquetes NuGet para instalar reglas de refactorización individuales una vez que Roslyn esté ampliamente disponible.

Espero ansiosamente el día en que todos los compiladores ofrezcan rutinariamente el Compilador como servicio (CaaS). Tenemos que dejar de pensar que los compiladores emiten solo código de preenlace y comenzar a pensar que los compiladores emiten árboles que pueden transformarse en múltiples objetivos. Todos los compiladores deben tener una función para emitir árboles y, opcionalmente, JSON / XML. La salida se puede transformar en muchos tipos de objetivos, como el mismo lenguaje embellecido, fuente C, IL, binario IL, Java, Javascript, LLVM, ejecutable PIC e incluso código de preenlace.

Escribo compiladores para vivir. Mis clientes se venden en CaaS porque abre la puerta a una fantástica flexibilidad, portabilidad y análisis.

Estoy realmente decepcionado de que Microsoft no haya implementado CaaS hace mucho tiempo. Por ejemplo, podría haberse usado como una ruta de migración para VB6 a otra cosa, o .Net a C ++.

La respuesta simple de por qué MSFT está invirtiendo en Roslyn es que su base de código existente para el compilador de C # ahora tiene 5 versiones, 11 años ahora. Eso es mucho tiempo para que cualquier base de código siga siendo manejable. Además, dado que están reescribiendo, decidieron invertir en hacerlo para que todos sus componentes internos estén expuestos como API.