Yukihiro Matsumoto: «Ruby se ha diseñado para los humanos, no para las máquinas»

Introducción

Es un auténtico placer que nuestro buen amigo Yukihiro Matsumoto, creador del lenguaje de programación Ruby, haya podido reunirse con nosotros en RubyRussia 2019 como ponente por segunda vez, después de su última charla hace tres años en RubyRussia 2016.

En todo este tiempo desde que empezamos a celebrar la conferencia (ahora, más de 10 años), Ruby ha pasado por una gran evolución, y Evrone ha crecido y se ha desarrollado en paralelo.

Grigory Petrov, responsable de relaciones con los desarrolladores de Evrone, se reunió con Matsumoto para escuchar de primera mano cómo se siente al ser una estrella, la filosofía detrás del diseño y evolución de Ruby, y un poco sobre la vida y cultura japonesas.

La entrevista

Grigory: Esta es tu segunda visita a Rusia; la primera fue en 2016 y, desde entonces, el número de asistentes a RubyRussia se ha duplicado. Muchas gracias por tu ponencia, me ha encantado. ¡Y ahora ya conozco las respuestas a algunas de las preguntas que iba a hacerte!

He visto que la gente no solo te hace preguntas, sino que también te piden que te hagas fotos con ellos e incluso algunos te pedían autógrafos… ¡Eres toda una estrella! Como desarrolladores, nos gusta el lenguaje y lo que haces con la comunidad. Pero… ¿esto te ocurre con gente de todo el mundo o es algo específico de Rusia?

Yukihiro: La gente quiere hacerse fotos conmigo en todas partes: en todos los países y en cada conferencia, siempre quieren hacerse fotos conmigo. ¡Pero creo que es la primera vez que alguien me pide un autógrafo!

Grigory: Como creador de un lenguaje de programación, imagino que recibirás numerosas preguntas, sugerencias, ideas, etc. ¿Cuál es la pregunta que te realizan con más frecuencia?

Yukihiro: La pregunta más popular es la siguiente: «Soy de la comunidad del lenguaje X; ¿podrías introducir una característica del lenguaje X en Ruby?». O algo similar… Y mi respuesta habitual a estas peticiones es… «No, no haría eso», porque tenemos distintos diseños de lenguaje y distintas políticas de desarrollo de lenguaje.

No podemos usar una característica del lenguaje X y aplicarla directamente en Ruby; aunque en algunos casos está claro que tomamos prestadas ideas de otros lenguajes, como Python, JavaScript y Elixir. Me hacen esta pregunta una y otra vez, pero ofrecer una respuesta positiva es muy inusual.

Grigory: Es genial que puedas decir que no; creo que las tecnologías «diseñadas por la comunidad» no tienen por qué terminar con los mejores resultados. Hay un gran número de lenguajes y tecnologías distintos, así que podemos analizar los procedimientos recomendados e implementar solo aquellos que sean adecuados.

Hace poco, hemos visto la tendencia de añadir el tipado gradual a lenguajes de tipado dinámico, como JavaScript, Python y PHP. ¿Qué piensas sobre las anotaciones de tipos y el tipado gradual? ¿Por qué son tan populares? ¿Y cuáles son tus planes e ideas generales para la comprobación de tipos en Ruby 3 y versiones posteriores?

Yukihiro: Por ejemplo, Rust y Go son lenguajes de tipado estático. Si el software creado con estos lenguajes crece con bastante rapidez, puedes acabar manteniendo enormes bases de código, que pueden llegar a alcanzar hasta millones de líneas de código, con cientos de miembros de equipos trabajando a la vez y, en estos casos, la comprobación de tipos es un método muy útil para detectar errores de coincidencia.

En cambio, con los lenguajes de tipado dinámico, tenemos que escribir pruebas para evitar errores de coincidencia de tipo en el código. A medida que crece el software, también crece el volumen de las pruebas (y las tareas relacionadas con escribirlas), y eso realmente ha ayudado a impulsar la reciente popularidad de tipados estáticos y graduales.

Sin embargo, al mismo tiempo, la declaración de tipos estáticos es redundante y, con un lenguaje como Ruby, queremos la ventaja de la comprobación de tipados estáticos sin la redundancia de declaraciones de tipos manuales.

