Hello, World

Hello world.

Hola, mundo. ¿Es señal o ruido? Todo el trabajo de los desarrolladores, las innumerables horas de codificación, estrés y pruebas, todo se reduce a esa pregunta: ¿se entiende nuestra señal?

Hola.

¿O se pierde? ¿Es puro ruido?

Esta es la segunda temporada de Command Line Heroes en español, un podcast original de Red Hat. En el episodio de hoy, vamos a hablar de la traducción. Veremos los lenguajes de programación: de dónde provienen y cómo elegimos cuáles aprender. Haremos un análisis profundo de las formas en que hablamos con nuestras máquinas. Cómo evolucionan esos lenguajes. Y cómo podemos usarlos para que nuestro trabajo cante.

Quizás, quizás, quizás. [Voz robótica]

Si eres desarrollador, tal vez sientas que tienes que ser políglota y dominar muchos lenguajes. Más te vale conocer Java. Y Python. Y Go, JavaScript, Node... Tienes que soñar en C++. Y quizás conocer los clásicos como COBOL, simplemente para aumentar tu credibilidad. Tal vez hasta te preocupen los nuevos, como Dart... Es agotador.

Lo extraño es que las computadoras con las que nos comunicamos solo hablan un lenguaje: el lenguaje de las máquinas. Todos esos ceros y unos que andan volando por ahí, todos esos bits... A fin de cuentas, cada lenguaje que aprendemos es otro camino hacia el mismo lugar. Todo se reduce, sin importar qué tanto nos concentremos cuando estamos trabajando.

Y eso es lo que hay que tener en cuenta a medida que comienza nuestra historia, porque vamos a empezar con el maravilloso momento en que una mujer dijo: “¿Sabes qué? Yo soy una persona. No hablo en bits, ni pienso en bits. Para programar quiero usar palabras”.

Ahora nos parece fácil, pero alguna vez la idea de que pudieras hablar con las computadoras a tu manera parecía una broma, y hasta un sacrilegio.

La segunda temporada de Command Line Heroes en español aborda las cuestiones fundamentales que sustentan todo lo que hacemos. Y el héroe de este episodio es una mujer cuya trayectoria necesitas conocer si quieres comprender completamente nuestra realidad. Entonces te presento a la primera dama del software.

Señoras y señores, es un gran placer presentar a la Comodoro Grace Mary Hopper. Gracias.

Fui a Canadá para hablar en la Universidad de Guelph y tuve que pasar por migración en el Aeropuerto de Toronto. Le di mi pasaporte al oficial, que lo vio y me dijo: “¿De qué cuerpo militar es usted?”

Y le dije: “De la Marina de los Estados Unidos”.

Me miró detenidamente. Y luego dijo: “Ha de ser de lo más antiguo que tienen”.

Acabamos de escuchar a la contralmirante Grace Hopper en 1985. En ese momento tenía 79 años de edad y dictaba su famosa conferencia en el M.I.T. Desde entonces era una leyenda. Es la madrina de los lenguajes de programación independientes. La que usó compiladores para que pudiéramos usar el lenguaje humano en lugar de símbolos matemáticos.

Recibió la Medalla Nacional de Tecnología y, después de morir, la Medalla Nacional de la Libertad. Así que no era ninguna floja. La llamaban “Amazing Grace”.

Si alguien nació para ser programadora informática, era Grace.

Escuchamos a Claire Evans, periodista tecnológica y autora de un libro llamado Broad Band, sobre las innovaciones de las mujeres en la tecnología. Evans describe los primeros momentos de las computadoras, con los que Grace Hopper se encontró en la década de 1940, cuando era una joven de las Reservas de la Marina y las computadoras eran del tamaño de una pequeña habitación.

La vida de los primeros programadores era como un sacerdocio. Eran muy buenos para cosas muy aburridas; digo, hay que recordar que esto es antes de los compiladores, antes de los lenguajes de programación, cuando la gente realmente programaba al nivel de las máquinas, bit a bit.

No cualquiera puede hacer ese tipo de cosas, se necesita mucha disciplina, y Grace la tenía.

