Lenguajes que llegaron para quedarse

Cuando el metro de la ciudad de Nueva York comenzó a funcionar en 1904, era una maravilla de la era moderna. Pero... ¿qué sucede si los usuarios de hoy dependen de una infraestructura que fue diseñada hace más de un siglo? Los trenes van repletos y a menudo se retrasan. Cada año el metro de Nueva York realiza dos mil millones de recorridos, y ya a nadie le sorprende. Estamos atados a una infraestructura antigua que se está desmoronando y tenemos que buscar formas nuevas e inteligentes de lograr que funcione.

Antes, los proyectos de infraestructura eran unas cosas gigantes de concreto que podíamos ver; por ejemplo, el metro. Y gracias a su presencia física, era muy evidente cuando se averiaban. Las carreteras se agrietan, los postes telefónicos se caen. Sabemos cuando necesitamos arreglarlas. Para poder sincronizar nuestras vidas actuales con la infraestructura antigua, se necesitan grandes esfuerzos.

Pero las cosas no siempre son tan obvias. Hoy en día también tenemos infraestructuras de TI, granjas de servidores en campos aislados, cables de fibra óptica que recorren océanos e infraestructuras de software, como los sistemas operativos heredados o los scripts de shell, que nadie se atreve a reemplazar. Nosotros no podemos ver con nuestros propios ojos los estragos del tiempo en una infraestructura de TI vieja y destartalada. Pero aunque no podamos verlo, la infraestructura que hace posible el trabajo de desarrollo actual está envejeciendo, como las antiguas vías del metro. Y eso puede afectar nuestra vida moderna. Conforme los héroes de la línea de comandos trabajan para garantizar que no quedemos atrapados en el pasado, surgen nuevos y enormes desafíos.

Este es el quinto episodio de nuestro recorrido de la temporada por el mundo de los lenguajes de programación. Veremos dos lenguajes que están estrechamente ligados a la infraestructura para la que fueron diseñados. COBOL es un lenguaje de la informática de las mainframes y Go es de la nube. Ambos están profundamente marcados por sus orígenes. El entender eso podría evitar que los desarrolladores del mañana terminaran como pasajeros atascados en una concurrida estación de tren.

Esta es la tercera temporada de Command Line Heroes en español, un podcast original de Red Hat.

Hay muchas cosas que hacer, pero necesitamos una gran cantidad de información, correlacionada y de fácil acceso. Este es solo el principio.

La almirante Grace Hopper fue la precursora de los lenguajes de programación de alto nivel en las décadas de 1940 y 1950. Y pudo dar ese gran salto gracias a la infraestructura de su tiempo, las computadoras mainframe.

Hola, me llamo Chris Short.

Chris es gerente principal de marketing de productos en Red Hat, y además le encanta la historia.

La almirante Hopper en los años 40 creó FLOW-MATIC, y en general se le considera la abuela de COBOL, que fue revolucionario en ese momento. Se podía simplemente decir “Pues vamos a ponerlo en la mainframe” o “Oye, vamos a guardarlo en la mainframe”.

Fue un cambio importante. De repente, tienes este lenguaje independiente de la máquina, COBOL, que se originó en el entorno de mainframe. Comenzaron a abrirse las posibilidades.

COBOL les dio a todas las empresas la capacidad de decidir que, en lugar de ocupar una sala llena de personas con lápices, papeles, calculadoras y reglas de cálculo, podían ocupar solo media sala con una mainframe. Y luego unas cuantas personas podían escribir algunas aplicaciones en COBOL, para que hicieran todas las cuestiones de matemáticas, lógica y contabilidad que antes estaban a cargo de un equipo entero de finanzas. Entonces, el equipo de personas que necesitabas para las finanzas se redujo mucho, simplemente porque gran parte de las entradas podía ser digital en lugar de manual.

Si hubieras sido uno de los nuevos programadores de COBOL, habrías sentido que tenías trabajo de por vida. Porque las mainframes, que eran la infraestructura en la que se basaba tu trabajo, no se iban a ir a ningún lado.

