7

Supongo que todos ya han escuchado las noticias sobre some key developers leaving the Dynamic Languages team debido a lo que perciben como una disminución en el soporte para Dynamic Languages ​​en Microsoft.Haciendo el caso de IronRuby e IronPython

Soy bastante aficionado a Python y trato de usarlo a menudo. Entonces, por extensión, me importa IronPython y me gustaría ver que continúe evolucionando. Estoy seguro de que muchas personas sienten lo mismo por IronRuby. Pero lo que todavía no puedo entender es ¿Por qué deberían los desarrolladores de .NET preocuparse por IronRuby y IronPython?

Si tuviera que escribir una carta a Microsoft pidiéndoles que continúen apoyando y desarrollando el DLR y los idiomas Iron, ¿qué argumentos usaría?

Si tuviera que convencer a su empleador de comprometer el tiempo de los desarrolladores para contribuir con las versiones de IronPython o IronRuby que aún no se han hecho, ¿cómo lo racionalizaría en términos de valor comercial?

Éstos son los pocos casos de uso interesantes que podría llegar a, pero si donde un gestor de ponderar la pregunta anterior, probablemente no encontrarlos que convincente:

  1. de scripting embebido idiomas en aplicaciones más grandes: Un caso de uso válido, pero parece ser un escenario de nicho para la mayoría de los desarrolladores.
  2. Automatización de prueba y prueba: Ruby, en particular, tiene una amplia selección de excelentes herramientas de prueba y bibliotecas, y sería bueno tenerlas disponibles en .NET a través de IronRuby. Pero parece que las librerías .NET equivalentes están llenando ese vacío, como SpecFlow y Selenium's WebDriver.
  3. Ejecución de marcos existentes en Microsoft Stack: Si IronRuby permitiera que Ruby on Rails se ejecutara en Windows con IIS y MS SQL, esto podría alentar a las tiendas que se han estandarizado en la pila de Microsoft a adoptar RoR.

¿Alguien puede pensar en algo mejor?

Respuesta

5

Lo que escriba no es correcto y voy a añadir algunos más balas:

  • Uso de la consola interactiva para la navegación/prueba rápida de métodos.
  • Dado que el desarrollo en IronRuby/IronPython es más rápido, puede usarlo para escribir POC y luego implementar la aplicación real en C# o lo que sea que esté usando.
  • Implemente DSL en IronRuby y úselos desde idiomas estáticos.
  • Agregando capacidades dinámicas (consolas REPL, por ejemplo) a aplicaciones de lenguaje estático.
  • Gestalt.
  • Para Rubyists: escribiendo WPF y Silverlight (aplicaciones WP7 también, potencialmente) en IronRuby.
+0

Shay, sucedió en su blog mientras investigaba la respuesta a esta pregunta antes de publicarla aquí, y me he dado cuenta de que usted es un firme defensor de IronRuby. Así que +1 por tomarse el tiempo para responder aquí, y gracias. Desafortunadamente, a juzgar por la resonante impopularidad de esta pregunta y el general "meh" que estoy viendo en línea sobre este tema, parece que aún no se ha hecho un argumento fuerte y convincente. Sería grandioso si alguien con su historial lograra articular una respuesta más definitiva. – Mhmmd

+0

Bueno, no creo que haya una "respuesta definitiva". Ruby es un lenguaje de programación como C# y puedes hacer con él lo que sea que puedas hacer con C# y aún más a veces. Sin embargo, IronRuby es un poco problemático porque los desarrolladores de .NET no están dispuestos a dejar de usar C#, por lo que tiene que hablar de IronRuby más como una herramienta que como un lenguaje de programación completo. Como herramienta, creo que tus balas más las mías tienen mucho sentido. Y en mi opinión, es una herramienta muy poderosa. –

2

No me gustaría subestimar el valor de incrustar uno de ellos en una aplicación grande. Utilicé las capacidades de meta-programación de Ruby para modificar las funciones internas de una aplicación sobre la marcha y engancharlas en cosas a las que normalmente sería difícil acceder (esto es especialmente cierto para los eventos; puedo agregar fácilmente un gancho externo temporal para plantear un evento de forma manual). probar en lugar de modificar y recompilar la fuente de C#).Esto me ha permitido buscar errores y reproducir escenarios complicados más fácilmente. También me permitió prototipar varios códigos que luego convertiría en una prueba unitaria o nuevas clases.

Además, puede ser útil para los comprobadores manuales QA. Las tareas comunes se pueden incorporar a los scripts automatizados que pueden ejecutar.

0

Scripting liviano ES una razón muy convincente para tener lenguajes dinámicos e incrustados en .Net toolkit.

Mi empresa tiene un software de instrumentos científicos. La adquisición de datos y el análisis se realizan con scripts en una aplicación de framework. Esto nos permite ser muy receptivos a las diferentes necesidades de nuestros clientes.

Hemos estado evaluando tecnologías para actualizar nuestro software, por lo que no tenemos que mantener nuestro propio lenguaje de scripting. Miré Qt/PyQt pero me callé cuando se vendió a Nokia. Decidí esperar para ver cómo maduró IronPython. Decidí usar IronPython después de que aparecieron .Net4 y C# 4.

Creo que ahora podría haber tomado una decisión equivocada y estoy considerando volver a Qt/PyQt. ¿Cómo es eso por una razón convincente?

Cuestiones relacionadas