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

37

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

.net visual-studio static-analysis

— Richard Hooper
source

4

Le principal intérêt de Roslyn est davantage Microsoft stagiaire - ce qui en fait un compilateur C # facile à gérer et extensible. De cette façon, l'équipe peut plus facilement implémenter et essayer de nouvelles fonctionnalités linguistiques. L'implémentation de nouveaux algorithmes d'optimisation deviendra également plus facile.

— JustAnotherUserYouMayKnowOrNon

1

Oui, Penfold - Je suppose que vous avez peut-être oublié certaines choses. Avez-vous regardé l'interview de Dustin Campbells sur Channel9? channel9.msdn.com/Events/Ch9Live/…

— James Snell

3

Ceci est le risque de développer des add-ons réussis / rentables aux produits Microsoft, ils pourraient le mettre dans la prochaine version.

— JeffO

10

En outre, vous pouvez être sûr que les responsables de ReSharper s’imprègnent des fonctionnalités supplémentaires qu’ils peuvent brancher. Oui, ils ont écrit un analyseur / analyseur C #, mais le coût par fonctionnalité chutera considérablement s’ils peuvent exploiter le moteur MS C # réel.

— Binary Worrier

2

Découvrez les scripts pour une utilisation intéressante de Roslyn. github.com/scriptcs/scriptcs

— Ashley Davis

53

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.

— RationalGeek
source

+1 pour diff diff. Pour l’intérêt, voici un lien vers un produit commercial en développement qui utilise Roslyn pour les différences sémantiques. (Divulgation complète - Je n'ai aucun lien avec eux, je viens de voir leur produit mentionné sur le blog de Jon Skeet )

— MarkJ

@RationalGeek - Merci pour les exemples, je n'avais pas considéré l'exemple de route DSL => C # ... Je peux imaginer quelques scénarios où ce serait très puissant dans les applications métier. Beaucoup d'autres exemples que j'ai vus (pas seulement le vôtre) recoupent beaucoup les outils de refactoring que j'ai mentionnés auparavant. L’autre partie de ma question initiale était de savoir pourquoi une personne investirait de l’argent dans le développement d’outils permettant d’effectuer cette analyse alors qu’il en existe d’excellents qui sont précoulés à une fraction du coût ... mais je suppose qu’il reste toujours de la place pour un autre (espérons). mieux) ensemble d'outils! :)

— Richard Hooper

@Penfold, il y a toujours de la place pour de nouveaux outils de développement ... :-)

— RationalGeek

1

Le sémantique diff ne sert pas uniquement à la compilation. Chaque système de contrôle de version nécessite un diff, et la plupart utilisent un diff stupide. Il suffit de permuter 2 fonctions et de constater le désordre

— causé

En voici un exemple important: la recompilation automatique lors de l'écriture d'applications ASP.NET SANS avoir à reconstruire et redéployer l'application Web. Enfin annoncé dans ASP.NET vNext, le travail en C # sera littéralement identique à un langage de script ... sauf qu’il est à la fois typé et performant. Je vois cela comme le tout début de cette approche générale et finira par se retrouver dans les applications pour client riche (mobile, ordinateur de bureau) afin que vous puissiez modifier votre code au moment de l'exécution. C'est beaucoup plus facile avec les applications Web puisque, par définition, chaque requête est sans état, mais avec le temps, elle se retrouvera également dans d'autres architectures d'applications.

— Marsy

12

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.

— Brian
source

4

"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 de gestion." - Qu'est ce qui pourrait aller mal!

— gbjbaanb

10

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

— BSalita
source

1

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.

— John Tasler
source