La ley de Moore todavía no existía en ese entonces, así que existía la posibilidad de que trabajaras toda una década en la misma mainframe, ¿me explico? No te preocupaba el siguiente sistema operativo, el siguiente tipo de orquestador de contenedores o la siguiente innovación, la inteligencia artificial ni nada. Podías pasar toda tu vida laboral trabajando en COBOL. Y sabías que no corrías riesgos de perder el trabajo.

Pero luego llegó la ley de Moore. También aparecieron nuevas infraestructuras. Y en estos días, es menos probable que los programadores aprendan un lenguaje de hace medio siglo. Pero la cosa es que esas viejas computadoras mainframe no han desaparecido. Y eso significa que nuestra necesidad de desarrolladores COBOL tampoco.

Cada vez es más difícil encontrar desarrolladores COBOL. Lo que acaba sucediendo es que las mainframes han estado aquí unos 50 años. Y los desarrolladores COBOL que aún pueden escribir bien en COBOL cobran una cantidad exorbitante de dinero para ayudar con los proyectos y la reorganización de los datos dentro de las mainframes. Ese conjunto de habilidades definitivamente está desapareciendo y se está convirtiendo en un campo profesional altamente lucrativo si... definitivamente puedes ganar mucho dinero si escribes COBOL actualmente.

Sobre todo en las industrias de fabricación y finanzas. No se puede dejar de usar toda esa infraestructura que se dispuso hace décadas. Todo el trabajo del mundo está lleno de código heredado. Sería un gran error ignorar esa antigua infraestructura y los lenguajes ligados a ella.

Sería muy difícil refactorizar las 200 mil millones de líneas de código que andan por ahí dando vueltas. No, yo no creo que vaya a desaparecer de nuestras vidas, estoy seguro.

Chris Short es gerente principal de marketing de productos en Red Hat.

Quiero dar un ejemplo real del argumento de Chris. No sé si sabes que COBOL está integrado en el 95 % de todas las transacciones de los cajeros automáticos. Así de ligados estamos a este lenguaje. Y aunque se use tanto, el programador COBOL promedio no es precisamente más joven que el lenguaje en sí. Tiene entre 45 y 55 años. Porque a los principiantes no les interesa. Por eso quiero presentarles a alguien.

Hola, me llamo Ritika Trikha.

Ritika es escritora de tecnología y solía trabajar para HackerRank. Y le interesa muchísimo COBOL y el que la gente suponga que es una especie de vestigio inútil de la época de las mainframes.

Los desarrolladores de hoy en día no están pensando en COBOL: ojos que no ven, corazón que no siente.

Pero esa podría ser la receta del desastre.

Actualmente todavía hay muchas empresas que dependen de un gran volumen de líneas de código COBOL. Se generan al menos 1500 millones de nuevas líneas de código en COBOL al año. Y yo creo que cuando observas las industrias específicas, es muy interesante. Hay como 50 millones de líneas de código en el Servicio de Impuestos Internos de los Estados Unidos. Y en el mismo país hay 60 millones de líneas de código en la Administración del Seguro Social. Y sucede que dichos organismos manejan parte de la información más importante y confidencial de nuestros días, así que al dejar de alimentar y mantener estas mainframes, podríamos generar un desastre.

Así que, si no podemos escapar de nuestra vieja infraestructura ni tampoco podemos usar una varita mágica para reconstruir todo el universo de las mainframes, ¿qué hacemos? ¿Cómo hacen los programadores, que a veces solo piensan en el futuro, para empezar a aceptar el pasado? Tenemos que comenzar por abordar el problema sin rodeos.

Sí, pues las generaciones más jóvenes van a tener que aprender a usarlo. O si no, se necesita algún tipo de modernización de las mainframes. En cualquiera de los casos, el problema no se va a ir. Por eso es importante COBOL.

No está fácil. Según Ritika, hemos ignorado el problema mucho tiempo.

Reemplazar miles de millones de líneas de COBOL sería muy caro, difícil, y el riesgo sería altísimo. Es un código fundamental, como podemos ver con el caso del Seguro Social y la información financiera. Y COBOL se diseñó específicamente para los grandes volúmenes de transacciones. Grace Hopper lo diseñó para las transacciones comerciales en la década de los sesenta. Y desde ese entonces, la mentalidad ha sido de “Si no está descompuesto, no lo arregles”, así que ya llegamos a un punto en que tenemos décadas de altos volúmenes de datos valiosos que se ejecutan en COBOL.

