Faire valoir le cas de IronRuby et IronPython

Question

Je suppose que tout le monde a déjà entendu parler des départs de certains développeurs clés de l'équipe des langages dynamiques en raison de ce qu'ils perçoivent comme un soutien en baisse pour les langages dynamiques chez Microsoft.

Je suis assez attaché à Python et j'essaie de l'utiliser souvent. Donc, par extension, je me soucie d'IronPython et j'aimerais le voir continuer à évoluer. Je suis sûr que beaucoup de gens ressentent la même chose pour IronRuby. Mais la chose que je n'arrive toujours pas à comprendre pleinement est pourquoi les développeurs .NET devraient se soucier d'IronRuby et d'IronPython?

Si vous deviez écrire une lettre à Microsoft pour leur demander de continuer à soutenir et à développer le DLR et les langages Iron, quels arguments utiliseriez-vous?

Si vous deviez convaincre votre employeur d'engager du temps de développeurs pour contribuer aux versions communautaires à venir d'IronPython ou d'IronRuby, comment le rationaliseriez-vous en termes de valeur commerciale?

Voici quelques cas d'utilisation intéressants auxquels j'ai pu penser, mais si j'étais un manager réfléchissant à la question ci-dessus, je ne les trouverais probablement pas si convaincants:

1. Langages de script intégrés dans des applications plus importantes: Un cas d'utilisation valable, mais cela semble être un scénario de niche pour la plupart des développeurs.
2. Tests et automatisation des tests: Ruby en particulier dispose d'une grande variété d'outils de test et de bibliothèques de qualité, et ce serait bien de les utiliser dans .NET via IronRuby. Mais il semble que des bibliothèques équivalentes en .NET comblent ce manque, comme SpecFlow et Selenium WebDriver.
3. Exécution de frameworks existants sur la pile Microsoft: Si IronRuby permettait à Ruby on Rails de s'exécuter sur Windows avec IIS et MS SQL, cela pourrait encourager les entreprises ayant adopté la pile Microsoft à adopter RoR.

Est-ce que quelqu'un peut penser à quelque chose de mieux?

Answer 1

Ce que vous avez écrit est correct et j'ajouterai quelques autres points :

• Utiliser la console interactive pour parcourir/tester rapidement les méthodes.
• Étant donné que le développement en IronRuby/IronPython est plus rapide, vous pouvez l'utiliser pour écrire des POCs et plus tard implémenter l'application réelle en C# ou tout autre langage que vous utilisez.
• Implémenter des DSL en IronRuby et les utiliser à partir de langages statiques.
• Ajouter des capacités dynamiques (consoles REPL, par exemple) aux applications de langages statiques.
• Gestalt.
• Pour les adeptes de Ruby : écrire des applications WPF et Silverlight (éventuellement WP7) en IronRuby.

Answer 2

Je ne sous-estimerais pas la valeur d'intégrer l'un d'entre eux dans une grande application. J'ai utilisé les capacités de méta-programmation de Ruby pour modifier les internes d'une application en direct afin de me connecter à des éléments auxquels il serait habituellement difficile d'accéder (c'est particulièrement vrai pour les événements ; je peux facilement ajouter un crochet externe temporaire pour déclencher manuellement un événement pour les tests au lieu de modifier et recompiler réellement la source C#). Cela m'a permis de traquer les bugs et de reproduire plus facilement des scénarios complexes. Cela m'a également permis de prototyper divers codes que je transformerais plus tard en tests unitaires ou en nouvelles classes.

En outre, cela peut être utile pour les testeurs manuels QA. Les tâches courantes peuvent être incorporées dans des scripts automatisés qu'ils peuvent exécuter.

Answer 3

Le scripting léger est une raison très convaincante d'avoir des langages dynamiques et intégrés dans la boîte à outils .Net.

Mon entreprise développe des logiciels pour instruments scientifiques. L'acquisition et l'analyse de données se font toutes deux avec du scripting dans une application framework. Cela nous permet d'être très réactifs aux besoins variés de nos clients.

Nous avons évalué des technologies pour mettre à niveau notre logiciel afin de ne pas avoir à maintenir notre propre langage de script. J'ai regardé Qt/PyQt mais j'ai hésité quand cela a été vendu à Nokia. J'ai décidé d'attendre pour voir comment IronPython évoluait. J'ai choisi d'utiliser IronPython après la sortie de .Net4 et de C# 4.

Je pense maintenant que j'ai peut-être pris la mauvaise décision et je considère revenir à Qt/PyQt. Pas mal comme raison convaincante, non ?