De inmediato se dio cuenta de que para las personas es muy limitante el tener que usar un lenguaje destinado a las máquinas. Es como si cada vez que tuvieras que caminar, tuvieras que decirle qué hacer a cada célula de tu cuerpo. Se puede, claro. Pero no es eficiente.

Tenía que haber un atajo entre las intenciones del programador y las acciones de la computadora. Las personas habían intentado mecanizar el pensamiento matemático desde que apareció el ábaco. Tenía que haber una manera de lograrlo con las computadoras.

Antes, los matemáticos tenían que hacer muchas operaciones aritméticas. Es decir, tenían que hacer mucho trabajo tedioso paso a paso para llegar a las soluciones realmente interesantes. Y luego llegaron las computadoras y ofrecieron la posibilidad de hacer esas operaciones a máquina, así que el matemático quedaba libre para dedicarse a los pensamientos elevados, intelectuales y orientados a los sistemas.

Pero, en realidad, eso no fue lo que pasó. Cuando llegaron las computadoras, el matemático tuvo que convertirse en programador. Y luego se volvieron a atorar con todos esos tediosos pequeños cálculos orientados a las reglas, bit a bit para escribir los programas.

Creo que lo que Grace quería era asegurarse de que las computadoras ayudaran a los matemáticos a concebir grandes ideas y hacer grandes cosas, sin que tuvieran que atorarse con los detalles.

Hopper se unía a una larga línea de pensadores. Estaba Pascal en el siglo XVII con la primera calculadora. Luego Babbage en el siglo XIX con el motor analítico. Hay una línea hermosa y prolífica de inventores que querían diseñar cosas para potenciar el cerebro humano. Cosas que nos permitieran procesar más datos de los que podíamos manejar por nuestra cuenta. Ese es el linaje al que entraba Grace Hopper cuando inventó algo que a todo el mundo le parecía imposible.

Me refiero a la idea de que las personas pudieran comunicarse con sus computadoras usando lenguaje natural, y de que ese lenguaje fuera independiente de las máquinas y, por lo tanto, interoperable entre diferentes máquinas informáticas. Fue una idea revolucionaria para su tiempo.

A las personas que respaldaron la noción a la que ella llamó “programación automática” en los primeros días se las consideró los cadetes espaciales en la comunidad de programadores y gente de la computación.

Y las que no la apoyaron finalmente se dieron a conocer como los neandertales; esa era la enorme brecha que existía en la comunidad informática.

No fue fácil para Hopper convencer a sus superiores de que cruzaran esa brecha. Pero sintió que era su deber intentarlo.

Siempre hay límites. En este caso, representan lo que tu jefe cree en ese momento. Ahora, claro, si te los saltas, no recibes el presupuesto. Entonces, tu responsabilidad frente a esos límites es doble: no te los puedes saltar, pero tienes que educar a tu jefe para poder extenderlos, para que la próxima vez tengas más margen de maniobra hacia el futuro.

El futuro hacia el que ella maniobró es nuestro presente. Prácticamente todos los lenguajes de los que dependemos tienen una deuda con Hopper y su primer compilador. Así que el marcador le da un punto a los cadetes espaciales y ninguno a los neandertales.

Y ese punto lo obtuvieron gracias a la idea de que codificáramos con lenguaje humano y no con números.

Grace tenía muy claro que la computación iba a cambiar al mundo, pero primero había que entender cómo acceder a ella, cómo utilizarla. Quería que fuera lo más abierta y accesible posible para la mayor cantidad de personas.

Y eso implicaba ciertas concesiones en la comprensión y la legibilidad. Entonces, finalmente, el deseo de crear lenguajes de programación venía de la idea de dar más puntos de entrada a la máquina, para que ya no estuviera reservada a los "sacerdotes" que le dedicaban su vida, sino que se abriera a un público mayor y a una nueva generación.

Vamos a hacer una pausa para destacar algo de lo que dijo Claire: los lenguajes de programación como los conocemos hoy en día provienen del deseo de abrir la tecnología. Es decir, quitarles a los doctores en Matemáticas la exclusividad que tenían para manejarla, para poder permitir que su desarrollo fuera accesible para todos.

El espíritu del compilador que hace todo ese trabajo está motivado por un sentido de empatía y comprensión.

