Pourquoi quelqu'un investirait-il du temps dans Microsoft "Roslyn"?

Je viens de lire quelques-uns des livres blancs et des exemples de Microsoft "Roslyn" et le concept semble très intéressant. D'après ce que je peux dire, cela ouvre la boîte noire qu'est le compilateur et fournit une interface que nous pouvons utiliser pour obtenir des informations et des métriques sur le code écrit dans Visual Studio.

Roslyn semble également avoir la capacité de «scripter» du code et de le compiler / exécuter à la volée (similaire au CodeDom), mais je n’ai rencontré que des utilisations limitées pour ce type de fonctionnalité dans mon expérience.

Bien que l’élément analyse et métrique du code soit un domaine intéressant, c’est quelque chose qui existe depuis très longtemps et de nombreux fournisseurs ont déjà beaucoup investi dans des outils d’analyse et de refactorisation de code (par exemple, ReSharper, CodeRush). , nCover, etc) et ils font un très bon travail!

Pourquoi une entreprise ferait-elle tout son possible pour mettre en œuvre quelque chose qui peut être fourni pour une fraction du coût en achetant une licence pour l'un des outils existants?

Peut-être ai-je raté certaines fonctionnalités clés du projet Roslyn qui les placent en dehors du domaine des outils mentionnés ...

Roslyn semble également avoir la capacité de «scripter» du code et de le compiler / exécuter à la volée (similaire au CodeDom), mais je n’ai rencontré que des utilisations limitées pour ce type de fonctionnalité dans mon expérience.

La compilation et l'exécution à la volée constituent le principal avantage de Roslyn. Je pense que vous sous-estimez peut-être les avantages de cette fonctionnalité car vous n’avez jamais rencontré de cas d’utilisation dans votre expérience où elle brille vraiment. Et cela a du sens; le besoin de compilation dynamique est probablement une fonctionnalité de niche, mais son utilisation fournit des applications puissantes qui seraient beaucoup plus difficiles sans cela.

Voici quelques exemples qui me viennent à l’esprit où une compilation dynamique serait très utile. Il y a d'autres façons d'accomplir toutes ces choses, mais Roslyn les facilite.

• Avoir des fichiers de plug-in chargés au moment de l'exécution, compilés et inclus dans l'exécution de l'application "parent".
• Création d'un DSL qui est ensuite traduit en C # au moment de l'exécution et compilé avec Roslyn.
• Créer une application orientée programmeur qui prend C #, l’analyse, la traduit, etc.
• Comparer deux fragments de code pour leurs différences après la compilation, par opposition aux différences "superficielles" telles que les espaces. Ceci est connu comme Diff sémantique .

Donc, pour résumer, vous ne trouverez peut-être jamais d’utilisation pour Roslyn, selon le logiciel que vous passez votre temps à écrire. Cependant, il existe de nombreux cas d'utilisation où Roslyn apporte beaucoup à la table. Aucun des outils mentionnés ne fournit cette fonctionnalité. Ils ne pourraient pas non plus se baser sur leur architecture et leur objectif.

Je suis sûr que les entreprises qui fournissent des outils (par exemple JetBrains *) sont très intéressées par Roslyn. Microsoft souhaite faciliter la création d’outils, car un bon outillage encourage l’utilisation de son écosystème.

* Selon le blog JetBrains ( cette entrée ), JetBrians a annoncé qu’il n’utiliserait pas Roslyn. Cependant, j'imagine que tous les nouveaux concurrents de JetBrains (qui n'ont pas de base de code préexistante) utiliseront Roslyn; cela leur donne une longueur d'avance.

Question 6 sur 10 questions, 10 réponses sur Roslyn :

6: Quelles sont les utilisations pratiques de Roslyn? Comment cela m'aidera-t-il en tant que développeur?

Une des premières utilisations de Roslyn qui me vient à l’esprit est celle d’un moteur de règles métier. Avant Roslyn, l’évaluation des macros d’utilisateur impliquait généralement l’implémentation de VBA (Visual Basic pour Applications), l’appel au DLR avec des expressions Ruby ou le shilling au compilateur de ligne de commande avec un code Visual Basic ou C # généré dynamiquement et l’obtention du résultat de l’exécution. ce code. Ces méthodes étaient moins qu'idéales.

Roslyn autorisera facilement la compilation et l’exécution dynamiques de code C # et (éventuellement) de code Visual Basic avec la fonction Evaluate (), comme le montre l’article d’Eric Vogel intitulé "Utilisation de l’API de script Roslyn en C #". Les macros utilisateur écrites dans le même langage que l'application permettront aux développeurs de prendre en charge plus facilement des macros utilisateur représentant des règles métier.

La refactorisation de code devient beaucoup plus facile avec Roslyn. Avant Roslyn, les développeurs d'outils tels que DevExpress CodeRush et Refactor Pro et JetBrains ReSharper devaient recréer une grande partie des opérations du compilateur comme base de leurs produits. Avec Roslyn, les développeurs de refactoring peuvent directement tirer parti des fonctionnalités existantes du compilateur. Je peux imaginer l’apparence des paquets NuGet pour installer des règles de refactoring individuelles une fois que Roslyn sera largement disponible.

J'attends avec impatience le jour où tous les compilateurs proposeront régulièrement Compiler as a Service (CaaS). Nous devons cesser de penser que les compilateurs n'émettent que du code antérieur au lieur et commencer à penser que les compilateurs émettent des arbres pouvant être transformés en cibles multiples. Tous les compilateurs doivent avoir une fonctionnalité pour émettre des arbres et éventuellement JSON / XML. La sortie peut ensuite être transformée en plusieurs types de cibles, telles que le même langage optimisé, les sources C, IL, binaire IL, Java, Javascript, LLVM, l'exécutable PIC et même le code de pré-éditeur de liens.

J'écris des compilateurs pour gagner ma vie. Mes clients sont vendus sur CaaS car cela ouvre la porte à une flexibilité, une portabilité et une analyse fantastiques.

Je suis vraiment déçu que Microsoft n'ait pas implémenté CaaS il y a longtemps. Par exemple, il aurait pu être utilisé comme chemin de migration de VB6 vers autre chose, ou .Net vers C ++.

La réponse simple à la raison pour laquelle MSFT investit dans Roslyn est que leur base de code existante pour le compilateur C # a maintenant 5 versions - 11 ans maintenant. C’est long pour que toute base de code reste gérable. De plus, depuis qu'ils réécrivent, ils ont décidé d'investir pour le faire, afin que tous ses internes soient exposés en tant qu'API.