Project Roslyn : comment Microsoft a réécrit son compilateur C# en C# et l'a rendu open source
Le lead designer du langage raconte l'histoire

Le , par Michael Guilloux, Chroniqueur Actualités
Roslyn est le nom de code du compilateur open source pour C# et VB.NET. Mais avant de voir le jour et en plus devenir open source, ç’a été un vrai parcours du combattant. Dans un billet de blog, Mads Torgersen, lead designer de C# chez Microsoft a décidé de revenir sur les grands défis auxquels ils ont été confrontés au sein de la firme de Redmond.

Les premières conversations sur ce qui allait devenir Roslyn étaient déjà en cours lorsque Mads Torgersen a rejoint Microsoft en 2005, juste avant la sortie de .NET 2.0. « Cette conversation portait sur la réécriture de C# en C#. Ceci est une pratique normale pour les langages de programmation ; un élément de preuve de la maturité du langage. Mais il y avait une motivation plus pratique et plus importante : nous, les créateurs de C#, ne programmions pas nous-mêmes en C#, nous codions en C++ », dit-il.

Rappelons que C# est un langage de programmation orienté objet, commercialisé par Microsoft depuis 2002 et destiné à développer sur la plateforme Microsoft .NET. Il est dérivé du C++ et très proche du Java dont il reprend la syntaxe générale ainsi que les concepts, en y ajoutant des notions telles que la surcharge des opérateurs, les indexeurs et les délégués. Il est utilisé notamment pour développer des applications web sur la plateforme ASP.NET.


Mads Torgersen, lead designer de C# chez Microsoft

Les défis de la réécriture du compilateur C#

Réécrire le compilateur C# était synonyme de relever un certain nombre de défis. D'abord, pour les utilisateurs existants, cela veut dire qu'il va falloir faire correspondre le nouveau compilateur à l'ancien, bogue par bogue. « Et je ne parle pas seulement de bogues connus, mais aussi de ces comportements inconnus et inattendus que les développeurs ont trouvés et ont fini par adopter, souvent sans le savoir », explique le lead designer de C#.

Si un nouveau compilateur C# écrit en C# avait de nombreux avantages au sein de l’équipe des langages, la question était donc de savoir si ce nouveau compilateur apporterait de la valeur aux clients existants. Parce qu'en fin de compte, peut-être que les seules personnes qui voudraient que C# soit écrit en C# étaient les membres de l’équipe du compilateur.

Pendant des années, l'ampleur même de ce défi a empêché les ingénieurs de Microsoft de se lancer dans le projet. Dans le même temps, un autre problème était en train de prendre de l'ampleur : la duplication des efforts entre différents outils fonctionnant avec le code C#. « Outre l'équipe du compilateur, notre équipe sœur était en train de créer le support IDE pour C# dans Visual Studio, et elle devait également écrire des tonnes de code (également à cette époque en C++) pour comprendre la syntaxe et la sémantique C# », ajoute Mads Torgersen. Voici entre autres les problèmes auxquels l'équipe C# devait avoir des solutions avant de se lancer dans son projet.

Est enfin venue une proposition qui allait rendre cela possible...

Après des années d'hésitation est venue une proposition qui allait rendre le projet possible, avec notamment de la valeur pour les clients : faire en sorte qu’il n’existe qu’une base de code qui comprenne le langage C# et qui soit partagée par tous ceux qui souhaitent créer des outils basés sur le code. Comme l'explique M. Torgersen, la valeur client découlerait de l'augmentation des outils disponibles, et en particulier de la qualité des outils existants. Pour cela, il fallait, entre autres, construire une API publique unifiée pour le code C#. Et si vous construisez une API pour toute la communauté C#, cela devient tout à fait normal que ce soit une API .NET, implémentée en C#. C'est donc ainsi que s'est présentée une opportunité de réaliser le vieux rêve de réécrire C# en C#.

...Mais il faut encore faire face à la culture de code source fermé du Microsoft de l'époque

« Roslyn est donc née d'un esprit d'ouverture : partage des composants essentiels du langage C# à l'intention du monde, qu'on pourrait utiliser par programmation », souligne le lead designer de C#. Mais c'était en soi une proposition audacieuse dans une culture encore largement fermée chez Microsoft : « partagerions-nous cette propriété intellectuelle gratuitement ? Allons-nous permettre aux constructeurs d’outils tiers de mieux rivaliser avec nous ? » Voici des questions qu'on se posait chez Microsoft.

Les arguments avancés par les partisans de ce projet étaient que cela allait permettre de renforcer l’écosystème et faire de C# le langage le mieux outillé de la planète. Mais « il s’agissait de la croissance à long terme de C# et .NET, contre la monétisation à court terme et à la protection des actifs de Microsoft. Ainsi, même sans avoir mentionné l’open source, accepter le coût et les risques du projet Roslyn a été une étape importante et audacieuse pour Microsoft », estime Mads Torgersen.

