Ruby: The Bad Parts [cerrado]

Hace poco leí el libro de Crockford "Javascript: The Good Parts" y una de las premisas subyacentes era que los lenguajes de programación pueden tener un conjunto de características malas que los programadores deberían evitar.

Soy Rubyist y, aunque me encanta el lenguaje, siempre hay valor en obtener perspectiva. Entonces, ¿cuál ves como la peor característica (por ejemplo, métodos, clases, prácticas) en Ruby? Mi intención aquí no es comenzar una discusión sobre los méritos del lenguaje en sí o su velocidad, etc. Más bien preferiría una discusión sobre qué características considera peligrosas / problemáticas / dolorosas de usar, basadas en experiencias pasadas.

Deberías ver Python vs Ruby: A Battle to The Death por Gary Bernhardt. Él hace la cita:

Las mismas cosas que encuentro feas en Ruby son las que hacen posible un software increíble de Ruby como RSpec, y que Python nunca podría haberlo hecho (dada la implementación actual).

Si bien habla mucho sobre Python en particular, toca muchas cosas que son raras en Ruby. Uno de los grandes temas generales es el parche de mono .

Los objetos Ruby (a diferencia de los objetos en algunos otros lenguajes orientados a objetos) pueden modificarse individualmente. Siempre puede agregar métodos por objeto. En Ruby, el comportamiento o las capacidades de un objeto pueden diferir de los suministrados por su clase.

Si bien esto proporciona mucha flexibilidad y potencia algunas de las gemas más populares y complicadas de Ruby, puede morderte el trasero si estás tratando de depurar un problema sin darte cuenta de que alguna biblioteca en algún lugar ha modificado un método central.

Algunas personas solo piensan en el rubí en términos de rubí sobre rieles y es un poco molesto porque el lenguaje se sostiene por sí solo bastante bien.

Creo que la peor característica es la open classesque le permite cambiar globalmente el comportamiento de todas las instancias actuales y futuras de la clase modificada.

La parte problemática de esta característica es que estos cambios (globales) ocurren durante el tiempo de ejecución cuando el intérprete de Ruby se encuentra con la definición, lo que podría pasar mucho tiempo después de que haya instanciado un par de objetos que ahora cambian su comportamiento de repente.

En una base de código grande, esto puede resultar en errores muy, muy difíciles de encontrar, especialmente porque esto se ve agravado por la débil historia de depuración de Ruby (en comparación con CLR o JVM) y el uso de otras características (por ejemplo eval) en este contexto puede hacer que es bastante difícil encontrar la ubicación donde ocurrió este cambio global. es decir, si ya llegó al punto en el que sospecha que la clase "correcta" está causando el problema. En mi experiencia, generalmente comienza con una persecución salvaje, ya que los problemas comienzan a surgir en un objeto usando al verdadero culpable.

Por lo tanto, lo mejor sería dejar de usar clases abiertas ( #extendy poner los cambios en un ModuleIMHO es mucho más seguro, más fácil de entender y mejor probar) o si no se puede evitar:

• solo extienda las clases con un comportamiento nuevo (es decir, sin anular el comportamiento existente)
• tener un lugar definido en el árbol de código fuente, donde todas las extensiones que usan clases abiertas deben colocarse
• no use #evaly amigos para crear clases abiertas
• coloque todos los usos de las clases abiertas en un gran gráfico visible, donde todos los desarrolladores puedan verlos, y deje en claro que cualquier cambio en ellos son "decisiones arquitectónicas" que afectan a toda la base de código (lo que hacen) y no el lugar para hacks rápidos útiles para su tarea actual

La razón principal por la que no uso Ruby: es más lento que la melaza en enero en el Polo Norte durante una era de hielo. Los lenguajes de evaluación comparativa son una ciencia inexacta, pero Ruby parece drásticamente más lento que incluso JavaScript y Python.

Si esto se puede extender a Ruby on Rails, entonces:

1. El hecho de que la lógica de la base de datos le da a cada tabla una auto_incrementclave principal, incluidas las tablas que no las necesitan y no deberían tenerlas.

2. El hecho de que las claves compuestas no son compatibles en absoluto.

Para Ruby, mi queja sería la misma que para cualquier lenguaje que cambie la seguridad por la expresividad; es fácil hacer mucho con solo un pequeño código, pero es igual de fácil hacer un gran lío con cualquier cantidad de código.

Ruby adopta la metaprogramación (reflexión, introspección), programación de paradigmas múltiples y dinamismo a un nivel poco común. Es fácil dispararse en el pie con potencia y flexibilidad.

¿Molesto? Ruby tiene la capacidad de ser extremadamente legible o inescrutable. He visto código que parece pertenecer a un script Bash.

Malas prácticas? Algunos rubíes valoran la inteligencia sobre la sabiduría. Escriben y comparten trucos que muestran su inteligencia, pero esto crea un código ilegible y frágil.

Por otro lado: Javascript fue un desastre por diseño, y el libro "The Good Parts" trata de extraer su belleza oculta. Perl, un lenguaje que popularizó "Hay más de una forma de hacerlo" (es decir, flexibilidad), tiene un libro similar en "Perl, mejores prácticas". La historia de Perl es de experimentación y experiencia ganada con esfuerzo, "Best Practices" representa su conocimiento. Perl 6 será, creo que es justo decir, un reinicio del lenguaje basado en ese conocimiento y más. Ruby puede sufrir problemas similares.

@James y bucles for ... Cuando haces un bucle for en ruby, llama ".each". Por lo tanto, "for" es azúcar sintáctico para personas más cómodas con bucles estilo C. Pero como Rubyist, vas a usar iteradores como .map, .inject, .each_with_object, todo el tiempo. Nunca tendrá que escribir un bucle for con algo como "i = 0; i> 6; i ++" en ruby, por lo que terminará abandonando el hábito. @andrew ... el elocuente rubí no respalda los bucles.

Esto se trata más de los programadores que del lenguaje, pero ¿por qué los programadores de Ruby odian tanto los bucles?

Me doy cuenta de que Ruby tiene:

someCollection.each do |item|
   ...
end

pero nunca he visto eso usado en situaciones donde un bucle for no haría exactamente lo mismo.

He preguntado varias veces y nunca obtuve una buena respuesta a esta.

Si es solo una cuestión de estilo, estoy feliz de aceptarlo, pero he visto a los programadores de Ruby realmente entusiasmados con esto y tengo mucha curiosidad.

Por lo general, evitaría las cosas que se agregaron solo para ser compatibles con otros idiomas. Por ejemplo, perlismos y for x in y.