"Azúcar Ruby inútil": reenvío de argumentos

La nueva sintaxis de reenvío de argumentos de Ruby usando `...` polariza a los desarrolladores entre quienes la ven como un azúcar sintáctico elegante y de bajo mantenimiento para envolver y delegar métodos, y quienes la consideran una complejidad innecesaria que perjudica la legibilidad. El intercambio se amplía hacia una crítica del diseño general de Ruby —sus múltiples convenciones de llamada, bloques y sintaxis evolutiva— en contraste con lenguajes como JavaScript, Python, Go y Clojure, y se conecta con preguntas más profundas sobre la simplicidad, la “magia” y cuánto más de sintaxis debería seguir añadiendo un lenguaje maduro. Varios comentaristas también tratan el tipado estático opcional y los sistemas de tipos (por ejemplo, Sorbet, TypeScript) como un eje alternativo para mejorar la robustez en lugar de nuevas características sintácticas.

Recepción general del artículo y la función

  • A muchos comentaristas les gusta la serie y ven la sintaxis de reenvío de argumentos ... como elegante, expresiva y útil para Ruby en el mundo real (por ejemplo, objetos de servicio en Rails).
  • Otros consideran que el nuevo azúcar sintáctico es feo, confuso o “inútil”, especialmente si vienen de versiones antiguas de Ruby o prefieren una sintaxis mínima y explícita.

Elipsis ... vs la convención de “código omitido”

  • Varias personas señalan la confusión porque ... es tanto sintaxis válida de Ruby como una convención común para indicar “código omitido”.
  • Se sugieren varias alternativas:
    • Usar . . . con espacios, comentarios o marcadores textuales como [..trim..].
    • Depender de funciones del lenguaje como todo! de Rust o ... de Python como marcador de posición.
  • Se cita que varios lenguajes ya usan ... para variádicos/spread, así que algunos argumentan que Ruby no está rompiendo ningún “estándar de la industria”.

El modelo de argumentos y bloques de Ruby

  • Las explicaciones aclaran que Ruby tiene:
    • Argumentos posicionales y nombrados, más un bloque opcional.
    • Rarezas históricas en torno a hashes frente a argumentos nombrados, corregidas en Ruby 3.
  • Se discuten bloques frente a procs frente a lambdas:
    • Los bloques son cierres implícitos con semántica especial de retorno.
    • Los procs/lambdas son objetos invocables explícitos, con distinto comportamiento de flujo de control.
    • Algunos ven tres abstracciones “parecidas a funciones” como demasiado complicadas; otros las consideran potentes e intuitivas una vez aprendidas.

Calidad de diseño: Ruby frente a otros lenguajes

  • Un lado sostiene que las múltiples convenciones de llamada y el azúcar sintáctico de Ruby indican un diseño defectuoso o sobredimensionado frente a modelos más simples (por ejemplo, “solo pasar objetos y funciones” como en JavaScript).
  • La opinión contraria:
    • La sintaxis y la semántica de Ruby se consideran cuidadosamente pensadas y muy legibles.
    • Muchos lenguajes de la misma época tomaron decisiones torpes; Ruby no es de forma única malo.
    • Ruby ofrece un techo alto para código elegante tipo DSL, pero también un suelo muy bajo para “magia” ilegible.

Tipado estático y sistemas grandes

  • Algunos argumentan que Ruby debería priorizar el tipado estático opcional; otros afirman que tener dos sistemas de tipos dentro de un lenguaje es mala ingeniería.
  • Se citan TypeScript y los tipos de Python como ejemplos exitosos; Sorbet y otras herramientas de tipado para Ruby se ven como útiles pero menos potentes.
  • Hay un fuerte desacuerdo sobre si el tipado estático es esencial para sistemas grandes y de larga vida o una práctica sobrevalorada y de retroalimentación lenta.