¿Cómo se verán afectadas las aplicaciones Python y Ruby por .NET?

Question

Tengo curiosidad acerca de cómo .NET afectará las aplicaciones de Python y Ruby.

¿Las aplicaciones escritas en IronPython / IronRuby serán tan específicas para el entorno .NET que esencialmente se convertirán en plataformas específicas?

Si no usan ninguna de las características de .NET, ¿cuál es la ventaja de IronPython / IronRuby sobre sus contrapartes que no son .NET?

Answer 1

No puedo decir nada sobre IronRuby, pero la mayoría de las implementaciones de Python (como IronPython, Jython y PyPy) intentan ser lo más fieles posible a la implementación de CPython. Sin embargo, IronPython se está convirtiendo rápidamente en uno de los mejores a este respecto, y hay mucho tráfico en Planet Python al respecto.

Lo principal que alentará a los desarrolladores a escribir código que sea diferente de lo que escribirían en CPython es la falta de módulos de extensión C como NumPy (esto también es un problema en Jython y PyPy).

Un proyecto interesante para vigilar es IronClad, que le permitirá llamar a los módulos de extensión C desde IronPython. Esto eventualmente debería significar que puede desarrollar código en CPython, utilizando los módulos que desee, y se ejecutará sin modificaciones en IronPython.

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

Entonces para responder a sus preguntas:

Debería ser bastante fácil escribir aplicaciones IronPython que también funcionen en CPython, pero probablemente apuntaría a lo contrario: los programas CPython que también funcionan en IronPython. De esa manera, si no funciona, es más probable que sea un error conocido con una solución conocida.

La ventaja de IronPython et al existente es que proporcionan implementaciones alternativas del lenguaje, que a veces son útiles para detectar errores en CPython. También proporcionan métodos alternativos para implementar sus aplicaciones de Python, si por alguna razón se encuentra en una situación (como Silverlight) donde distribuir la implementación de CPython con su aplicación no es apropiado.

Answer 2

  

¿Las aplicaciones escritas en IronPython / IronRuby serán tan específicas para el entorno .NET que esencialmente se convertirán en plataformas específicas?

IronRuby actualmente se envía con la mayoría de la biblioteca estándar de ruby ??core, y es compatible con gemas de ruby.

Esto significa que admitirá prácticamente cualquier aplicación de ruby ??nativa que no dependa de extensiones C.
La otra cara es que será posible escribir aplicaciones de rubí nativas en IronRuby que no se basen en el CLR, y serán portátiles para IRM.

Si la gente elige o no crear o usar extensiones para sus aplicaciones usando el CLR es la misma pregunta que si las personas crean o usan extensiones C para IRM: una no es más portátil que la otra.

Hay una pregunta secundaria de " porque es mucho más fácil crear extensiones IronRuby en C # que crear extensiones CRuby en C, ¿las personas crearán extensiones donde deberían apegarse al código ruby ??nativo? ? " , pero eso es completamente subjetivo.

Sin embargo, en general, creo que cualquier cosa que facilite la creación de extensiones es una gran victoria.

---

  

Si no usan ninguna de las características .NET, ¿cuál es la ventaja de IronPython / IronRuby sobre sus contrapartes que no son .NET?

1. Rendimiento: IronRuby ya es más rápido en su mayor parte que MRI 1.8, y no está muy lejos de MRI 1.9, y las cosas solo mejorarán en el futuro. Creo que Python es similar a este respecto.

2. Implementación: como la gente ha mencionado, ejecutar una aplicación nativa de rieles multiplataforma rubí dentro de IIS es una propuesta atractiva para algunos desarrolladores basados ??en Windows, ya que les permite integrarse mejor con los servidores existentes / infraestructura de administración / etc

3. Estabilidad: si bien MRI 1.9 es mucho mejor que 1.8, no creo que nadie pueda estar en desacuerdo con que CLR tiene un recolector de basura y un tiempo de ejecución de base mucho mejores que C ruby.

Answer 3

IronPython / IronRuby están diseñados para funcionar en la máquina virtual .net, por lo que, como usted dice, son esencialmente específicos de la plataforma.

Aparentemente son compatibles con Python y Ruby siempre que no use ninguno de los marcos .net en sus programas.

Answer 4

Si crea una biblioteca o marco, las personas pueden usarlo en .NET con su código .NET. ¡Eso es genial para ellos y para ti!

Al desarrollar una aplicación, si utiliza las instalaciones de .NET con abandono, pierde "multiplataforma", lo que no siempre es un problema.

Si ajusta estos usos con una API interna, puede reemplazar las implementaciones de .NET más adelante con Python puro, C (para CPython) o Java (para Jython) más tarde.

Answer 5

Según la página de Mono, IronPython es compatible con la implementación de Mono del tiempo de ejecución .Net, por lo que los ejecutables deberían funcionar tanto en Windows como en Linux.

Answer 6

Responde su primera pregunta con la segunda, si no usa nada de .Net solo las bibliotecas originales proporcionadas por la implementación del lenguaje, puede interpretar su archivo * .py o * .rb con otra implementación y debería funcionar.

La ventaja sería que si es una tienda .Net, generalmente se encarga de tener el marco correcto instalado en la máquina del cliente, etc ... bueno, si desea un código python o ruby, ahora necesita admitir otro '' marco '' necesita distribuir la instalación, ocuparse del problema de la versión, etc ... Así que hay 2 ventajas, usar .Net framework power dentro de otro idioma + mantener la distribución / mantenimiento lo más simple posible.

Answer 7

Sería genial ejecutar Rails / Django bajo IIS en lugar de soluciones de tipo Apache / Mongrel