🤾 🚹 🚾 Transcripción de mi entrevista con el autor Ruby 🤑 🐸 ✋🏽

Durante la conferencia de otoño, Ruby Russia I, por los derechos del organizador, quedó al margen del autor y Ruby le dio una entrevista de ~~interrogatorio de~~ una hora . Traté de elegir preguntas que no estuvieran hastiadas para que las respuestas nos fueran útiles, y no "para bien o para mal". ¡Y el abuelo me sorprendió, el viejo desarrollador plus! Debajo del corte está la transcripción de la entrevista, la opinión no trivial de Yukihiro Matsumoto sobre los tipos en general y los hacks en particular, así como la oportunidad de discutir todo esto en los comentarios. Estoy en contacto con el equipo Ruby Evrone . Invitamos a Matsumoto a Moscú regularmente, existe la oportunidad de formular preguntas interesantes de antemano para futuras entrevistas.

Como fundador del lenguaje, obtienes muchas sugerencias e ideas. ¿Sobre qué te preguntan más a menudo?

La gente a menudo pregunta: "Uso el lenguaje X. ¿Por qué no agregas una función de X a Ruby?" En la mayoría de los casos, respondo que esto no es posible. Tenemos diferentes diseños de idiomas y diferentes políticas de idiomas. No podemos simplemente tomar algunas funciones de X y agregarlas a Ruby. Pero a veces todavía tomamos prestadas buenas ideas de otros lenguajes como Python, JS o Elixir.

Ahora los lenguajes dinámicos agregan la capacidad de especificar tipos explícitamente. Esto ya apareció en Python, PHP y JavaScript (TypeScript). ¿Qué piensas sobre esto, cómo funcionará con los tipos en la tercera versión de Ruby?

Rust and Go son lenguajes estáticamente escritos. En proyectos grandes, cientos de desarrolladores crean y mantienen mucho código, millones de líneas. En tales casos, la verificación de tipo es conveniente, le permite detectar errores. En otros casos, debemos escribir una prueba para asegurarnos de que los tipos utilizados sean correctos. Los volúmenes de prueba aumentan con el crecimiento del proyecto. En esto, veo la razón de la popularidad del tipeo estático, ya que su uso reduce el número de pruebas.

Al mismo tiempo, la declaración de tipo explícita es información redundante. En el caso de Ruby, el lenguaje en sí puede ocuparse de los tipos y nuestro código simplemente funcionará. Queremos los beneficios de la verificación de tipo, pero no queremos la redundancia de su especificación manual. Como comunidad de lenguaje Ruby, nos esforzamos por proporcionar a los desarrolladores todas las características. Utilizaremos un archivo con tipos independientes de nuestro programa Ruby. Por lo tanto, el programa Ruby no contendrá información de tipo.

Un archivo de información de tipo separado, que llamamos el "archivo de firma de ruby", contendrá información sobre los tipos utilizados en bibliotecas, gemas y su código de biblioteca. También proporcionaremos una nueva herramienta, el "generador de perfiles de tipo", que recopilará información de tipo. Puede detectar conflictos de tipo o conflictos basados en el código mismo o anotaciones de tipo.

Usando archivos de firma, puede refinar los tipos que usa y ayudar al generador de perfiles a verificar su código. Después de recopilar toda la información de tipo en las bibliotecas utilizadas y su código, el generador de perfiles tiene suficiente información para encontrar posibles errores.

Las versiones futuras de Ruby podrán realizar comprobaciones de tipo estático, hasta cierto punto. Aún así, Ruby es un lenguaje dinámico, y las comprobaciones de tipos principales en él son habituales durante la ejecución de nuestro código. La verificación de tipo "primer nivel" utiliza información sobre los tipos en el código y ayuda al desarrollador a detectar del 40 al 80 por ciento de los errores. La verificación de tipo "segundo nivel" genera información de tipo basada en el código mismo. En el futuro, con la ayuda de dichas herramientas, podremos proporcionar una verificación de tipo estático en Ruby sin la necesidad de que el desarrollador las especifique explícitamente ...

