¿Qué puede aprender JavaScript de Ruby?

Question

El grupo de trabajo ECMAScript ha comenzado a trabajar en la próxima edición del idioma. ¿Qué pueden aprender de Ruby?

Answer 1

Esto es en realidad una cuestión mucho más difícil de lo que parece al principio.

La razón principal de esto es que se ha demostrado ser muy difícil obligar a los proveedores de navegadores, a modo de especificación, para implementar la mascota o características favoritas de los amantes del lenguaje, usuarios, otros proveedores o académicos sin muy buenas justificaciones . Así es como terminamos con la especificación de ES4 casi muerta en la mesa, que produjo una ES Harmony mucho menos ambiciosa (aunque todavía bastante impresionante). Un lenguaje como JavaScript que tiene problemas de implementación y puesta en práctica tan terriblemente difíciles simplemente no puede ser el tipo de patio de recreo experimental impresionante que Ruby ha sido durante gran parte de su vida. Cualquiera que haya seguido es-discuss (la lista de correo de desarrollo de lenguaje ECMAScript) probablemente ya haya notado que se requieren muchos meses de debate y experimentación para simplemente articular y acordar características comunes del lenguaje como, en la memoria reciente, sobrecarga del operador o corto forma la notación lambda.

Tal vez sea demasiado pedirle a cualquier grupo de trabajo que especifique una especificación que apunte a todos los dispositivos del planeta. En la superficie, parece que es una banda muy estrecha de lecciones, incluso las sociales, que pueden transferirse fácilmente de Ruby a JavaScript.

A tal efecto, y para facilitar la carga de Brendan Eich y su grupo:

Una de las "lecciones" con más urgencia útil para llevar a la lengua desde una perspectiva inspirada en Rubí (o LISP) sería maleabilidad del lenguaje. La capacidad de introducir nuevas características, ataques de sintaxis y lenguajes específicos de dominio que no provengan de un grupo interno de escritores de especificaciones sería increíblemente valioso. Permitir que el idioma sea un buen lugar para las extensiones modulares del idioma que se creará, y para aquellas extensiones que sean autohospedadas, a fin de minimizar los riesgos de fragmentación y permitir que esos cambios penetren y se purguen, etc.

Tal maleabilidad permitiría a la comunidad en general aplicar lecciones de todo tipo de direcciones y permitir que Internet decida en el tiempo qué lecciones valen la pena de qué idioma, etc. Ya tenemos una alta tasa de iteración y la evolución que ocurre en los otros extremos de este sándwich, es decir, en los navegadores mismos (por ejemplo, HTML5) y en las bibliotecas js. Si eso pudiera suceder más íntimamente en el nivel de idioma, podríamos ver que algunas cosas muy interesantes suceden muy rápidamente.

[adenda/editar]:

El lenguaje tiene que ser capaz de transformarse de manera significativa debido a que un pequeño grupo de personas es simplemente incapaces de anticipar todas las cosas que alguna vez va a ser utilizado para. Un tema que aparece en es-discuss a menudo es esa corriente subyacente de diseñar "un lenguaje para los próximos 10-15 años". En mi humilde opinión, este es un objetivo increíblemente poco realista. Si no lo construye, el sistema hará que desarrolle una alternativa mucho antes de la duración prevista de la especificación.Con la aceleración inmensa en el motor de JavaScript/tecnología JIT en los últimos tiempos, ya estamos viendo las primeras señales de que esto ocurra en forma de nuevos lenguajes que se escriben encima de JavaScript o que se compilan de forma cruzada sobre la marcha en JavaScript. Sí, incluso Ruby: programación de las funciones http://hotruby.yukoba.jp/

Answer 2

Tener un nombre que suena como una piedra preciosa es mucho mejor que un nombre que suena como una enfermedad de la piel.

Pero no nombrar a su nuevo idioma después de la cosa más caliente de hoy (que es la forma en que todos nos dieron en este "Java" desorden de la escritura en el primer lugar ....)

Answer 3

Abrazo, no tratar de enterrarlo en lenguaje estático construye

Answer 4

no puedo ver a mucho de lo que se podría aprender de Ruby. El grupo de estándares ya ha dado al lenguaje la forma de volver a enviar mensajes o mensajes al prototipo. La funcionalidad method_missing puede ser genial para implementar, pero no es tan necesaria como mejores instalaciones de refelction.

Answer 5

compilar una biblioteca estándar sobre el uso intensivo de cierres, tanto para la iteración de recopilación como para la adquisición de recurso/rendimiento de recurso/disposición del patrón de recursos. esa es una de las mayores victorias de ruby, imo. por supuesto, parte de lo que permite esta es la brillante decisión de dar a cada método un parámetro de cierre 'libre', con soporte sintáctico, por lo que probablemente no se verá tan bien en javascript. las técnicas aún son útiles, sin embargo.