¿Hay tareas que requieran un trabajo significativamente menor con Ruby que con C # 4.0?

8

Acabo de leer el capítulo de Ruby del libro 7 idiomas en 7 semanas . Aparte de un poco de azúcar sintáctica aquí y allá, realmente no puedo ver nada que no pueda hacerse con C # con una sintaxis similar. Entiendo que ambos idiomas son intrínsecamente diferentes, pero mi pregunta se relaciona con su uso en lugar de con el diseño.

Las preguntas relevantes me hacen creer que Ruby ofrece poco más que C #:

Apenas trabajé con Ruby y mi comprensión del idioma es todavía muy limitada, por lo que quizás alguien que haya experimentado tanto con .NET 4.0 como con Ruby pueda responder con ejemplos concretos.

¿Qué tareas requieren mucho menos trabajo con Ruby que C # 4.0?

P.s .: Esta pregunta se cerró en StackOverflow como demasiado subjetiva y argumentativa, aunque sí llamó la atención. Esperaba que se fusionara aquí, pero en lugar de eso solo tendré que volver a publicarlo.

    
pregunta Steven Jeuris 27.04.2011 - 23:50

1 respuesta

7

Ruby tiene literales para expresiones regulares y un montón de atajos sintácticos útiles para la creación / interpolación de cadenas. Por lo tanto, cuando sus tareas están principalmente relacionadas con la combinación de partes y partes de cadenas que combinan, Ruby podría requerir mucho menos trabajo (pero, aparte de los guiones cortos de ayuda, debo admitir que esta es una situación muy rara).

Más relevantes son las instalaciones de meta-programación de Ruby. es decir, #eval , #define_method y amigos, que combinados con open classes , #include y #extend le permiten crear toneladas de código repetitivo en el tiempo de ejecución. Puede argumentar que los generadores / asistentes de código le dan parte de la tiene los mismos beneficios, pero tiene que vivir con el código generado de la placa de la caldera, posiblemente muy grande, en comparación con una cantidad relativamente pequeña de código de meta-programación que tendría que leer y comprender.

Un caso de uso típico para esto es tener que interactuar con algún tipo de proveedor de datos dinámicos fuera de su aplicación. Rails ActiveRecord es un buen ejemplo para eso.

En el futuro, esto podría ser muy beneficioso para desarrollar GUIs, ya que puede generar métodos para manejar eventos a partir de elementos de la interfaz de usuario al crear métodos durante el tiempo de ejecución basados en el ID de los elementos de la IU, el tipo, los valores de entrada, etc. (como Objective-C en esteroides, quizás veamos algo de este poder cuando MacRuby madure).

Sin embargo, la línea entre el buen uso y el horrible abuso de esta función es muy delgada y, según mi experiencia, tiende a ser una causa importante de dolores de cabeza en grandes proyectos de Ruby (on Rails). Así que ten cuidado cuando decidas liberar el Djinn de su botella :)

    
respondido por el Alexander Battisti 28.04.2011 - 11:48

Lea otras preguntas en las etiquetas