De cierto modo, Ritika está pidiendo un cambio cultural. Un cambio de actitud sobre lo que se pone de moda y lo que pasa de moda. A medida que el mundo del desarrollo comienza a forjarse un pasado cada vez más largo, tenemos que estar más en contacto con nuestra propia historia. No nos podemos escapar de la infraestructura cuando envejece. Y eso quiere decir que tampoco podemos olvidarnos de la historia de los lenguajes.

Se necesita hacer algo. Cuando estaba en HackerRank, vi de primera mano cuántos bancos e instituciones financieras necesitan desesperadamente desarrolladores COBOL. El problema no va a desaparecer, así que yo creo que o hacemos algún tipo de modernización de los sistemas, o tenemos que seguir capacitando gente e incentivándola. Yo personalmente creo que COBOL va a volver a ponerse de moda. Porque, en serio, ¿qué va a pasar cuando todos los desarrolladores COBOL se jubilen y las generaciones nuevas no sepan usarlo? Algo tiene que pasar, ¿no? Se necesita un cambio más sistemático e institucionalizado para poder alejarnos de COBOL y pasar a las nuevas infraestructuras basadas en la nube.

Ritika Trikha se dedica a escribir artículos de tecnología y vive en San Francisco.

¿Pero entonces qué pasa con las infraestructuras basadas en la nube que mencionó Ritika y que se están desarrollando actualmente? ¿Van a atar a las generaciones futuras a ciertos lenguajes particulares, así como todavía estamos atados a COBOL? Amazon Web Services (AWS) se lanzó en 2006 y tal vez sea la infraestructura de nube más grande que existe. Google Cloud Platform llegó en 2008 y Microsoft Azure se inició en 2010. El lenguaje Go se diseñó con un sistema de concurrencia para que pudiera funcionar perfectamente dentro de toda esa nueva infraestructura de nube. Es un lenguaje de su época.

Hola, me llamo Carmen Andoh, soy gerente de programas para el equipo de Go en Google.

Carmen sabe de primera mano que Go está vinculado a la infraestructura actual. Todo empezó con los creadores de Go, que tienen lazos fuertes con la historia de los lenguajes.

Robert Pike, Robert Griesemer y Ken Thompson. Nombres famosos desde la década de los 60. En unas vacaciones de verano, Ken Thompson inventó el lenguaje de programación B y luego inventó el sistema operativo UNIX. Rob Pike inventó UTF-8, que es un formato de codificación. También inventó ASCII. Ayudó a crear el entorno de programación UNIX. Entonces habían sido compañeros de trabajo durante mucho tiempo, y habían observado e inventado sistemas operativos en lenguajes de programación anteriores, incluido C, el cual Ken Thompson luego ayudaría a escribir junto a Dennis Ritchie.

Cuando Pike, Griesemer y Thompson ya estaban trabajando en Google, descubrieron un problema grave. No se estaba logrando la concurrencia a gran escala. Las personas esperaban horas a que se compilara una factura. Estaban trabajando en C++ y tenían que escribir muchísimos callbacks y event dispatchers. Era el año 2009 y nuestra infraestructura estaba cambiando otra vez. Los lenguajes como C++ se ajustaban cada vez menos a esta nueva realidad.

Los problemas los generaban los procesadores multinúcleo, los sistemas de red, los enormes clústeres informáticos y el modelo de programación web, entre otras cosas. Y otro factor era el crecimiento de la industria y la cantidad de programadores que ya llegaban a las cifras de cuatro ceros para el 2010. Entonces hasta ese momento se estaba intentando adaptar los lenguajes de programación, en lugar de abordar la situación sin rodeos.

Finalmente, llegas a un punto de quiebre y se necesita que algo cambie.

Nos chocaba C++, así que dije: “Bueno, vamos a ver si podemos inventar algo nuevo”.

Ese nuevo lenguaje necesitaría adaptarse perfectamente a nuestra última infraestructura.