Claire cree saber por qué Hopper fue la mujer que daría ese cambio. Y tiene que ver con su trabajo durante la Segunda Guerra Mundial.

Resolvía problemas de barrido de minas, problemas balísticos, problemas de oceanografía. Aplicaba todas las disciplinas diferentes y diversas que representan las realidades violentas, caóticas y desordenadas de la guerra, y las traducía en programas que ejecutaba en la computadora Mark I.

Sabía cómo hacer la traducción entre distintos lenguajes. Y no me refiero a lenguajes informáticos, me refiero a idiomas humanos. Sabía escuchar a alguien que tenía un problema complejo, trataba de entenderlo, buscaba las limitaciones y las potencialidades de su disciplina y luego lo traducía todo para convertirlo en algo que la computadora pudiera entender.

De alguna manera, fue la primera compiladora. O la compiladora humana personificada, porque sabía que había que estar en el nivel de la gente.

Compilar como acto de empatía y comprensión. Todos debemos tenerlo en cuenta cuando aprendemos nuevos lenguajes o nos preguntamos por qué algo no se compila. El trabajo del compilador debe ser encontrar tu lenguaje en su propio medio.

Grace Hopper sabía que una vez que las personas pudieran aprender a hablar lenguajes de programación, y que los compiladores comenzaran a traducir nuestras intenciones al lenguaje mecanizado, se abrirían las compuertas.

Sabía que la informática nunca podría desarrollarse como industria, como una fuerza de cambio mundial, si estaba demasiado aislada y era demasiado específica. Y si la gente que la practicaba no podía comunicarse con las personas cuyos problemas debían ingresarse en la máquina, por así decirlo.

Entonces, ella tenía mucha experiencia en ese tipo de traducción humana, y creo que eso la hizo estar especialmente calificada para diseñar y crear lenguajes de programación.

El trabajo de Hopper en el lenguaje de procesamiento de datos con base en el inglés finalmente evolucionó hasta convertirse en COBOL, que es perfecto porque no es pretencioso y va al grano, al igual que Grace Hopper.

En cierto modo, nos dio un lenguaje que se parecía mucho a ella. Y al igual que Hopper, COBOL es longevo. Sesenta años después, sigue vivo.

Bueno, los compiladores de Grace Hopper eran como BabelFish: negociaban el significado entre los programadores y sus máquinas. Y traducían cosas de niveles cada vez más abstractos.

Luego, unas décadas más tarde, conseguimos añadir otro ingrediente fundamental a la mezcla de lenguajes. Imagínate, la comunidad de software gratuito despegó en los 80, pero cuando se creó la alternativa de Unix, GNU, no había compiladores gratuitos y abiertos que la acompañaran.

Para que GNU nos brindara una verdadera alternativa a Unix pero de código abierto, y para que los lenguajes de programación prosperaran en el mundo del código abierto, la comunidad necesitaba hacer una movida estilo Grace Hopper: necesitábamos un compilador de código abierto.

Aquí está Langdon White, arquitecto de plataformas en Red Hat, que nos habla del estado de las cosas en ese entonces.

En la década de los 80, te podías gastar fácil diez mil dólares en un compilador. La parte gratuita era muy importante. Yo no tenía diez mil dólares extra para ir a comprarme un compilador. Además, en ese caso tenía que comprarme un compilador para cada plataforma en que quisiera trabajar. Entonces, en esos días era sobre todo Unix, pero con distintos elementos.

Así que no podías comprar solo uno, tenías que comprar varios para diferentes arquitecturas o diferentes proveedores.

Langdon señala que no solo los costos estaban en juego. En algunos casos, se arriesgaba incluso el trabajo de codificación.

La gente no se da cuenta de que la manera en que se estructura el código es muy importante en cosas muy específicas. Así que para que los bucles anidados for o los bucles anidados while y demás quedaran bien, dependías del compilador.

Entonces, si no sabes cómo se optimiza tu código, es muy, muy difícil saber cómo escribirlo para lograr la mayor optimización.

Simplemente necesitábamos una opción gratuita, una opción accesible, una opción confiable. Lo que necesitábamos era el compilador de GNU para C, el GCC. Ese fue el monstruo, que se lanzó por primera vez en 1987, y que fusionó la revolución compiladora de Grace Hopper y el movimiento de software libre.

