¿Recomendaría Iron Ruby, Iron Python o PowerShell para hacer que una aplicación C# sea un servidor de scripts?

Question

¿Recomendaría Iron Ruby, Iron Python o PowerShell para hacer que una aplicación C# sea un servidor de scripts?

Después de algunos retoques rápida, en este momento me estoy inclinando hacia PowerShell por dos razones principales (tenga en cuenta estas puramente mis opiniones, y si se equivocan, me gustaría saber !!!):

1) Es simple crear un espacio de ejecución con clases en su aplicación; por lo tanto, es fácil hacer que su aplicación sea programable.

2) He oído algunos rumores de que IronRuby e IronPython están perdiendo soporte de Microsoft, por lo que pueden ser una solución a largo plazo.

Como esta es la primera vez que agrego secuencias de comandos a una aplicación, agradeceré todos los consejos que pueda recibir de personas que han estado en este camino antes.

Específicamente, además de dejarme saber si está de acuerdo con mis dos puntos anteriores, me gustaría saber si IronRuby y IronPython son mucho más fáciles de usar (para un usuario, no desarrollador) que powershell, y si en su experiencia ¿Usar el DLR es tan fácil como pasar un objeto a un espacio de ejecución de powershell? Y si agrego soporte para los scripts de DLR e IR/IP, ¿mi aplicación aún sería retrocompatible con XP?

Answer 1

número 2 es cierto (los equipos dinámicos de lang han estado perdiendo personal por un tiempo) y una excelente razón. Ruby y Python no son lenguajes de MS, y como tal, Iron * simplemente 'lo hace funcionar en .NET'. PowerShell es una creación de Microsoft, controlada por Microsoft y compatible con Microsoft.

Más importante aún, varios productos de Microsoft han tomado profundas dependencias de PowerShell (Exchange, SharePoint, etc.) por lo que hay muy pocas dudas sobre el soporte continuo de PowerShell como lenguaje.

Por último, PowerShell considera ser el lenguaje de scripting para otras aplicaciones como uno de sus objetivos de soporte de primera clase.

Answer 2

No estoy convencido de que PowerShell tenga "un lenguaje de scripting para aplicaciones" en cualquier parte de sus objetivos a largo plazo. Es primera una concha, segundo un motor de automatización de la integración &, y el tercero un lenguaje shell scripting ... ya que no es redistribuido de todo, no estoy seguro de dónde incrustado scripting encaja.

Es ciertamente muy fácil host PowerShell, suponiendo que esté preinstalado en las PC de destino, por lo que es una opción muy viable, pero creo que, en general, es igual de fácil hacerlo con IronRuby o IronPython.

Dudo que el DLR se vaya, así que creo que usar un lenguaje DLR sigue siendo una buena opción para esto: estarías configurado para aceptar otros lenguajes DLR con mucho menos esfuerzo, y el DLR y los idiomas son redistribuible.

Además, el trabajo para alojar PowerShell solo le brinda PowerShell, mientras que puede aprovechar el mismo trabajo para que IronPython e IronRuby funcionen. Quién sabe, dado que PowerShell es un lenguaje dinámico, tal vez será portado al DLR con la compatibilidad dinámica adecuada en una versión futura ... pero es poco probable que sea redistribuible, porque Microsoft no lo considera una herramienta de desarrollo, sino más bien una parte central del sistema operativo.

En pocas palabras: usando el DLR es mucho más portátil - y no solo para XP sino incluso para Mono (y por lo tanto para Linux, OS X, iOS, Android, etc. ... e incluso para la web o Windows Phone a través de Silverlight).

Answer 3

Estoy en una posición similar. Decidí usar scripts de IronPython, pero desde que vi la charla de Anders Hejlsberg "The Future of C#", tuve la sensación de que IronPython estaba condenada al fracaso.

A Microsoft le interesaba que se desarrollara el DLR, pero finalmente quieren que usemos las herramientas y los idiomas que controlan. Después de todo, ¿no estás usando C# y no Java? Entonces, ¿cómo se verá un lenguaje dinámico de Microsoft? ¿Qué tal un C# dinámico (interpretado como C# de hierro)? La charla de Hejlsberg dejó en claro que no está muy lejos. Incluso tenía una ventana de consola con una interfaz REPL. Dicho esto, siempre hay una posibilidad para Iron VB. Habla sobre cerrar el ciclo.

En el lado positivo para los programadores de nosotros, Iron C# también resuelve otro problema con el que estoy teniendo problemas: la existencia de dos entornos de objetos paralelos, uno de objetos .Net, uno de los objetos de Python. Se necesita trabajo para llegar de uno a otro. Supongo que un Iron C# utilizaría la estructura de clase .Net.

Mi consejo: Quédese con las clases Iron Python y .Net. Cuando ocurra Iron VB o Iron C#, será una traducción de idioma rápida, tal vez automática. Además, si bastantes de nosotros usamos IronPython, Microsoft puede cambiar su forma de pensar.