Lo que pasó con la nube, que empezó a madurar en 2005, es que ya no tenías que procesar tus propios datos, sino que alquilabas el servicio en otro lado y adquirías un sistema distribuido. Pero lo que sucede en un sistema distribuido, y en una nube, es que hay problemas de mensajería simultánea entre los sistemas distribuidos. Tienes que verificar que no tengas problemas de asincronía. Go es un lenguaje de programación que es asíncrono en sí. Eso quiere decir que cada operación que realizas, como enviar un montón de mensajes a otro sistema, se puede hacer sin que necesites esperar que el otro sistema te responda. Así que puedes manejar muchos mensajes en cualquier momento dado.

Ahora, el cloud computing es distribuido. Así que Go se desarrolló para abordar esa necesidad exacta. Desde el principio, Go se convirtió en una de las formas estándar de hacer informática distribuida. Y por eso creo que inmediatamente les llamó la atención a los desarrolladores. Go definitivamente es el lenguaje de la infraestructura de nube, tanto en su diseño como en el ecosistema que abarca todas las herramientas de infraestructura de nube, y los pilares fundamentales que han surgido en la última década.

Pronto empezaron a escribirse aplicaciones muy importantes como Kubernetes en Go. Google también creó Go Cloud, una biblioteca de código abierto y un conjunto de herramientas que hicieron que Go fuera aún más atractivo. Se hizo evidente que era el lenguaje de un ecosistema completamente nuevo. Era el lenguaje de la nube. Y definitivamente no le venía nada mal que los creadores tuvieran fama de desarrollar lenguajes que perduraban.

Creo que el resto de la industria dijo: “No, no creo que esto vaya a desaparecer pronto”, y de hecho los inventores del lenguaje también crearon otros, que ahora tienen 50 o 60 años.

Carmen Andoh es gerente de programas para el equipo de Go en Google.

Bueno, entonces tenemos un nuevo lenguaje, Go, que se diseñó para ofrecer la concurrencia que requiere la infraestructura de nube ¡Perfecto! Y ahora sabemos que los lenguajes de los diseñadores de Go tienden a durar medio siglo. Eso también está perfecto. Pero mi pregunta es, ¿qué va a pasar en 50 años cuando Go se parezca más a COBOL? ¿Qué va a pasar cuando haya código Go heredado por todos lados, que solo los desarrolladores sénior entiendan? ¿Estaremos preparados para el momento en que la infraestructura de nube actual comience a volverse obsoleta? ¿Lo que COBOL y las mainframes nos han enseñado nos va a ayudar a diseñar un futuro mejor para Go y la nube?

Afortunadamente, encontré a la persona ideal para plantearle esas preguntas. Con eso continuamos.

¿Cómo podemos preparar nuestros lenguajes para el futuro? Sabemos que están ligados a la infraestructura de su época. Sabemos que con el tiempo las nuevas infraestructuras van a reemplazar a las anteriores. Entonces, ¿qué estamos haciendo hoy para que las cosas sigan funcionando sin problemas mañana?

Me llamo Kelsey Hightower, trabajo en Google, soy Developer Advocate, y me dedico a convertir las tecnologías abiertas en productos para Google Cloud.

Kelsey dedica mucho tiempo a pensar en el futuro de la programación. Me daba curiosidad saber si un día terminaríamos con otro grupo de programadores ya entrados en años, con conocimientos místicos mágicos en Go, como actualmente sucede con COBOL. ¿Estamos al menos haciendo planes para ese futuro a largo plazo? Kelsey y yo nos pusimos a averiguarlo.

... y así sucesivamente. Pero al pensar en algunos de los nuevos desafíos actuales, como lidiar con Internet, con la red, con muchos usuarios, con cientos de miles de usuarios simultáneos, con diferentes conjuntos de computadoras y distintas arquitecturas... Al pensar en esos nuevos casos de uso, dan ganas de un nuevo lenguaje. Por ejemplo, JavaScript es para la web, así que no se trata de reacondicionar COBOL para que podamos usarlo para programar la web. Actualmente tenemos muchos lenguajes que ya están bien establecidos, y todos ellos están sumamente concentrados en su especialidad.

Entonces, en ese caso, ¿debemos fomentar el que la gente vuelva a COBOL? Si estamos desarrollando nuevos lenguajes altamente especializados para los nuevos problemas, pero COBOL sigue entre nosotros, ¿hay que alentar a los programadores para que aprendan a usarlo para poder mantener nuestro código heredado?

