Hablemos de RUBY

Pues yo te hacía más de Ruby, ya sabes, un cool boy como DHH.

¿DHH? ¿Te refieres a David Heinemeier Hansson?

El bueno de David, sí, el que parece que tiene problemas con TypeScript.

¿TypeScript? Mejor no abramos ese melón ahora.

Ruby y Python se ven iguales.

Ni por asomo. A ver, Ruby está basado en Python, pero cambian muchas cosas.

De hecho, está basado en Python y Perl, según su creador Yukihiro Matsumoto.

Mats para los amigos.

Quería un lenguaje más potente que Perl. De hecho, nunca le gustó Perl y lo consideraba un juguete.

¿Un juguete? ¿En el sentido de que es poco serio?

Sí. Tampoco le gustaba Python porque no lo consideraba orientado a objetos.

¿Qué?

¡Pero si tiene una muy buena orientación a objetos!

Ya, Chip. ¿Cómo haces métodos o atributos privados en Python? Pues... ¡Pues eso mismo!

El caso, como no encontraba un lenguaje de scripting que tuviera los elementos que él buscaba, Creo, Rubí.

Suena interesante. ¿Nos cuentas su historia? Antes de continuar, un inciso.

¿Te gustaría apoyar a nuestro canal?

No te olvides de darle a me gusta y, si no lo estás, suscribirte para no perderte futuro contenido. También puedes apoyarnos si quieres uniéndote al canal o enviándonos un gracias aquí abajo en el botoncito. Nosotros te lo agradeceremos igualmente y os avisaremos de ofertas y promociones del canal.

Y además también podemos acompañarte desde tu plataforma de podcast favorita.

Ahora sí, continúa. ¿Por qué se creó Ruby?

Como decíamos, Yukihiro—

Matz, vamos a llamarle Matz, estamos entre amigos.

Matz Sumoto, en 1993, era usuario de Perl, Python y otros lenguajes de programación, pero quería un lenguaje de scripting que fuese realmente orientado a objetos.

¿Orientado a objetos como Smalltalk?

No, ningún lenguaje que dice ser orientado a objetos es del tipo Smalltalk. Al menos de momento, y aunque usando Ractor estamos más cerca, no, no es como Smalltalk.

Algo sí, pro, es decir, la creación de objetos, el hecho de que todo es un objeto, incluidos los literales...

Algo sí, pero como dijimos en nuestro capítulo del desastre del billón de dólares, lo importante en la programación orientada a objetos no son los objetos. Son los mensajes.

Vale, entonces, Matz decidió que como no había un lenguaje de scripting que implementara la orientación a objetos como él la concebía, decidió crear su propio lenguaje.

Además, él veía su lenguaje como un núcleo Lisp sobre el que crearlo todo.

Una base de Lisp, pero un momento, Lisp no es orientado a objetos, sino más bien funcional. ¿Qué pinta en todo esto?

Ruby implementa metaprogramación y es bastante importante porque permite definir DSL empleando el lenguaje Ruby.

¿DSL? ¿Metaprogramación?

La metaprogramación es una forma de convertir el código que escribimos en datos para poder procesarlo y cambiarlo en tiempo de ejecución, o ejecutar nuestro código en tiempo de compilación para generar un código más eficiente. El DSL es Domain Specific Language y es una forma de acomodar el lenguaje para servir a un dominio específico, orientar el lenguaje al problema.

Tenemos que hablar algún día sobre Lisp, y seguramente sobre DSL también.

¡Sí! Dejadnos un comentario si queréis oír alguna de esas historias.

Pero entonces, ¿el código en Ruby son datos y por eso se pueden modificar?

Algo así. Hay mucho azúcar sintáctico de por medio.

¿Azúcar? ¿En serio?

Sí, el azúcar sintáctico es lo que ayuda a las personas a leer el código de forma más comprensible. Por ejemplo, una suma 2+ 5 ¿Cómo lo escribes?