Me gusta esta idea y espero futuras versiones de Ruby para ver qué tan bueno será este enfoque. Es genial que estés experimentando con el idioma. ¿Qué futuro ves para Ruby, en qué dirección estás desarrollando el lenguaje?

De hecho, no controlo el idioma o la comunidad. Solo proporciono tecnología, y la comunidad decide qué camino tomar. Tenemos suficiente tecnología para casi todas las áreas para hacer que Ruby sea flexible y productivo. Por ejemplo, Ruby se usa principalmente para crear aplicaciones web. Pero quiero que Ruby se aplique en otras áreas: investigación e informática, inteligencia artificial, aprendizaje automático, en el campo de la innovación. Estamos tratando de hacer que la tecnología sea adecuada para una aplicación más amplia.

A los desarrolladores nos gusta llamar a las cosas nombres diferentes. "Este es un automóvil deportivo", y este es un "automóvil familiar". JavaScript es un lenguaje de desarrollo web. C es un lenguaje de sistema de bajo nivel. ¿Cómo te gusta llamar a Ruby, posicionarlo?

Yo llamaría a Ruby "un lenguaje de programación productivo". La productividad es uno de los objetivos principales, las tareas principales de Ruby. Fue diseñado para personas, no para automóviles. A veces los desarrolladores se quejan del diseño del lenguaje cuando parte de la sintaxis es difícil de implementar de manera eficiente. El diseño de Ruby no se centra en la productividad, sino en la productividad. Esto libera a los desarrolladores para resolver tareas más complejas relacionadas con el proyecto en sí. Tratamos de hacer que Ruby sea lo más productivo posible y lo más productivo posible.

Python no tiene funciones anónimas multilínea debido a la complejidad del desarrollo. Es bueno escuchar que para Ruby, usted y los desarrolladores principales están tratando de facilitar la vida de los programadores, a pesar de la complejidad de la implementación. Por cierto, si empezamos a hablar de complejidad. Imagina que tienes la oportunidad de retroceder en el tiempo y darte un consejo joven cuando comenzaste a desarrollar Ruby. ¿Qué consejo sería este?

No tome prestado demasiado de otros lenguajes de secuencias de comandos. Su lenguaje de programación será el mejor lenguaje de uso general. Un gran enfoque en las secuencias de comandos se convertirá en una especie de rudimento en el futuro.

Durante la evolución del lenguaje Ruby, hiciste muchos cambios, experimentaste mucho. Algunos de ellos tuvieron éxito, otros no. ¿Cuál considera que es su mayor éxito en el desarrollo de un lenguaje, qué es lo que más le gusta?

Si necesita elegir una cosa, estos son bloques. Los bloques en Ruby son únicos; esta es una abstracción útil de una función de orden superior. Son mucho más simples que en otros idiomas. Esto ofrece limitaciones y facilidad de uso.

Coincidencia, pero los bloques son lo que más me gusta de Ruby. En mis propios discursos y entrevistas, hablo de Ruby como lenguaje con DSL, azúcar sintáctico y bloques. Los bloques son muy geniales.

En otros idiomas, como Swift, si se especifica otra función como último argumento de una función, esta función de argumento puede comportarse como un bloque en Ruby. Hay una sugerencia para dicho azúcar sintáctico incluso para JavaScript. Estoy muy orgulloso de ello.

Sí, JavaScript, con su sintaxis de flecha gruesa, a menudo usa el último argumento de una función como "algo así como bloques en Ruby". No puedo evitar hacer la pregunta opuesta. ¿Cuál puede llamar el mayor error en un proyecto que necesita ser reparado o ya arreglado?

Hay algunos Comencemos con las variables globales. Eran útiles para el lenguaje de secuencias de comandos, pero ahora se ven como un rudimento. También lamento agregar transmisiones explícitamente: necesitamos una abstracción más conveniente para la concurrencia. Otro de mis errores de diseño es la falta de inmunidad de algunos objetos. Por ejemplo, ahora puede cambiar la zona horaria de un objeto horario. En lugar de simplemente crear un nuevo objeto inmutable. Esto es de lo que me arrepiento.