Pues ese va a ser el desafío que enfrenten las empresas, ¿no? Porque imagínate que has invertido 10 o 20 años en COBOL, y ya nadie quiere aprender a usarlo. Digo, nadie sale de la universidad diciendo: “Ah, pues yo voy a apostarle...”

Claro.

“...a un lenguaje más viejo que mis papás”. Entonces, en esa situación hay que preguntarse, ¿cuál es el riesgo de seguir con COBOL? ¿Seguirá vigente en el futuro? Yo lo que creo es que sigue vigente para ciertos trabajos, pero tenemos que plantearnos una pregunta: ¿ya es hora de avanzar? ¿Ya es hora de evolucionar un poco? Si tu empresa todavía tiene miles y millones de líneas en COBOL, necesitas contratar a todos los programadores que conozcan el lenguaje, pero tal vez hay que pensar en qué pueden aprender los demás lenguajes de COBOL, para que incorporen parte de sus funciones y sus bibliotecas.

“La vida después de COBOL” sería un gran proyecto de infraestructura. En mi analogía del metro de Nueva York, eso implicaría reemplazar cada túnel subterráneo. Entonces me dio curiosidad saber si podíamos anticipar esos problemas e incluso facilitarnos la vida en el futuro.

Si comparamos la nube con las mainframes, ¿vamos a terminar en la misma situación, con bases de código heredado que utilizan lenguajes algo antiguos, pero muy estables, y vamos a tener que decidir si seguimos adelante o nos quedamos como estamos?

Pues... Lo que distingue a la nube es que no es de un solo proveedor, ¿no? Muchos proveedores de servicios en la nube generalmente combinan conjuntos de tecnología que te permiten tener el lenguaje de programación y los paradigmas de programación que tú escojas, ya sea los uses por eventos o como servicios web basados en HTP. Entonces, eso significa que puedes elegir qué lenguaje vas a usar, para enfocarte en lo que se resuelve. Así que los datos siempre entran y salen, pero tú eliges cómo se procesan.

La mainframe solo tenía una interfaz principal, ¿no? O sea, si escribes un trabajo, lo tienes que enviar de cierto modo, supervisarlo de otro modo y luego lanzarlo de otro modo distinto. Es muy limitante en sí. Si piensas en algunas de las mainframes nuevas, son compatibles con algunas de las tecnologías más recientes, así que incluso en el mundo de las mainframes, empiezas a ver la ampliación de los lenguajes de programación que puedes utilizar para ejecutar tus trabajos.

Entonces empezamos a preguntarnos, bueno, ahora que ya tengo una nueva opción, ¿en qué momento debo dejar de usar este paradigma de programación específico? O sea, yo no creo que nos atoremos.

Claro.

Pero creo que sería bueno que hubiera una máquina nueva que estuviera distribuida, tal vez con un menor costo de entrada, para que no tengas que comprar toda la mainframe para poder comenzar. Porque no queremos sacrificar la comodidad de decir: “aquí está mi trabajo, tú lo corres y me avisas cuando esté listo”.

Absolutamente. ¿Crees que lo que le está sucediendo, o lo que le ha sucedido a COBOL, le sucederá a cualquiera de los lenguajes actuales? Por ejemplo, Go. ¿Nos ves luchando por mantenerlo y por lograr que las personas quieran usarlo en 30 años?

Es que yo creo que ese puede ser el destino de cualquier lenguaje. Por ejemplo, piensa en Python: ha estado aquí durante mucho tiempo. Creo que como 20 años, si no es que más. Entonces creo que lo que pasa... Porque Python tuvo un resurgimiento en su uso, es como el lenguaje fundamental del aprendizaje automático.

Sí.