Pues pongo el 2, el signo de suma y el 5.

Pero has puesto la operación, la suma, en medio. ¿Por qué no escribir suma y sus 2 parámetros 2 y 5?

¿Como lo hace Lisp?

¡Exacto! Si escribimos primero lo que queremos hacer, quedaría más claro y mucho más fácil para el lenguaje entender que es una suma y que debe tener 2 parámetros.

Entonces, ese azúcar ayuda a que podamos escribir el operador en medio Y en una primera pasada el compilador lo traslada a algo más comprensible para él poniéndolo al principio, ¿cierto?

¡Exacto!

Recapitulando: Ruby es un lenguaje orientado a objetos.

Realmente diría que es uno de los pocos actualmente en los que todo, y digo todo, es un objeto.

Dispone de metaprogramación como Lisp y sigue muy activo.

Si el lenguaje fue desarrollado en Japón y se empleó en sistemas... ¿Cómo se hizo tan conocido?

Hay muchos factores que contribuyeron a la fama de Ruby.

Uno tuvo que ser Rails, segurísimo.

Sí, aunque no el primero. Es decir, los creadores de Rails no habrían sabido del lenguaje si no llega a ser por un libro publicado por la editorial Pragmatic Programmers.

¡Anda! ¿Otro lenguaje impulsado por una editorial como Perl?

Exacto. Fue trabajo de Dave Thomas, que por cierto ha dejado la primera edición de su libro Programming Ruby abierto en internet para que cualquiera pueda leerlo.

¡Qué detalle! ¿Qué dice en su libro?

Dice que como programador pragmático está siempre en la búsqueda de nuevos lenguajes y herramientas para hacer la vida del programador más fácil. Herramientas que hagan el trabajo mejor.

Supongo que Java no estaría en su lista.

Probablemente tampoco Go.

¡Retira eso!

En su lista de momento, y que sepamos, solo estuvo Ruby y ahora Elixir.

¿Cuáles son los motivos que le llevaron a fijarse en Ruby inicialmente?

Principalmente su creencia de que cuanto menos código se escribe, menos puedes equivocarte.

Y tus manos y tus dedos te lo agradecerán.

Además, enfatiza las bondades de Ruby diciendo que su orientación a objetos es mejor y más pura que la que encontramos en C++ o Java.

Sí, ya lo sabíamos, lo has comentado un par de veces.

Es importante.

¿Y para los programadores de Python y Perl?

Pues dice que encontramos las expresiones regulares, atajos, dinamismo, Etcétera.

Podemos resumir que su principal motivación era la facilidad de aprender.

Yo me quedaría con la productividad.

Yo lo cambiaría por Python.

Dave Thomas publicó el libro en el año 2000, lo cual sirvió como base para que programadores como DHH se fijaran en el lenguaje.

DHH se fijó en Ruby y por eso creó Rails en 2004 gracias al libro. ¡Tiene sentido!

¿Por qué lo llamáis DHH?

Mats, DHH, estamos entre amigos.

Antes de seguir con Rails, ¿por qué se llama Ruby?

Según la página oficial de Ruby, en su sección de preguntas y respuestas, dice que Ruby está basado principalmente en Perl.

Yo creo que tiene algo más de Python.

Discutible.

Tomó el nombre de una piedra preciosa para estar en concordancia con la perla. ¡Curioso!

Incluso inicialmente tenía dudas si llamarlo Ruby o Coral.

El arrecife de coral tiene más similitud con perla que un rubí.

Pero es más difícil de escribir. Si te fijas en el teclado, teclear Ruby es mucho más fácil.

Yo uso Dvorak.

Sigue siendo más fácil, son menos letras.

Creo que no quedan dudas al respecto. Querían un nombre con analogía a Perl y se decidieron por Ruby por facilidad.