Normalizó las cosas y permitió que todo el mundo pudiera compilar lo que los demás habían escrito. La abundancia de nuestros lenguajes se debe a ese momento.

El hecho de que el GCC fuera abierto llevó a los lenguajes a otro nivel.

Carol Willing trabaja en el Proyecto Jupiter y es la exdirectora de la Python Software Foundation.

La gente comenzó a darse cuenta de que los lenguajes propietarios servían para cierto propósito en ese momento, pero no iban a ganar la aceptación ni la adoración de la comunidad de desarrolladores. Porque si eres desarrollador, lo que quieres es saber usar el lenguaje más frecuente y también, el que es nuevo y está a la vanguardia.

No necesariamente quieres desarrollar una habilidad que te va a atar a una tecnología única. Creo que una de las razones por las que Python tuvo tanto éxito es que era de código abierto y tenía una sintaxis muy limpia.

Lo que hacía era permitir que la gente resolviera problemas de manera rápida y eficiente, y con un método común. Y también que la gente colaborara. Y creo que esas son las características de los buenos programas y las buenas bibliotecas: el poder trabajar sin muchos dolores de cabeza y luego poder compartir tu trabajo con otros... yo creo que eso es valiosísimo.

Con el paso de los años, el GCC evolucionó para admitir Java, C++, Ada, Fortran... y la lista sigue.

Si hay una interfaz subyacente común como el GCC, la gente puede tomar un lenguaje y luego personalizarlo según sus necesidades particulares. Por ejemplo, en el mundo de Python, hay muchas bibliotecas diferentes, e incluso en el caso particular del mundo científico de Python, están NumPy, scikit-image y scikit-learn.

Y cada uno de ellos era conocido por una tarea más específica. Y luego hemos visto cosas como la bioinformática y el procesamiento del lenguaje natural. Entonces la gente puede trabajar con una base común y hacer muchas cosas distintas con ella. Y además puede agregar elementos a sus lenguajes o bibliotecas, para optimizar la resolución de problemas en su sector o área en particular.

Entonces, eso es lo que pasa cuando la tecnología de compilación encabeza el movimiento del código abierto, ¿verdad? Con el tiempo se crea un big bang de nuevos lenguajes que apoya la comunidad y que cualquiera puede aprender y utilizar para sus desarrollos.

Actualmente se utilizan cientos de esos lenguajes.

A medida que el código abierto se volvió más popular y más aceptado, lo que vimos fue una proliferación de lenguajes. Varios de ellos giran en torno a... a la tecnología de los teléfonos celulares y... los dispositivos móviles. Y el hecho de tener lenguajes distintos permite que el desarrollo de juegos sea más sencillo. Por ejemplo, los lenguajes multipropósito como Python y Ruby fueron una especie de cimiento para el desarrollo web y la distribución de aplicaciones y sitios web.

La lista sigue. Y sí, esa Torre de Babel que estamos construyendo va a tener cada vez más lenguajes. Pero también podemos verlo como una cornucopia, un festín de lenguajes. Y a continuación te vamos a ayudar a organizar ese festín.

Bueno, entonces ya sabemos de dónde viene la abundancia de lenguajes. Pero, ¿cómo hacemos para poder entender todo esto? ¿Cómo elegimos los lenguajes que nos importan? Es una pregunta importante, así que trajimos apoyo: Clive Thompson es uno de los escritores que mejor entiende el mundo de la tecnología. Es columnista de Wired, colabora en la revista New York Times Magazine, y escribió un libro sobre la psicología de los programadores informáticos.

Lo cual es perfecto, porque necesitamos saber qué sucede en nuestro cerebro cuando elegimos qué lenguajes aprender. ¿Por qué hay tantos lenguajes de programación?

Cada lenguaje tiene una... vamos a decir, una tendencia hacia las cosas en las que es bueno. Así que, en general, cuando alguien crea un nuevo lenguaje es porque... ninguno de los que ya existen es bueno para lo que él quiere. JavaScript es un buen ejemplo.

A mediados de la década de los 90, Netscape había creado un navegador, y los administradores de los sitios web querían hacer algo un poco más interactivo. Querían que hubiera una manera de programar en su sitio web.