Para bibliotecas como Tensorflow. Así que yo creo que el error es guiarse solo por el tiempo, yo creo que esa no es la manera correcta de ver las cosas. También hay que considerar qué tan vigente está esa comunidad. Qué tanta capacidad de adaptación tiene ese lenguaje. Y creo que lo que Python hizo muy muy bien es que... esa comunidad vio la capacidad de lograr que otros lenguajes fueran más fáciles de usar. Por ejemplo, Tensorflow tiene mucho de C++, así que es un lenguaje que probablemente no es tan fácil como Python. Así que podrías tomar Python y usarlo para generar algunas de las cosas que se hacen con Tensorflow, por ejemplo. Ahora que el aprendizaje automático está en auge, la gente se llevó Python a esa nueva área. ¿Y sabes qué? Eso implica que Python va a seguir vigente durante mucho tiempo. Y lo mismo va a pasar con Go. Si Go sigue vigente... Porque, digo, está presente en muchas de nuestras herramientas de infraestructura, muchas de las bibliotecas en la nube, así que esa presencia va a garantizar que siga vigente. Así que para mí el secreto es que las comunidades se hagan un lugar en el futuro, para que cuando llegue se aseguren de formar parte de él.

Sí. Entonces, ¿cómo le hacemos para que nuestros lenguajes estén preparados para el futuro? Es decir, ¿cómo diseñamos un lenguaje para que dure y para que siga vigente en 20, 30 años?

Las personas que usan el lenguaje... Bueno, creo que esto es algo exclusivo del espacio del código abierto. La gente se ha alejado de los lenguajes comerciales, ¿no? Porque antes los lenguajes venían de Microsoft o de Sun Microsystems en el caso de Java™, y todo el mundo confiaba en que el proveedor se iba a encargar de la parte complicada de lograr lo que el lenguaje iba a poder hacer, las mejoras en el tiempo de ejecución... Pero ahora lo que vemos con cosas como Go, Node.js, Ruby, todos son tiempos de ejecución y lenguajes respaldados por la comunidad y enfocados. Así que cualquiera puede agregar bibliotecas nuevas, ¿no? Hubo una nueva especificación de HTP, HTP-2, que salió hace unos años, y bueno, en cada una de las respectivas comunidades hubo contribuidores que hicieron aportaciones a esas bibliotecas particulares, ¿y sabes qué pasó? Pues ahora todos esos lenguajes son compatibles con el futuro de... digamos de la web, en su mayor parte.

Entonces yo creo que ahora las personas tienen más control. Si desean que su lenguaje pueda utilizarse en nuevos casos de uso, simplemente pueden agregar las funciones pertinentes. Ya no estamos limitados a una o dos empresas. Si la empresa deja de funcionar, tal vez el tiempo de ejecución desaparezca también. Actualmente ya no vemos ese problema tan seguido.

Como habíamos dicho en este podcast, el futuro es abierto. Pero es increíble pensar que en un par de décadas, el pasado también será abierto. Porque la infraestructura y los lenguajes que nosotros dejaremos podrán transformarse y evolucionar.

Perfecto, gracias por invitarme. Ya tengo ganas de ver lo que hacen los desarrolladores, y no olvidemos que la mainframe sigue vigente. Así que no la llamemos heredada, es tecnología clásica.

Ah, me gusta, clásica, muy bien.

Kelsey Hightower es Developer Advocate en Google.

Yo me imagino un futuro lleno de lenguajes de programación clásicos, junto con nuevos lenguajes que ni siquiera han nacido todavía. Ese es el futuro que me entusiasma.

Las puertas se están cerrando, mantenga su distancia.

En 2017, el gobernador de Nueva York declaró que el metro de la ciudad estaba en estado de emergencia. Su gobierno destinó nueve mil millones de dólares para invertir en la antigua infraestructura. Eso debe recordarnos que tarde o temprano tenemos que cuidar los sistemas que heredamos. No simplemente correr hacia lo que viene. Sino llevar el pasado con uno.

En el mundo del desarrollo, tendemos a inclinarnos hacia el futuro. Creemos que nuestros lenguajes solo son útiles en el momento, cuando son la novedad. Pero, a medida que la infraestructura informática envejece, la historia del desarrollo cobra mayor importancia. Resulta que el pasado no se queda en el pasado. Tenemos que tener eso presente.

El próximo episodio se trata de Bash. Vamos a analizar los orígenes de los scripts de shell y la clave para la automatización.

Command Line Heroes en español es un podcast original de Red Hat. Hasta la próxima, sigan programando.