2009-02-25 17 views
10

¿Cuáles son las cosas que deseas que Ruby (y, en términos más generales, la comunidad de Ruby) mejoren?¿Qué cosas te gustaría mejorar en el lenguaje Ruby?

Leo somewhere que Ruby es la hija de Smalltalk y LISP, con Miss Perl como niñera.

Tengo mucho respeto por los padres de Ruby, pero no estoy seguro de que me guste la influencia que la señorita Perl tuvo en el niño. Específicamente, no me gustan las variables predefinidas: necesito un cheat sheet para saber lo que significan. Podrías decir "simplemente no los uses". Bueno, yo no ... pero otras personas sí. Y cuando descargo un plugin en la Web, no tengo más remedio que buscar mi hoja de trucos si alguna vez necesito ir y tocar el código fuente. Solo desearía que quitaran esos del lenguaje en sí.

Además, creo que Ruby es demasiado un objetivo en movimiento. Mi código se rompe en cada nueva actualización de Ruby, incluso en versiones menores. Esto también se aplica a Ruby on Rails y a la mayoría de los complementos de Rails con los que he trabajado: cambian todo el tiempo, y a nadie parece importarle si los cambios lo rompen todo o no. En mi humilde opinión, aunque me encantan muchas cosas en Ruby, esta falta de estabilidad es casi un fracaso.

+0

Usted puede responder a sus propias preguntas, pero si usted se preocupa de no ser grosero, hacerlos en las respuestas de la comunidad. – Slartibartfast

+0

¡Oye, nunca antes había notado esa casilla de verificación! Gracias por la pista. – MiniQuark

+0

Creo que es más un caso de Perl y Smalltalk siendo los padres directos, con Lisp como amigo de la familia. –

Respuesta

0

Me gustaría que deshacerse de las variables predefinidas : $!, $&, $+, etc.

+0

Siempre puede incluir English.rb (que es parte de la biblioteca estándar) si no le gustan las variables globales crípticas. http://www.ruby-doc.org/core/files/lib/English_rb.html –

+1

interesantes, gracias por el enlace. Pero mi punto es que siempre que * anyone * use esas variables predefinidas, aún tendré que mantener mi hoja de trucos lista. – MiniQuark

7

deseo de la gente consideraría compatibilidad entre versiones menores como una regla inquebrantable cuando se libera un nuevo idioma (o biblioteca o marco) versión.

+0

¿Quiere decir cambios de "versiones menores" entre 1.8.xy 1.8.y? ¿Qué tipo de problemas has encontrado? –

+0

Sí, me refiero a cambios entre 1.8.xy 1.8.y. Esos cambios deben ser 100% indoloros, y no lo son. Los cambios de 1.x a 1.y pueden implicar algunas refactorizaciones menores. Los cambios de 1. a 2. pueden romper todo, está bien. – MiniQuark

+0

¿Qué tipo de problemas ha encontrado al cambiar entre 1.8.xy 1.8.y? –

1

Agradecería poder instalar ruby ​​1.9 como un RPM en lugar de tener que usar la fuente.

+0

Su distribución es responsable de proporcionarle paquetes. Si no lo hacen, una búsqueda rápida arrojará resultados para Ruby 1.9.1 RPM. Esto no tiene nada que ver con Ruby en absoluto. –

+0

@ Nathan: entiendo a qué te refieres. Pero el hecho de que no tenga nada que ver con el lenguaje en sí no significa que sea una queja irrelevante sobre el uso de Ruby. Por ejemplo, podría quejarme de que los desarrolladores de Ruby son caros: no me quejo del lenguaje en sí, sino de su entorno. – MiniQuark

+0

Por cierto, la guerra de "rubygems versus Debian" tiene que terminar. – MiniQuark

0

Me gustaría tener soporte para metaprogramación estática en tiempo de compilación. El Converge Programming Language podría ser un buen punto de partida.

2

Deshacerse de la distinción artificial entre Módulos y Clases sería agradable.

Tanto los módulos como las clases son espacios de nombres. Los módulos también son mixins, mientras que las clases no lo son. Las clases también se pueden crear instancias mientras que los módulos no. Esta distinción es innecesaria. Solo deshazte de los Módulos y permite que las Clases sean usadas como Mixins.

Un ejemplo de un idioma donde esto funciona es Newspeak.

+0

+1 Interesante. Yo uso mixins en Python: son simplemente clases. Solo usa herencia para "incluirlos". – MiniQuark

+3

La herencia y mixins son diferentes. – nitecoder

+0

No se puede mezclar una clase en una clase, a pesar de 'Class

1

Make Ruby complete Message Enviado, deshágase de todo lo que no sea un mensaje de envío: variables locales, variables globales, variables de instancia, variables de jerarquía de clases, constantes, variables globales mágicas, constantes mágicas, operadores integrados, palabras clave integradas, incluso literales. Consulte Self, Ioke o Newspeak por la increíble potencia y elegancia que esto genera.

1

Reemplace el sistema Mixin con un sistema Traits.

+0

Verificar. (Bueno, está bien, no es reemplazado * *, * se añadió *.) –

3

Deseo que se documenten algunos de los módulos de menor uso de la biblioteca estándar.

+2

Afortunadamente, esto es algo que se puede solucionar sin ser un contribuyente principal Ruby. –

+1

Hubo un mensaje hace unos meses preguntando si la biblioteca estándar era un ghetto. –

-2

Reemplace las excepciones con un sistema de estilo de Lisp común Conditions sistema.

3

Make require -los archivos son menos dolorosos. No me pregunten cómo, pero tal vez tengan un archivo dedicado a conocer las rutas involucradas y simplemente deshacerse de la ruta de acceso relativa de todo lo demás.

+0

Ruby 1.9 tiene 'require_relative', lo que hace que la mayoría de las veces no requiera archivos externos, pero estoy de acuerdo en que debe haber algún tipo de' project root' o 'application path' para trabajar. –

Cuestiones relacionadas