Vale, ¿y ahora hablamos de Rails? Creo que es importante porque fue determinante para la acogida de Ruby como lenguaje de uso masivo.

Exacto, Rails fue uno de esos hitos que hizo elevarse a Ruby por las nubes.

¿Por qué eligieron Ruby para crear Rails y no otro lenguaje más sencillo como PHP?

De hecho, tiene gracia que pongas de ejemplo a PHP porque la relación entre DHH y Jason Fried comenzó con trabajos en PHP. DHH hacía esos trabajos para Jason y este le pagaba con portátiles y máquinas.

¿Nada de dinero?

Nada de dinero. Máquinas y portátiles.

¿Cómo tuvo la idea de hacer Rails usando Ruby?

Pues parece que comenzó a leer sobre Ruby en 2003, gracias a todos esos libros que las editoriales ofrecían sobre el lenguaje y... ¿Tuvo una epifanía? Algo así. El código en Ruby le parecía pseudocódigo, así que le propuso a Jason convertir lo que tenían hecho en PHP para crear un sistema de seguimiento de tareas en su framework.

¿No sería más correcto Rails on Ruby por eso de que el framework Rails usa el lenguaje Ruby?

Técnicamente es correcto, pero como que no encaja.

Si quieres hacer el juego de palabras on Rails, que viene a traducirse sobre ruedas, pues es mejor dejarlo como Ruby on Rails.

Vale. ¿De dónde viene el nombre de Rails o Ruby on Rails?

Pues parece que DHH comentó en una entrevista que estaba en uno de esos grandes metros de la ciudad de Nueva York Y estaba muy alerta porque era la primera vez que visitaba la ciudad.

Sentía el peligro.

De repente escuchó a una mujer gritando que se le había caído el anillo.

¿Un anillo caro?

No es relevante. Lo relevante es que cayó sobre las vías y DHH se lanzó a su ayuda.

¡Un verdadero caballero! ¡Aprende, chico!

Pues se lanzó a las vías, siguió donde apuntaba la mujer y allí lo vio. Un anillo con un enorme rubí sobre las vías del metro.

Un rubí sobre raíles, muy apropiado... y muy caro.

Pertenecía a la abuela de la señora, que había muerto recientemente.

Caro sentimentalmente hablando.

No sé, a mí la historia no me parece cierta.

Si DHH la contó en una entrevista, tiene que serlo.

Bueno, Rails se hizo famoso gracias a que DHH pasó mucho tiempo solo dedicándose al marketing del framework, yendo de conferencia en conferencia, entrevista tras entrevista... Y creó polémica al atacar a Java.

¿Quién no ataca a Java?

Parece que a la gente de Java no le gustó nada, pero la técnica fue bastante buena porque Ruby on Rails ha sido empleado en sitios tan grandes y conocidos como GitHub, Shopify, Twitter, Airbnb, Kickstarter, Twitch, entre otras muchas.

Son empresas grandes y prestando servicio a millones de usuarios. Pero hemos oído muchas veces que Ruby no escala. Entonces, ¿Ruby escala?

Es curioso que lo preguntes.

¿Y eso?

Recientemente Pragmatic Programmers publicó un libro que se titula Rails Scales! Así en exclamación, como anunciando que Ruby sí que escala.

¿Y escala?

En principio diremos que no hay tecnología que escale o no. Puede facilitarnos las cosas, pero todo dependerá del diseño de la infraestructura Y por ese motivo el libro habla de Rails, porque presenta una infraestructura.

¿Rails propone una forma de programar y una forma de desplegar?

Sí. El framework de Rails se basa en proponer formas de trabajar y de poner ese código en producción o desplegar. Por lo tanto, influye en cómo se comportará nuestro desarrollo.

¿Esto tiene que ver con la convención sobre configuración que emplea Rails?

¡Exacto! Rails minimiza la configuración y la forma en la que podemos organizar nuestro código, los elementos que debemos usar, todo nos viene dado por convención.