Para la comunidad de Ruby y el lenguaje Ruby, intentamos satisfacer ambas necesidades al mismo tiempo: vamos a separar el archivo de información de tipos del programa de Ruby (el programa de Ruby en sí no contiene ninguna información de tipos estáticos). En su lugar, usamos un archivo de información de tipos separado (denominado «archivo de firma de Ruby») que contiene información sobre la biblioteca, las gemas y tus programas.

Vamos a proporcionar una herramienta, denominada «generador de perfiles de tipos», que puede recopilar información de tipos sobre tu software. Después de recopilar la información de tipos de la biblioteca y el software, el generador de perfiles de tipos tendrá toda la información necesaria sobre todas las clases y métodos, por lo que puede detectar contradicciones de tipos (conflictos de tipos). Incluso se puede restringir de forma manual la información de tipos en el archivo de firma para mejorar la comprobación de tipos.

En versiones futuras de Ruby, podrás comprobar los tipos estáticamente (hasta cierto punto, pero con un grado muy limitado). Tendrás el comportamiento de Ruby tradicional que realiza la comprobación de tipos en tiempo de ejecución. Con el «comprobador de tipos de nivel uno», se puede identificar entre el 40-80 % de los errores de tipos mediante la información de tipos disponible en el código fuente. Un «comprobador de tipos de nivel dos» puede generar información adicional de tipos basándose en el análisis del código en sí. Con estas herramientas, las versiones futuras de Ruby pueden proporcionar comprobaciones de tipados estáticos sin necesidad de realizar anotaciones de tipos específicas en el código.

Grigory: Durante tu charla en la conferencia, has mencionado esto y creo que se ajusta bien a la idea. Soy desarrollador de C/C++, por lo que el tipado estático me resulta algo natural, y siempre he considerado los tipos como una forma de declarar mis intenciones para ayudar al lenguaje y las herramientas a encontrar posibles errores en el futuro.

Tu idea es crear un sistema donde escribas el código en sí, pero que sea posible a partir de ese código deducir información suficiente para identificar errores sin tener que recurrir a tipos explícitos, y creo que me gusta cómo suena eso.

Es genial que realices experimentos y pruebes nuevas ideas. ¿Cuál es el futuro que imaginas para Ruby? ¿En qué dirección te gustaría que avanzara el lenguaje?

Yukihiro: En realidad, no dirijo el lenguaje ni la comunidad. Simplemente proporciono la tecnología, y es la comunidad la que decide el camino que desea tomar. Por lo menos, tengo tecnología suficiente para tantos dominios como sea posible con el fin de que el Ruby sea flexible y productivo. Por ejemplo, ahora Ruby se usa principalmente para crear aplicaciones web, pero me gustaría que Ruby se usara también en investigación, inteligencia artificial y aprendizaje automático. Estamos intentando que la tecnología pueda usarse en nuevos dominios.

Grigory: A los desarrolladores nos gusta ponerle etiquetas a todo. Por ejemplo, esto es un coche deportivo o esto es un coche familiar. También etiquetamos los lenguajes de programación: JavaScript es un «lenguaje para la web», C es un «lenguaje de nivel bajo para sistemas», C# es «para aplicaciones nativas de la interfaz de usuario de Windows». ¿Cómo clasificarías el lenguaje Ruby?

Yukihiro: Diría que Ruby es un lenguaje de programación productivo. La productividad es uno de los objetivos principales de Ruby. Diseñé Ruby para las personas, no para las máquinas. A veces, los colaboradores principales se quejan del diseño del lenguaje porque resulta difícil implementarlo de manera eficiente. El diseño de Ruby no se centra primero en el rendimiento, sino en la productividad. Eso quiere decir que los implementadores tienen un mayor desafío, pero estamos encantados de que exista ese desafío: nuestro objetivo es conseguir que Ruby sea productivo para los desarrolladores en la medida de lo posible y, al mismo tiempo, que también tenga el mejor rendimiento posible.

Grigory: Con Python, no hay elementos invocables anónimos multilínea debido a problemas de implementación. Es bueno escuchar eso para Ruby, ya que los desarrolladores principales estáis haciendo todo lo posible para facilitar la vida de otros desarrolladores, a pesar de las dificultades tecnológicas de la implementación.