La mutabilidad es compleja y puede conducir fácilmente a errores. Pero suficientes preguntas técnicas! Los humanos somos criaturas sociales, y sería interesante conocer tu vida, ¿cómo organizas el trabajo?

Soy un desarrollador de Ruby a tiempo completo. La mitad de mi tiempo trabajo en el diseño de la próxima versión del lenguaje. El resto del tiempo estoy trabajando en una implementación alternativa de MRuby. La implementación principal es creada por los desarrolladores principales, y solo tomo decisiones que reflejan en el código.

El número de confirmaciones en su GitHub es impresionante, especialmente las confirmaciones el día que vuela a Rusia. Recientemente, los desarrolladores han hablado mucho sobre el agotamiento. ¿Tienes tiempo libre, pasatiempos y algo que te protege del agotamiento?

Afortunadamente, paso todo mi tiempo trabajando con código abierto. No tengo presión de los clientes, no tengo jefes, me pongo las tareas. Todo esto me permite trabajar sin estrés. No tengo plazos más que la próxima fecha de lanzamiento de Ruby. Esta libertad me permite sentirme relajado. También trato de pasar tiempo sin estar en la computadora, prestar atención a mis familiares, familiares, ayudar a la iglesia local, caminar con el perro y jugar con mi gato.

A muchos desarrolladores de Ruby rusos les gusta Japón como país, su cultura. Miran anime, leen manga, vienen a Japón como turistas. Como japonés nativo y desarrollador de software, ¿qué lugares y actividades puede recomendar a otros desarrolladores que visitan Japón?

Japón es un país diverso. Puede visitar Tokio futurista, donde hay mucha cultura pop, como manga y anime. Al mismo tiempo, tenemos montañas, bosques y sitios históricos, como antiguos santuarios y templos. Apreciamos la belleza de la flor de sakura y el color de las hojas de otoño. Por lo tanto, todo depende de tus gustos y preferencias, puedes disfrutar de muchas cosas: comida, naturaleza, tecnología. Puedes visitar muchos lugares, especialmente en Tokio. Recomiendo que los colegas presten atención a la diversidad de nuestro país y confíen exactamente en esto en sus viajes turísticos.

¿Hay algo en la cultura y el idioma japonés que influyó en la creación de Ruby?

No tenemos control sobre tal influencia cultural y es difícil de evaluar. Por ejemplo, en japonés, las oraciones están pegadas. Del mismo modo que el "método de encadenamiento" funciona en Ruby. Tal vez esta es la influencia del idioma japonés. Japón es un país rico y no necesitamos un trabajo duro constante. El código abierto no genera dinero, pero al trabajar en mi trabajo principal o depender del dinero de los patrocinadores, yo y los colaboradores podemos apoyar y desarrollar el lenguaje y mejorar la tecnología. Esta es también la influencia de Japón y las oportunidades que brinda.

Y la última pregunta insidiosa. Las personas a menudo se imaginan a sí mismas en el lugar de los demás, piensan qué harían, cómo actuarían. ¿Hay algo en la posición del autor de un lenguaje de programación popular que no sea obvio desde el exterior?

Crear un lenguaje de programación no es una tarea técnica muy difícil. Muchos estudiantes que asisten a cursos de desarrollo de lenguajes de programación en la universidad pueden hacer su propio idioma y no hay nada prohibitivamente complicado. La dificultad es que el lenguaje es una forma de expresar pensamientos. Esto se aplica tanto a los lenguajes de programación como a los lenguajes naturales: ruso, inglés, japonés. Lenguajes de programación como Ruby, Python o JavaScript: ayudan a nuestra mente a formular pensamientos. Esta es la tarea principal de los lenguajes de programación. Un buen lenguaje de programación ofrece un enfoque para formular pensamientos. Para Ruby, este enfoque es "productividad de desarrollo y el placer de escribir código". Para otros idiomas, podría ser "simplicidad", "eficiencia" u otra cosa. Cada idioma tiene su propio enfoque. Y si te gustalo que Ruby ofrece para formular pensamientos es tu idioma.

Transcripción de mi entrevista con el autor Ruby

More articles: