Comment les applications Python et Ruby seront-elles affectées par .NET?

Question

Je suis curieux de savoir comment .NET affectera les applications Python et Ruby.

Les applications écrites dans IronPython / IronRuby seront-elles si spécifiques à l'environnement .NET qu'elles deviendront essentiellement spécifiques à la plate-forme?

S'ils n'utilisent aucune des fonctionnalités .NET, quel est l'avantage d'IronPython / IronRuby par rapport à leurs homologues non .NET?

Answer 1

Je ne peux rien dire à propos d'IronRuby, mais la plupart des implémentations python (comme IronPython, Jython et PyPy) tentent d'être aussi fidèles que possible à l'implémentation CPython. IronPython est rapidement en train de devenir l'un des meilleurs à cet égard, et la planète Python en génère beaucoup.

La principale chose qui encouragera les développeurs à écrire du code différent de celui qu’ils écrivent dans CPython est l’absence de modules d’extension C comme NumPy (c’est un problème dans Jython et PyPy également).

IronClad est un projet intéressant à surveiller. Il vous permettra d’appeler des modules d’extension C à partir d’IronPython. Cela devrait finalement signifier que vous pouvez développer du code sous CPython, en utilisant les modules de votre choix, et qu'il s'exécutera sans modification sur IronPython.

http://www.resolversystems.com/documentation/index.php/Ironclad

Donc pour répondre à vos questions:

Il devrait être assez facile d’écrire des applications IronPython fonctionnant également sur CPython, mais j’aurais probablement pour objectif d’aller de l’inverse: les programmes CPython qui fonctionnent également sur IronPython. De cette façon, si cela ne fonctionne pas, il est plus probable qu'il s'agisse d'un bogue connu avec une solution de contournement connue.

L’avantage d’IronPython et al exister est qu’ils fournissent des implémentations alternatives du langage, qui sont parfois utiles pour détecter les bogues dans CPython. Ils fournissent également des méthodes alternatives pour le déploiement de vos applications Python si, pour une raison quelconque, vous vous trouvez dans une situation (telle que celle de silverlight) où la distribution de la mise en oeuvre CPython avec votre application n’est pas appropriée.

Answer 2

  

Les applications écrites dans IronPython / IronRuby seront-elles si spécifiques à l'environnement .NET qu'elles deviendront essentiellement spécifiques à une plate-forme?

IronRuby est actuellement livré avec la plupart des bibliothèques ruby ??standard et prend en charge les gemmes ruby.

Cela signifie qu’elle prendra en charge à peu près toutes les applications ruby ??natives qui ne reposent pas sur des extensions C.
Le revers de la médaille, c'est qu'il sera possible d'écrire des applications natives ruby ??dans IronRuby qui ne s'appuient pas sur le CLR, et que celles-ci seront portables pour l'IRM.

Que les utilisateurs choisissent ou non de créer ou d'utiliser des extensions pour leurs applications à l'aide du CLR relève de la même question, à savoir si les utilisateurs créent ou utilisent des extensions C pour l'IRM - l'une n'est pas plus portable que l'autre.

Il y a une question secondaire de "car il est tellement plus facile de créer des extensions IronRuby en C # que de créer des extensions CRuby en C, les gens créeront-ils des extensions où ils devraient s'en tenir au code ruby ??natif ? " , mais c'est tout à fait subjectif.

Mais dans l’ensemble, je pense que tout ce qui facilite la création d’extensions est une grande victoire.

  

S'ils n'utilisent aucune des fonctionnalités .NET, quel est l'avantage d'IronPython / IronRuby par rapport à leurs homologues non .NET?

1. Performances: IronRuby est déjà beaucoup plus rapide que MRI 1.8 et n’est pas très éloigné de MRI 1.9, et les choses ne feront que s’améliorer. Je pense que python est similaire à cet égard.

2. Déploiement: comme certains l’ont déjà mentionné, exécuter une application de rails multiplate-forme ruby ??native dans IIS est une proposition intéressante pour certains développeurs Windows, car cela leur permet de mieux s’intégrer aux serveurs / infrastructure de gestion existants / etc

3. Stabilité: Bien que l'IRM 1.9 soit bien supérieure à celle de 1.8, je ne pense pas que quiconque puisse être en désaccord sur le fait que CLR dispose d'un récupérateur de mémoire et d'un temps d'exécution de base bien meilleurs que ceux de C ruby.

Answer 3

IronPython / IronRuby sont conçus pour fonctionner sur la machine virtuelle .net, ils sont donc, comme vous le dites, essentiellement spécifiques à la plate-forme.

Apparemment, ils sont compatibles avec Python et Ruby tant que vous n’utilisez aucun des frameworks .net dans vos programmes.

Answer 4

Si vous créez une bibliothèque ou un framework, les utilisateurs peuvent l’utiliser sur .NET avec leur code .NET. C'est très cool pour eux et pour vous!

Lorsque vous développez une application, si vous utilisez les fonctionnalités de .NET avec abandon, vous perdez "multiplate-forme", ce qui n'est pas toujours un problème.

Si vous encapsulez ces utilisations avec une API interne, vous pourrez remplacer ultérieurement les implémentations .NET par pure-Python, C (pour CPython) ou Java (pour Jython) ultérieurement.

Answer 5

Selon la page Mono, IronPython est compatible avec la mise en œuvre Mono de l'exécution .Net. Par conséquent, les exécutables doivent fonctionner à la fois sous Windows et Linux.

Answer 6

Vous répondez à votre première question avec la seconde. Si vous n'utilisez rien de .Net que les bibliothèques d'origine fournies par l'implémentation du langage, vous pouvez interpréter votre fichier * .py ou * .rb avec une autre implémentation. et ça devrait marcher.

L’avantage serait que si votre boutique .Net prenne généralement soin d’installer le bon framework sur la machine cliente, etc ... ainsi, si vous voulez du code python ou ruby, vous devez maintenant supporter un autre " framework " besoin de distribuer l’installation, de s’occuper du problème de version, etc. ... Il y a donc 2 avantages, utiliser .Net framework power dans une autre langue + maintenir la distribution / maintenance aussi simple que possible.

Answer 7

Il serait intéressant d’exécuter Rails / Django sous IIS plutôt qu'avec des solutions de type Apache / Mongrel