Cómo Microsoft reescribió el compilador de C # a C # y lo abrió

Publicado por Mads Torgersen, arquitecto jefe de C # en Microsoft

Proyecto Roslyn

Roslyn es el nombre en código que se asignó al compilador de código abierto para C # y Visual Basic.NET. El proyecto comenzó en la oscuridad más profunda de la última década de la vida corporativa de Microsoft, y terminó como un proyecto de código abierto, un motor universal público multiplataforma para C # (y VB, que daré por sentado en el resto de este artículo).

La primera charla sobre el proyecto, que más tarde se conoció como Roslyn, ya estaba en marcha cuando me uní a Microsoft en 2005, poco antes del lanzamiento de .NET 2.0. Se habló de reescribir C # a C #. Esta es una práctica normal para los lenguajes de programación: prueba de la madurez del lenguaje. Pero había una motivación más práctica e importante: nosotros, los creadores de C #, no programamos en C #, ¡programamos en C ++! Si programa en C # a diario, cambia de opinión: el gran poder de trabajar en la herramienta que está desarrollando (alimentación para perros).

Los usuarios dependen del comportamiento del nuevo compilador como el anterior. Escribir un nuevo compilador para C # es un intento de encontrar una correspondencia de error a error.

La dificultad de reescribir el compilador, que se ha utilizado activamente durante varios años, es que los usuarios dependen del comportamiento del nuevo compilador al igual que el anterior. Escribir un nuevo compilador para C # es un intento de encontrar una correspondencia de error a error. Y estoy hablando no solo de errores conocidos, sino también de errores desconocidos y formas indeseables de comportamiento que los desarrolladores han encontrado y utilizan, a menudo sin saberlo.

Durante muchos años, la magnitud de este problema ni siquiera nos permitió comenzar el proyecto.

Aunque los desarrolladores del grupo de lenguaje en Microsoft recibieron muchas ventajas del nuevo compilador de C # escrito en C #, el valor para los usuarios finales no era tan obvio: ¿cómo los beneficiará el nuevo compilador? Quizás las únicas personas a las que les importa que el compilador de C # esté escrito en C # son los propios desarrolladores del compilador.

Al mismo tiempo, otro problema se manifestó cada vez más: la duplicación de esfuerzos entre diferentes herramientas que se ejecutan en código C #. Además del compilador, otro equipo trabajó en el soporte de IDE para C # en Visual Studio, y también tuvieron que escribir mucho código (en ese momento también en C ++) para comprender la sintaxis y la semántica de C #.

Al mismo tiempo, la cantidad de herramientas de Microsoft y otras compañías, como StyleCop, CodeRush, etc., estaba creciendo: todas ellas deberían implementar un procesamiento significativo del código C #. Cada uno de estos programas tiene sus propios errores ligeramente diferentes, diferentes niveles de comprensión, varios compromisos y concesiones. Y todos ellos harían un gran esfuerzo para llegar a una comprensión común del código.

Y decidimos una propuesta importante: asegurarnos de que solo haya una base de código en el mundo: ¡una base única para todas las herramientas que funcionan con código C #!

El valor de una propuesta de este tipo proviene de un aumento en el número de herramientas disponibles, y especialmente de una mejora en la calidad de las herramientas existentes. Todos los requisitos para la corrección y el rendimiento del idioma se asignan a una única base de código. Suficiente esfuerzo para hacer una base de calidad estelar y gran versatilidad. ¡Crearemos un motor real para el idioma! API unificada y abierta para código C #. Le daremos una nueva definición al concepto de "compilador".

Por supuesto, una vez que cree una API para la comunidad C # más amplia, no hace falta decir que debería ser una API .NET implementada en C #. Entonces, el antiguo sueño de escribir C # en C # se produce casi como un efecto secundario aleatorio.

Por lo tanto, Roslyn nació de una mentalidad abierta: compartiendo el funcionamiento interno de C # para uso programático por el mundo. Eso en sí mismo fue una propuesta un poco audaz para la cultura corporativa aún bastante cerrada de Microsoft.

¿Compartiremos la propiedad intelectual de forma gratuita? ¿Potenciaremos herramientas que compitan con nosotros?

En la discusión corporativa, fuimos ayudados a ganar argumentos sobre el fortalecimiento del ecosistema y la creación de un lenguaje con las mejores herramientas del planeta. Se trataba del crecimiento a largo plazo de C # y .NET en comparación con la monetización a corto plazo y la protección de los activos de Microsoft. Por lo tanto, sin mencionar siquiera el código fuente abierto, apostar por Roslyn fue un movimiento grande y audaz para Microsoft.