Il faut reconnaître que la vision de Roslyn était très ambitieuse et comportait également de nombreux défis techniques. Il a donc fallu une demi-décennie à Mads Torgersen et son équipe pour la concrétiser. Mais c'est l'ouverture du code source du projet qui semblait le plus grand défi : « La plupart du temps, lors de la construction de la version initiale, Roslyn était toujours un projet à source fermée. Depuis que le projet a réellement démarré en 2009, nous avions la vision de rendre nos compilateurs open source, mais Microsoft n’était tout simplement pas encore prêt. La culture consistant à développer en privé et déposer des brevets sur votre code de base reflétait le fonctionnement de Microsoft depuis les années 1970 - et même si des changements se produisaient, tout cela se déroulerait plus lentement que prévu par notre équipe. En fait, pendant un moment, on a eu l'impression que la société allait dans une direction totalement opposée », dit-il.

Mads Torgersen et son équipe ont eu cette impression avec le projet Windows 8, une période pendant laquelle tout a été dissimulé dans un secret extrême, non seulement vis-à-vis de l'extérieur, mais même au sein de l'entreprise. Le lead designer de C# explique par exemple que dans le cadre de ce projet, il y avait une fonctionnalité asynchrone qu'ils développaient à l'époque, mais il n'osait pas publier de notes de conception, même en interne, de peur de divulguer accidentellement des informations sur Windows 8 et de se mettre dans des problèmes. « Cela a créé un climat extrêmement terrible pour l’innovation et n’a certainement pas été de bon augure pour nos espoirs de rendre open source le compilateur C# », dit-il.

Le Microsoft d'aujourd'hui commence finalement à émerger et la culture open source se développe

Finalement, après Windows 8, la société a commencé à se transformer et à prendre une nouvelle direction, vers un nouveau leadership et une philosophie très différente ; le Microsoft que nous connaissons aujourd'hui. Le mouvement open source a rapidement commencé à s’implanter au sein de Microsoft. F# est déjà disponible en 2010 avec une licence open source et sa propre fondation, la F # Software Foundation. Une communauté dynamique a grandi autour de F#, ce qui été envié par les autres équipes. L'équipe de Torgersen a alors fortement insisté pour obtenir une licence de production open source pour Roslyn et, finalement, une infrastructure à l'échelle de la société a vu le jour pour la concrétiser.

En 2012, Microsoft a créé Microsoft Open Tech, une organisation spécifiquement axée sur les projets open source. Roslyn a migré sous Microsoft Open Tech et est officiellement devenu open source. C'était un candidat puissant : les ressources de développement étaient toutes internes et bien connues, et le projet lui-même était autonome, sans beaucoup de dépendances pouvant créer des conflits de licences. En avril 2014, lors de la conférence Build de Microsoft, la firme a présenté Roslyn en tant que projet open source et l'a publié sur CodePlex (la défunte plateforme d’hébergement de code open source de Microsoft) sous licence Apache 2.0, mais avec toujours quelques obstacles procéduraux qui demeuraient chez Microsoft. Au même moment, la .NET Foundation a été annoncée pour abriter tous les projets .NET, y compris Roslyn...

Sur d’autres fronts également, Microsoft a réalisé qu’il n’était pas nécessaire de tout contrôler et il est devenu évident que CodePlex n'avait aucune raison d'être. C'est ainsi que Roslyn a rejoint les projets en migration de CodePlex vers GitHub. Aujourd'hui, « la conception du langage C# et l'implémentation du compilateur sont maintenant des processus complètement ouverts, auxquels participent de nombreuses personnes en dehors de Microsoft, avec des fonctionnalités langage entièrement créées par des contributeurs externes », se réjouit Mads Torgersen. « Ce voyage a été long et difficile, et c’est pour moi un symbole des changements importants que Microsoft a subis au cours de la dernière décennie. La pépite qui était Roslyn a commencé dans le secret, a grandi sur une idée d'ouverture et a explosé avec un million d'utilisations différentes aujourd'hui grâce au pouvoir de l'open source ». Il termine son billet sur cette note de satisfaction.

Source : Blog Microsoft Open Source Stories

Et vous ?

Quel être votre sentiment à propos de cette histoire ?
Le passage en open source du projet Roslyn a-t-il apporté des bénéfices importants à Microsoft et C# ?
Microsoft est-il l'un des grands vainqueurs de l'open source ?

Voir aussi :

