Al leer el codigo de otra persona, y encontrarse con un map(&:upcase) puedes deducir de que se trata por el contexto, o buscarlo en la documentacion, pero eso solo te ocurrirá una vez. De ese momento en adelante tu capacidad para leer ruby ha mejorado y ya no es un problema.

Y no es por ponerme detallista, pero la construccion &:simbolo no es parte de Ruby. Rails la define (al igual que muchos otros detalles como .blank?) en core_ext de ActiveSupport. De hecho, ese “truco” en particular viene de Facets (buscala en rubyforge), una libreria repleta de detalles como ese.

Por otro lado tampoco creo que haya que pensar siempre en quién va a leer tu código: está bien poner comentarios y demás, pero no readaptarse a la forma de programar de los demás sólo para que puedan leer algo que tú escribiste tiempo atrás.

Lo que sí es legible es:

# Creamos un array con something
[*something]


Luis: lo que tú dices puede que tenga parte de razón, pero no veo yo tanta variabilidad en el lenguaje como para hacerlo inapropiado para grandes grupos de personas. Mira, por ejemplo rubyforge, o el mismo código fuente de Rails, que mucha gente lo lee y lo comprende.

Si con un lenguaje existen sentencias sinonimas, al leer un codigo nos podemos encontrar con cualquiera de ellas, en conseqüencia debemos conocerlas todas para poder leer el codigo escrito por alguien, a no ser que exista algun tipo de convención sobre que sentencias utilizar en cada caso.

Así, Ruby, no es un lenguaje apropiado para proyectos donde intervengan más de un desarrollador ni para aquellos que se quieran distribuir bajo licencias libres.

En canvio, como punto positivo, aprender Ruby (si se conoce otro lenguaje) es bastante más sencillo que aprender un lenguaje que carezca de sinonimos pues seguramente tendra sentencias similares a las del lenguaje que se conoce.