Por supuesto, desarrollar algo como esto no puede ser fácil. Las perspectivas para Roslyn eran muy ambiciosas y estaban plagadas de problemas técnicos, y nos llevó cincuenta años hacer frente a todo. Pero esa es otra historia.

Durante la mayor parte del desarrollo inicial, Roslyn siguió siendo un proyecto de código cerrado.

Desde el comienzo del trabajo serio en el proyecto en 2009, tuvimos ideas para abrir los compiladores, pero Microsoft aún no estaba listo.

Microsoft ha tenido una cultura de desarrollo cerrado y protección de patentes del código fuente desde la década de 1970. Aunque los cambios fueron en el aire, fueron más lentos de lo que nuestro equipo esperaba.

De hecho, durante algún tiempo pareció que la empresa iba en la dirección completamente opuesta.

El proyecto de Windows 8 ha afectado enormemente a toda la empresa. Gracias al nuevo modelo de programación, sus tentáculos penetraron profundamente en los equipos de desarrollo de herramientas e idiomas, y todo se cubrió en extremo secreto, no solo fuera, sino incluso dentro de la empresa. Como ejemplo, la función asíncrona que estábamos desarrollando en ese momento se coordinó y se mezcló con el modelo de programación de Windows 8, y no me atrevería a publicar notas sobre su diseño incluso dentro de la empresa, por temor a filtrar accidentalmente información sobre Windows 8 y problemas en mi cabeza. ! Esto creó un clima terrible para la innovación y, por supuesto, no nos permitió confiar en el compilador de código abierto C #.

Sin embargo, al final, cuando Windows 8 siguió su propio camino, la compañía comenzó a transformarse y encontró una nueva dirección, un nuevo liderazgo y una filosofía completamente diferente: el Microsoft que conocemos hoy. El código abierto ahora se está extendiendo rápidamente dentro de Microsoft.

F # se lanzó en 2010 con una licencia abierta y su propia organización: F # Software Foundation . Se formó una comunidad sobresaliente a su alrededor, que pronto se convirtió en la envidia de todos nosotros. Nuestro equipo insistió obstinadamente en obtener una licencia gratuita para Roslyn, y, finalmente, la infraestructura corporativa permitió que esto se hiciera.

Para 2012, Microsoft creó la organización Microsoft Open Tech, que se centra específicamente en proyectos de código abierto. Roslyn se puso bajo su ala y se convirtió oficialmente en un proyecto de código abierto. Roslyn estaba bastante madura para esto: todos los recursos de desarrollo eran internos y conocidos, y el proyecto en sí no sufría una gran cantidad de dependencias que pudieran dar lugar a conflictos de licencia.

En abril de 2014, en la Build Buildpers Conference en San Francisco, Anders Halesberg presentó a Roslyn como un proyecto de código abierto , y el código fuente se publicó el 3 de abril en CodePlex (la antigua plataforma de Microsoft para repositorios) bajo la licencia Apache 2.0.



Al mismo tiempo, la Fundación .NET fue declarada la base para proyectos .NET, incluida Roslyn.

¡Este lanzamiento se ha convertido en un verdadero soplo de aire fresco! Comenzamos a cosechar los beneficios de la apertura ya en CodePlex, y luego se eliminaron los obstáculos procesales restantes para el código abierto en Microsoft, por lo que hoy el código abierto es una parte natural e integral de cómo trabajamos en muchos de nuestros equipos.

Ya no vemos a GitHub como un lugar para publicar código fuente, es solo el lugar donde trabajamos.

En otros frentes, la compañía también se dio cuenta de que no era necesario esforzarse por controlar todo. Se hizo evidente que no había una buena razón para que CodePlex existiera, y Roslyn, junto con otros proyectos, migró a GitHub, para entonces la plataforma principal de facto para proyectos de código abierto. No solo el código en sí, sino también el proceso de su creación se lleva a cabo en GitHub: ya no consideramos a GitHub como un lugar para publicar códigos fuente; este es solo el lugar de nuestro trabajo.



El diseño del lenguaje C # y la implementación del compilador ahora son procesos completamente abiertos, con una participación significativa de terceros. Crean incluyendo funciones de lenguaje completo. El valor de C # simplemente se transfiere no solo debido a la escala de los esfuerzos para escribir funciones y corregir errores, sino también debido a la comprensión y corrección del curso, que producimos gracias al bucle de retroalimentación diaria instantánea con la comunidad.

Fue un viaje largo y loco, y para mí simboliza los tremendos cambios que Microsoft ha experimentado en la última década. Roslyn Nugget nació en la oscuridad, pero creció con las ideas de apertura, y hoy explotó en un millón de usos diferentes gracias al poder del código abierto.

Aprenda Roslyn y C # Language Design:

Roslyn en github
C # en GitHub

Source: https://habr.com/ru/post/es426961/


All Articles