Acabo de terminar de leer el capítulo 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 se pueda hacer con C # con una sintaxis similar. Entiendo que ambos idiomas son inherentemente diferentes, pero mi pregunta se relaciona con su uso más que con el diseño.
Las preguntas relevantes me hacen creer que Ruby ofrece poco más que C #:
- ¿Por qué los programadores de C # no se sienten atraídos por Ruby como los programadores de Java?
- ¿El bloque de código de Ruby es igual a la expresión lambda de C #?
Apenas trabajé con Ruby y mi comprensión del lenguaje todavía es muy limitada, por lo que quizás alguien que experimentó con .NET 4.0 y Ruby pueda responder con ejemplos concretos.
¿Qué tareas requieren significativamente menos trabajo con Ruby que C # 4.0?
PD: Esta pregunta se cerró en StackOverflow como demasiado subjetiva y argumentativa, aunque atrajo algo de atención. Esperaba que se fusionara aquí, pero en cambio tendré que volver a publicarlo.
fuente
Respuestas:
Ruby tiene literales para expresiones regulares y un montón de atajos sintácticos útiles para la creación / interpolación de cadenas. Entonces, cuando su (s) tarea (s) están relacionadas principalmente con la mezcla de partes y cadenas coincidentes, Ruby puede requerir mucho menos trabajo (pero fuera de los scripts de ayuda cortos, debo admitir que me pareció una situación muy rara).
Más relevantes son las instalaciones de metaprogramación de Ruby. es decir
#eval,#define_methody amigos, que combinados conopen classes,#includey le#extendpermiten crear toneladas de código repetitivo en tiempo de ejecución, puede argumentar que los generadores / asistentes de código le brindan algunos de los mismos beneficios, pero tiene que vivir con las cantidades posiblemente grandes - del código generado de la placa de la caldera, en comparación con una cantidad relativamente pequeña de código de metaprogramació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 interfaces gráficas de usuario, ya que puede generar métodos para manejar eventos a partir de elementos de la interfaz de usuario mediante la creación de métodos durante el tiempo de ejecución basados en la ID de los elementos de la interfaz de usuario, el tipo, los valores de entrada, etc. (como Objective-C con esteroides, tal vez veremos algo de este poder cuando MacRuby madure).
Sin embargo, la línea entre el buen uso y el horrible abuso de esta característica 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 :)
fuente