Aunque aún así puedes reconfigurar algunas partes, ¿no?

Sí, pero eso no sería aceptado por los programadores que apoyan y usan Ruby on Rails.

¿Hay algo de dogma en el uso de Rails?

Lo hay en todos los lenguajes y frameworks.

Entonces, Si Rails escala o no también depende de si seguimos sus convenciones o no.

Exacto. Aunque también depende de las características que le provea Ruby, no solo a nivel de programación sino también a nivel de rendimiento y aislamiento de sus hilos de ejecución, que fue un tema muy controvertido durante los últimos 20 años.

Podríamos entonces lanzar la pregunta: ¿Qué avances ha tenido Ruby?

Pues en verdad, si nos basamos solo en la línea original, podemos encontrar que Ruby 3 ha sido con diferencia la versión donde más se ha avanzado en este sentido.

¿Lo dices por Ractor?

Sí, entre otras cosas. Ruby 3 es conocida como 3x3 porque dicen que ha mejorado la velocidad 3 veces en comparación a Ruby 2.

3x3 da 9, no lo entiendo.

Cuando dijiste la línea original, ¿a qué te referías? ¿Hay más intérpretes o máquinas virtuales de Ruby?

Sí, muchas de hecho. Es bastante famoso Ruby MRI o Matz Ruby Interpreter, que es la implementación que soporta la comunidad y Matz Sumoto.

Creo que había una sobre la Java Virtual Machine llamada JRuby.

Sí, también otra llamada Rubinius.

Suena a Rubius.

Nah, esa fue una máquina virtual empresarial, pero que parece no tuvo tanto éxito. Últimamente no tiene mucha actividad.

¡Vaya! Pues sí que hay competencia.

Pues no había hecho nada más que empezar. También está JRuby, que estuvo compitiendo con MRI hasta 2009, que fue cuando se fusionó a MRI creándose la versión 1.9 de Ruby. GraalVM de Oracle, que soporta Truffle Ruby. RubyMotion, pensado para iOS. Y MRuby, pensado para sistemas embebidos.

Aunque de todas las mencionadas parece que tan solo MRI, JRuby y TruffleRuby son opciones a tener en cuenta.

Eso parece. Conclusiones.

Nos ha quedado largo el capítulo.

Es que había mucho que contar sobre Ruby.

Hemos dicho más que cuando hablamos sobre Python.

En tu mano queda. Si te animas a contar algo más sobre Python hacemos otro capítulo.

Le daré una vuelta.

Ruby es un lenguaje que ha tenido un gran impacto.

Rails también. Según parece, influenció a Django.

Aunque Django tiene cosas propias mucho mejores. Habría que hacer un capítulo.

También a Catalyst de Perl e incluso a otros como Laravel de PHP.

¿Crees que DHH se llevaría bien con el creador de Laravel?

Creo que a ambos les gustan los coches caros.

Pero ahora es el turno para vosotros. A ver qué nos contáis en la caja de comentarios.

¿Habéis usado Ruby y Rails? ¿Qué os pareció?

¿Deberíamos decir DHH o David?

David quizás se pronuncie de otra forma en Dinamarca.

¿Qué otras cosas sabéis de Ruby?

Y más importante, ¿queréis más Python?

Déjanos tu comentario. Tengo una misión para ti.

¡No! ¡Pídeme cualquier cosa menos eso!

Sé que has estado jugando con el lenguaje, sé que te ha gustado.

¡Maldita sea, Chip!

No sé qué prejuicios te impulsan a rechazar a Julia, Pero hay que acabar con ello.

Hay miles de lenguajes. ¿Por qué yuliā?

Porque será el siguiente y casi nadie lo conoce. Es nuestra misión.

¿Y no podríamos hablar de otro que también valga la pena y sea menos conocido?

En otro momento. Yuliā merece su espacio.

Lo intentaré.

Continuará.