Ya que hablamos sobre dificultades… Imagina que pudieras viajar al pasado y darle un único consejo a tu yo más joven, más o menos en el momento en que empezaste a desarrollar el lenguaje Ruby. ¿Qué consejo le darías a tu yo más joven?

Yukihiro: No uses demasiado código de otros lenguajes de scripting. Tu lenguaje de programación será el mejor lenguaje de programación de uso general. Las características introducidas solo para que Ruby sea más equiparable a lenguajes de scripting serán una especie de apéndice en el futuro (en su mayoría, sin ninguna utilidad hasta que produzcan errores), por lo que es mejor no centrarse demasiado en ellas.

Grigory: En el pasado, había una gran diferencia entre los lenguajes de programación «compilados» y «de scripting». En la actualidad, el mundo ha cambiado: entre máquinas virtuales, código byte y compiladores de JIT, la línea entre todos estos es bastante borrosa.

Durante esta evolución, has implementado una gran cantidad de cambios y has realizado muchos experimentos con Ruby. Algunos tuvieron éxito, y otros no. ¿Cuál crees que es tu mayor éxito en el diseño de Ruby? ¿Qué es lo que más te gusta?

Yukihiro: Si tuviera que elegir un solo aspecto, diría que los bloques. Los bloques de Ruby son bastante únicos: una abstracción bastante útil de una función de orden superior. Son mucho más sencillos que en otros lenguajes. Tienen ciertas restricciones, pero son fáciles de usar.

Grigory: Parece una coincidencia, pero los bloques son también lo que más me gusta de Ruby. En mis charlas y entrevistas, siempre digo que Ruby se basa en DSL, sintaxis simplificada y bloques. Los bloques son geniales.

Yukihiro: En lenguajes como Swift, si el último argumento es una función, puedes añadir llaves alrededor para algo como un bloque de Ruby. Hay una propuesta para que se añada una característica similar en JavaScript. Estoy muy orgulloso de esto.

Grigory: Sí, JavaScript puede emular bloques al pasar una función de flecha como el último argumento, ya que (desde ES6) tiene una sintaxis de flecha para funciones multilínea. Los bloques son geniales. Por otra parte, ¿hay aspectos que no te gusten del diseño o la evolución de Ruby? ¿Cuál dirías que es el mayor fracaso de diseño que hay que corregir o ya se ha corregido?

Yukihiro: Tengo algunos. Variables globales: son útiles para un «lenguaje de scripting». Pero ahora son más bien una especie de apéndice. También me arrepiento de añadir subprocesos al lenguaje: deberíamos tener una mejor abstracción de simultaneidad. Otro de mis errores de diseño es que algunos objetos son mutables innecesariamente. Por ejemplo, se puede cambiar la zona horaria de un objeto de tiempo existente, en lugar de crear uno nuevo. Me arrepiento de eso.

Grigory: Sí, la mutabilidad es ciertamente complicada y puede conducir fácilmente a errores en el código fuente.

Dejando a un lado los aspectos técnicos de Ruby, ¿cómo organizas tu trabajo en el lenguaje? ¿Cómo es para ti un día típico de trabajo?

Yukihiro: Soy desarrollador de Ruby a tiempo completo. Dedico la mitad del tiempo a pensar en el diseño del futuro Ruby 3. El resto del tiempo, trabajo en otra implementación de Ruby, MRuby, además de otros proyectos.

En el caso de Ruby, la implementación canónica la realizan los colaboradores principales, y yo solo necesito tomar decisiones como «este método debe comportarse así», «esta característica del lenguaje debería ser así», «la sintaxis como esto», «la semántica es esta», etc. Solo tomo decisiones, y el resto de los desarrolladores las implementan. Por lo tanto, soy mitad diseñador y mitad programador. Dedico aproximadamente un tercio de mi tiempo a MRuby.

Grigory: He echado un vistazo a tu perfil de GitHub y he visto un gran número de confirmaciones, incluso en el día de tu vuelo a Rusia. Recientemente, muchos desarrolladores afirman que están «quemados» con el trabajo. ¿Tienes tiempo libre? ¿Alguna afición? ¿Qué haces para mejorar tu bienestar y no quemarte?