Entonces enviaban sus solicitudes a Netscape. Solicitudes que decían: “Okay, no hay ningún programa que pueda hacer esto, pero necesitamos un lenguaje de programación que esté integrado a nuestro navegador”.

Así que contrataron a Brendan Eich. Todo el mundo lo consideraba especialista. Tenía como 32, y todos los demás tenían como 21.

Eso ya es ser experimentado en el mundo de los desarrolladores.

Y le dieron 10 días para hacer JavaScript. Entonces, hizo maniobras desesperadas para sacar un lenguaje de programación. Y le salió algo torpe y un poco desordenado. Pero funcionó. Y permitió que la gente hiciera cosas muy sencillas: tenía botones y diálogos, ventanas emergentes y cosas así.

Ese es un ejemplo de un lenguaje que surgió... que se diseñó para hacer algo que en ese momento todavía no era posible.

¡Increíble!

Por eso existen tantos lenguajes, porque la gente siempre encuentra algún motivo... un motivo para hacer algo que nadie más puede hacer.

Pero entonces, lo interesante sobre la relación entre los desarrolladores y nuestros lenguajes de programación es que tenemos un apego muy fuerte a esas herramientas. ¿Por qué será?

Hay varias razones. Por un lado, a veces el primer lenguaje que aprendemos es simple y sencillamente un accidente. Y se vuelve como tu primer amor.

Por otro lado, yo creo que también tiene que ver con el tipo de lenguaje que mejor le funcione a cada quien según su personalidad. Por ejemplo, ve Facebook. Facebook se diseñó con PHP, que es un lenguaje de programación algo enmarañado. Es muy irregular. Y de alguna manera creció con... avances y retrocesos. Y eso se siente en Facebook.

En cambio, por ejemplo, la gente de Google pensó: “Queremos un lenguaje de alto rendimiento, porque en Google es muy importante que todo funcione muy rápido, y que pueda dar servicio a miles y millones de usuarios a la vez”.

Entonces, deciden hacer Go, y Go es un lenguaje realmente excelente para ese tipo de informática de alto rendimiento.

Pero vamos a profundizar. ¿Será que los desarrolladores se sienten naturalmente atraídos a ciertos lenguajes? ¿O que el lenguaje en el que trabajan influye en su personalidad?

Eh... los dos, definitivamente. Pero... yo creo que la gente... que la gente siente algo muy fuerte cuando... cuando encuentra un lenguaje que le gusta. Porque sigues un plan de estudios de informática y, bueno, aprendes lo que tienes que aprender: todos enseñan Java. A veces más JavaScript o Python.

Pero la cosa es que estás obligado a aprenderlo, y lo aprendes. Pero, ¿qué hace la gente cuando puede decidir qué aprender? Y aquí es donde realmente se ve que el estilo emocional o psicológico de las personas se inclina hacia un lenguaje, porque conversé con un señor que intentó aprender un poco de JavaScript.

Y entonces, pues... es un lenguaje medio feo a la vista. Tiene un montón de llaves y corchetes. Y, bueno, intentó aprender a usarlo varias veces y no pudo. Y un día vio que un amigo suyo estaba trabajando en Python. Y el programa le llamó la atención, porque sintió que se veía limpio, bonito. Era escritor, y seguido se dice que Python es un lenguaje ideal para escritores, porque las sangrías permiten que todo sea fácil de leer.

Así que el programa simplemente le gustó, porque... porque había algo en su funcionamiento, en su aspecto, eh...en su poca densidad, que... lo atrapó.

Hay lenguajes que tenemos que aprender a usar. Me refiero a los lenguajes antiguos que están presentes en todo lo que usamos para trabajar: el latín del código.

Pero también hay lenguajes que nosotros mismos elegimos, lenguajes que se adaptan a nuestra personalidad. Y si quieres saber qué novedades están revolucionando las cosas, pregúntale a algún desarrollador cuál usa los fines de semana.

Esta es otra parte de nuestra conversación:

Entonces, pues... cuando le pregunto a la gente: “¿Qué haces en tu tiempo libre?” Responden con un montón de cosas extrañas. Y, pues, yo creo que en realidad es una de las cosas que... que son buenas y dignas de elogio del comportamiento de los desarrolladores, por... porque... tienden a ser personas muy curiosas.