Mono 5.0.0 est disponible et apporte le compilateur C# Roslyn pour activer le support C#7 et de msbuild pour une meilleure compatibilité
L'intégration du compilateur Roslyn à Mono avance à grands pas, le moteur Roslyn soutenant les EDI de Mono bientôt disponible pour des tests
Le prochain Visual Studio se dévoile, Microsoft publie la préversion de Visual Studio 14 avec Roslyn, ASP.NET vNext et le support de C++ 11/14
Roslyn : Microsoft utilise en interne son compilateur en tant que service, la plateforme ambitionne d'ouvrir la boite noire qu'est un compilateur
Microsoft a dévoilé la feuille de route de C # 7.1, C # 7.2 et C # 8.0 et propose quelques améliorations à son langage


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse Signaler un problème

Avatar de SimonDecoline SimonDecoline - Membre expérimenté https://www.developpez.com
le 03/10/2018 à 23:17
Citation Envoyé par Michael Guilloux Voir le message
Réécrire le compilateur C# était synonyme de relever un certain nombre de défis. D'abord, pour les utilisateurs existants, cela veut dire qu'il va falloir faire correspondre le nouveau compilateur à l'ancien, bogue par bogue. « Et je ne parle pas seulement de bogues connus, mais aussi de ces comportements inconnus et inattendus que les développeurs ont trouvés et ont fini par adopter, souvent sans le savoir », explique le lead designer de C#.
C'est une blague ?
Avatar de Pol63 Pol63 - Expert éminent sénior https://www.developpez.com
le 04/10/2018 à 8:03
pas forcément
quand tu as un logiciel testé et en place, et qui est critique
on te dis y a un nouveau compilateur qui apporte plus de performances, si quand tu livres avec ce nouveau compilo le comportement de ton appli n'est plus le même c'est dommage
après certes tu devrais refaire des tests avant de livrer suite à un changement, mais les bugs qu'il reste sur ce genre de brique logiciel (je parle du compilo) sont des bugs plutôt rares donc avec moins de chance d'arriver

dans le monde professionnel la continuité est signe de qualité (à part chez les développeurs web peut etre )
Avatar de SimonDecoline SimonDecoline - Membre expérimenté https://www.developpez.com
le 04/10/2018 à 13:38
Au temps pour moi. Je croyais que les principes de la qualité et de l'ingénierie, c'était de respecter les normes et docs de référence et de ne surtout pas exploiter des fonctionnalités erronées ou non documentées.
Avatar de npielawski npielawski - Membre à l'essai https://www.developpez.com
le 04/10/2018 à 14:40
Pour donner un exemple, ceux qui développent des émulateurs de console doivent aussi émuler les bugs connus parce que certains jeux les exploitent pour obtenir des fonctionnalités qui n'étaient pas prévues par la documentation officielle.
Avatar de SimonDecoline SimonDecoline - Membre expérimenté https://www.developpez.com
le 04/10/2018 à 22:25
Ok, mais je ne vois pas le rapport.

D'une part, un émulateur de console correspond à un matériel figé alors qu'un langage ou compilateur, on sait dès le départ que ça va beaucoup évoluer (d'où l'importance d'une norme ou doc de référence).

D'autre part, sans vouloir troller, le développement de moteurs de jeux n'est vraiment pas le domaine auquel je penserais pour parler de qualité logiciel et de bonnes pratiques d'ingénierie (même si ça semble s'améliorer depuis quelques années)...
Avatar de mr_samurai mr_samurai - Membre éprouvé https://www.developpez.com
le 11/10/2018 à 22:40
La blague en clair:

Le serpent qui se mord la queue
Avatar de jean12 jean12 - Membre du Club https://www.developpez.com
le 12/10/2018 à 13:26
Pour moi c'est plutôt une preuve de maturité de C# (j'ai connu la version 4 à l'époque).
Le seul hic est que les programmes existant sous l'ancien compilateur C++ doivent être testés sous le nouveau pour vérifier qu'il n'y a pas de nouveaux bogues (ou que certains bogues aient disparu).
Avatar de pvincent pvincent - Membre confirmé https://www.developpez.com
le 13/10/2018 à 9:24
Il y a plus de trente ans, le premier test effectué quand on compilait GCC (en général avec une ancienne version de gcc) consistait déjà à le recompiler avec l'exécutable obtenu et vérifier la stabilité des résultats.

Il est heureux que 30 ans plus tard et avec bien des hésitations, M$ se soit enfin persuadé du bien fondé de cette méthode.
Avatar de mr_samurai mr_samurai - Membre éprouvé https://www.developpez.com
le 13/10/2018 à 14:52
Citation Envoyé par pvincent Voir le message
Il y a plus de trente ans, le premier test effectué quand on compilait GCC (en général avec une ancienne version de gcc) consistait déjà à le recompiler avec l'exécutable obtenu et vérifier la stabilité des résultats.

Il est heureux que 30 ans plus tard et avec bien des hésitations, M$ se soit enfin persuadé du bien fondé de cette méthode.
J'ai aussi automatiquement pensé à GCC en lisant le titre
Contacter le responsable de la rubrique Accueil