Yukihiro: Por suerte, dedico todo el tiempo a trabajar en el software de código abierto. No tengo ninguna presión de los clientes. No tengo jefes. Soy mi propio jefe. Ese es el motivo por el que estoy tan relajado en el trabajo. No tengo plazos de entrega específicos, aparte de la fecha de publicación. Esta libertad me hace sentirme relajado. Ese es uno de mis secretos. El otro es que intento pasar tiempo alejado de los ordenadores y la programación. Por ejemplo, dedico tiempo o a pasear con mi perro y acariciar a mi gato. También hago servicios para la parroquia local. Paso tiempo con mi familia. El tiempo que dedico a mi vida social me ayuda mucho.

Grigory: A muchos desarrolladores de Rusia les gusta Japón como país y disfrutan con la cultura japonesa. Ven anime, leen manga y algunos de ellos incluso visitan Japón. Como nativo de Japón y desarrollador de software, ¿qué lugares y experiencias podrías recomendar a los compañeros desarrolladores que quieran visitar Japón?

Yukihiro: Japón es un país muy diverso. Puedes visitar áreas metropolitanas como Tokio, que es bastante futurista. Tenemos mucha cultura popular, como manga y anime. Al mismo tiempo, tenemos montañas, bosques y lugares históricos, como antiguos templos y santuarios. Tenemos bellos cerezos en flor. Depende de tu gusto y preferencias, así que puedes disfrutar de muchas cosas: la comida, la naturaleza y la tecnología. ¡Te recomiendo disfrutar de la diversidad del país!

Grigory: ¿Hay algo en la cultura e historia japonesas que haya influenciado a Ruby?

Yukihiro: No estoy seguro. En japonés, tenemos las cadenas de frases, que es algo similar a las cadenas de métodos en Ruby, así que a lo mejor es una influencia del idioma japonés. Japón es un país rico, y algunos de nosotros no hemos tenido que trabajar tan duro para ganarnos el pan. Esto me permite trabajar en software de código abierto, que no produce nada de dinero. No vendemos software de código abierto. Podemos ganarnos la vida con trabajos diarios o de nuestros patrocinadores, que pueden ayudarnos (también a los colaboradores) a trabajar en Ruby y mejorar la tecnología. Al menos, eso es lo que pienso.

Grigory: Por último, una pregunta con trampa. La gente quiere conocer cómo se ve el mundo a través de los ojos de otra persona: saber lo que piensan y lo que sienten. ¿Hay algún aspecto de ser el autor de un lenguaje que no resulte obvio desde fuera?

Yukihiro: Hay una cosa… A pesar de lo que otros puedan sentir, crear el lenguaje no es una tarea difícil. Los estudiantes de informática asisten a clases de implementación de lenguajes, y prácticamente todo el que se gradúa podría escribir su propio lenguaje de programación. Técnicamente, no es tan difícil.

Al mismo tiempo, la gente no entiende la naturaleza de diseñar un lenguaje. El lenguaje es como un andamio de la mente: una forma de estructurar tus pensamientos. Es lo mismo que con los idiomas humanos, como el ruso, el japonés y el inglés.

Los lenguajes de programación como Ruby, Python, JavaScript, etc., ayudan a desarrollar la mente y te permiten convertir ideas en algo tangible y útil. Esa es la finalidad principal de un lenguaje de programación.

Creo que un lenguaje de programación debería tener una filosofía que facilite nuestra forma de pensar y, por lo tanto, Ruby se centra en la productividad y en disfrutar programando. Por ejemplo, hay otros lenguajes de programación que se centran en la simplicidad, el rendimiento o algo parecido. Cada lenguaje de programación tiene un diseño y una filosofía distintos. Si te sientes cómodo con la filosofía de Ruby, eso quiere decir que Ruby es tu lenguaje.

Grigory: ¡Gracias! ¡Estos eran Grigory Petrov y Yukihiro Matsumoto en RubyRussia 2019! ¡Arigato!

Yukihiro: ¡Arigato!

Una vídeo entrevista con Yukihiro Matsumoto:

En la entrevista con Yukihiro, hemos aprendido algo sobre la filosofía de Ruby y los planes futuros del equipo principal para el desarrollo del lenguaje. Es un placer ser buenos amigos de Yukihiro, quien nos inspira a usar Ruby en una amplia variedad de proyectos de desarrollo de software. Si tiene buenas ideas y le gusta Ruby tanto como a nosotros… ¡nos encantaría crear un nuevo proyecto juntos!