Conozco gente que pensó: "Voy a aprender Erlang, nada más por el puro gusto”.

Imagínate todos los proyectos en los que esas personas trabajan el fin de semana. Es casi como si el proyecto fuera secundario. Es como si el aprendizaje de la herramienta, el lenguaje, fuera lo más importante. Por eso lo hacen, en realidad.

Eh... sí, exactamente. Por eso vemos a la gente repetir, una y otra vez, las calendarizaciones y las listas de tareas, porque es una forma muy rápida de descubrir qué hace el lenguaje y cómo funciona, y es casi como si no importara lo que se está desarrollando, siempre y cuando haya algo que desarrollar.

Quieren saber lo que se siente pensar en ese lenguaje. ¿Va a ser fácil... va... a ser emocionante y armonioso, va a ser diferente de lo que me dan los lenguajes actuales? ¿Me va a abrir las puertas para que todo sea más sencillo?

Entonces, cuando encontramos un nuevo lenguaje se forman nuevas posibilidades que pueden ser muy emocionantes. Emocionante por lo que nos permite imaginamos.

Hace unos años, un desarrollador muy conocido de Ruby dio una charla muy buena en la que defendía la idea de que un lenguaje no... no necesitaba ser bonito para poder utilizarlo.

Y su tesis, su argumento era que Ruby era muy emocionante porque era nuevo. Y hace unos años llegó a un punto en el que simplemente ya no necesitaba nada más. Estaba terminado. Era un lenguaje estable y maduro y, como resultado de esa madurez, pues ya no era tan emocionante como antes para los desarrolladores. Ya no es el juguete nuevo, así que poco a poco nos alejamos de él y empezamos a buscar el siguiente juguete nuevo.

Entonces, en cierto aspecto, nuestra propia curiosidad casi puede matar un lenguaje, o hacer que caduque un poco, independientemente de que... sea bueno o malo.

Sí, tienes toda la razón. De hecho, eh...la desventaja de esa profunda curiosidad, del deseo de aprender por sí solos que vemos en los desarrolladores, es que... seguido se ponen a buscar el juguete nuevo. Y cuando lo... cuando lo encuentran, lo usan para replicar cosas que ya se han hecho muy bien con otros lenguajes.

Claro.

Así es. La curiosidad es un beneficio y una trampa.

Sí, no hay mejor manera de decirlo.

A veces, nuestra curiosidad puede ser una trampa. Pero también es lo que impulsa la evolución de los lenguajes. Todos los lenguajes nuevos se crearon porque alguien dijo: “¿Y qué pasaría si...?” Nacen porque ese desarrollador quería hacer algo diferente.

Quería una forma completamente nueva de decirlo.

Y les voy a prometer algo.

Yo creo que Grace Hopper merece una última palabra.

Durante los próximos 12 meses, si cualquiera de ustedes dice que hay algo que “siempre se ha hecho así”, me materializaré instantáneamente a su lado y los atormentaré durante 24 horas. A ver si puedo hacer que le den otra vuelta. Ya no podemos decir eso, es peligroso.

La historia de Grace Hopper y el primer compilador nos recuerda que siempre hay una mejor manera de hacer las cosas, solo necesitamos encontrar las palabras correctas.

E independientemente de lo abstractos que se vuelvan esos lenguajes, ya sea que estemos muy cerca o muy lejos de los unos y ceros del lenguaje informático, debemos estar seguros de que nuestra elección sea inteligente. Elegimos el lenguaje o incluso desarrollamos el lenguaje que nos ayuda a que nuestras intenciones se acerquen a la realidad.

En el próximo episodio, seguiremos el complicado camino para realizar contribuciones de código abierto. ¿Cuáles son las dificultades de la vida real de los mantenedores? ¿Cómo hacemos el primer "pull request"?

Te llevaremos por un recorrido de los aspectos básicos de las contribuciones.

Command Line Heroes en español es un podcast original de Red Hat. Escúchalo gratis en Spotify, Apple Podcasts, Google Podcasts o donde más te guste.

Hasta la próxima, sigan programando.