Show logo

Lenguajes que llegaron para quedarse

  |  Command Line Heroes Team   Desarrollo y distribución de aplicaciones. Historia de la tecnología

Command Line Heroes • • Command Line Heroes: tercera temporada: Lenguajes que llegaron para quedarse

Command Line Heroes: tercera temporada: Lenguajes que llegaron para quedarse

About the episode

Los lenguajes que se utilizan para la infraestructura de TI no tienen fecha de vencimiento. COBOL lleva 60 años en acción, y así va a seguir. Al mismo tiempo que mantenemos miles y millones de líneas de código clásico para las mainframes, desarrollamos nuevas infraestructuras para la nube en lenguajes como Go. COBOL dio un salto informático enorme y permitió que las empresas se volvieran más eficientes. Chris Short nos cuenta que antes se creía que aprender COBOL era una buena apuesta a largo plazo, pero poco a poco se fueron escribiendo miles y millones de líneas con él. Ahora, sesenta años después, esas líneas no pueden reemplazarse fácilmente, y hay pocos especialistas que conozcan el lenguaje. Ritika Trikha explica que se necesita un cambio: o más gente aprende COBOL, o las industrias que lo utilizan van a tener que actualizar su código. Ambas decisiones son difíciles. Pero no estamos escribiendo el futuro en COBOL. La infraestructura de TI actual está en la nube, y gran parte de ella se escribe en Go. Carmen Hernández Andoh nos recuerda que los diseñadores de Go buscaban un lenguaje que se adaptara mejor a la nube. Y Kelsey Hightower señala que los lenguajes normalmente se concentran demasiado en una sola tarea, pero cada vez son más abiertos y flexibles.

Nos tomaremos un descanso durante las fiestas y volveremos con el episodio 6 la primera semana de enero.

Command Line Heroes Team Red Hat original show

Suscribir

Subscribe here:

Listen on Apple Podcasts Listen on Spotify Subscribe via RSS Feed

Transcripción

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, y que al final de esa década siguiera siendo la mainframe más poderosa del mundo. Y así se hizo durante unos 20 años. Entonces, ser programador de COBOL o programador de mainframes era una muy buena apuesta profesional, porque ibas a seguir trabajando con la misma tecnología durante mucho tiempo. Chris Short es gerente principal de marketing de productos en Red Hat. Tenía mucho sentido especializarse en COBOL. Pero claro, 60 años después, esa apuesta profesional se ve diferente. Hola, me llamo Ritika Trikha. Escribo sobre tecnología. Ritika nos va a contar en qué se ha convertido la situación de COBOL seis décadas después. COBOL sigue presente en todas partes. Muchísimas transacciones financieras pasan por sistemas de COBOL a diario, y también muchas transacciones gubernamentales. Pero lo que pasa es que ahora hay muy pocos programadores de COBOL, en comparación con el volumen de código que hay que mantener. En otras palabras, tenemos una crisis. Hay miles de millones de líneas de código COBOL que siguen ejecutándose y que necesitan mantenimiento. Pero la mayoría de los programadores que escribieron ese código ya se jubilaron. Y los nuevos programadores no aprenden COBOL. Se cree que el 95 % de las transacciones de tarjetas de débito y crédito en los cajeros automáticos pasan por sistemas de COBOL. Hay muchísimo código escrito en COBOL que sigue siendo importante para la infraestructura de nuestras empresas e instituciones gubernamentales. Pero ¿quién va a mantener todo ese código? ¿Quién lo va a actualizar cuando sea necesario? Entonces, en este momento tenemos a las empresas más grandes del mundo en una situación súper incómoda. Dependen de una infraestructura de software antigua y, en cierto modo, funciona muy bien. Pero es muy difícil encontrar personas que sepan qué hacer cuando algo se descompone. Realmente creo que las organizaciones están en una encrucijada, porque tienen dos opciones. Pueden invertir en contratar y capacitar a más programadores de COBOL, que es caro y puede ser difícil. O pueden intentar modernizar todos esos sistemas y migrar a tecnologías más nuevas, que también es muy caro. Ritika Trikha es escritora de artículos de tecnología. Como dice Ritika, las dos opciones cuestan mucho. ¿Puedes imaginarte lo que implica migrar miles de millones de líneas de COBOL que funcionan perfectamente? Sería un proyecto de software enorme. Tardará años, si no es que décadas. Y es cierto que COBOL puede ser muy estable y confiable, pero también está muy vinculado a la infraestructura de la época de las mainframes. Los nuevos programadores no quieren trabajar con él. Los nuevos lenguajes como Go sí les llaman la atención. Y resulta que Go tiene sus propios vínculos infraestructurales. Igual que COBOL estaba estrechamente vinculado a las mainframes, Go está estrechamente vinculado a la infraestructura de la nube. Hola, me llamo Carmen Hernández Andoh. Soy gerente de programas para el equipo de Go en Google. Hablé con Carmen sobre el diseño y la evolución de Go. Go se diseñó para resolver los problemas que tenía Google en ese momento. Era una empresa en crecimiento muy acelerado, y tenían proyectos grandes que tardaban mucho en compilarse. Tenían desarrolladores muy inteligentes que tenían que lidiar con la complejidad de C++, y mucho código de C++ muy complicado. Entonces, los diseñadores del lenguaje querían algo que fuera fácil de aprender, muy simple, muy legible, y que se compilara rápido. Go se diseñó para el mundo de la nube de Google. Pero resultó que el resto del mundo también estaba avanzando hacia la nube. Las características que lo hacían ideal para Google resultaron ser características que también lo hacían ideal para las aplicaciones distribuidas y para las aplicaciones de infraestructura, que se estaban volviendo mucho más importantes conforme más empresas empezaban a migrar hacia la nube. Go se lanzó en 2009, en el momento perfecto. Toda la industria empezaba a buscar soluciones en la nube. Y de repente se dieron cuenta de que tenían Go, que parecía diseñado específicamente para ese mundo de la nube. Muchos proyectos importantes de infraestructura de la nube, como Docker y Kubernetes, están escritos en Go. Yo creo que Go encontró su nicho. Se convirtió en un lenguaje de infraestructura. Las personas lo usan para crear herramientas, para desarrollar aplicaciones de red y para escribir servicios. Es el lenguaje que elegirías si quisieras escribir algo como un balanceador de carga o un proxy. Carmen Hernández Andoh es gerente de programas para el equipo de Go en Google. El surgimiento de Go como lenguaje de infraestructura de la nube me recuerda mucho a lo que le pasó a COBOL con las mainframes hace 60 años. Pero la diferencia importante es que ahora entendemos mejor qué sucede cuando un lenguaje se vuelve parte fundamental de la infraestructura. No queremos que dentro de 60 años los desarrolladores estén luchando por encontrar a los pocos programadores de Go que queden en el mundo. ¿Cómo te aseguras de que tu lenguaje no se vuelva heredado? Le pregunté a Kelsey Hightower, que es developer advocate en Google. Hola, me llamo Kelsey Hightower. Kelsey tiene una perspectiva muy interesante sobre cómo los lenguajes evolucionan junto con la infraestructura. Yo creo que si miras COBOL, tienes que darle el crédito que se merece. O sea, logró su objetivo, ¿no? Incluso al día de hoy. Si quieres procesar muchísimas transacciones con muy muy poca latencia y alta disponibilidad, la mainframe sigue siendo la mejor opción. Ahora, es cierto que muchas personas nuevas no quieren trabajar con las mainframes. Las perciben como tecnología heredada. Pero en realidad es muy buena para su propósito. ¿Y crees que eso le va a pasar a Go en un futuro? ¿O hay algo diferente en Go que va a evitar que caiga en la misma situación? Pienso que con Go va a pasar algo diferente, porque las personas que diseñaron Go habían vivido lo que habían vivido con C++. Y sabían lo que pasaba cuando intentabas usar C++ en equipos grandes: se volvía muy difícil mantener el código, los tiempos de compilación se volvían muy lentos. Entonces, cuando diseñaron Go, en cierto modo dijeron: "queremos aprender de la historia, vamos a ver qué podemos hacer diferente". ¿Entonces qué hicieron diferente? Bueno, una cosa que hicieron fue asegurarse de que Go tuviera compatibilidad hacia atrás. Esto significa que el código que escribes hoy en Go va a seguir funcionando en las futuras versiones del lenguaje. No van a cambiar la API de una manera que rompa tu código. Eso es muy importante para la adopción a largo plazo. Otra cosa que me parece interesante de Go es que tiene mucho enfoque en la simplicidad. Exacto. Los diseñadores de Go tomaron decisiones muy deliberadas para mantener el lenguaje simple. No agregaron muchas características que otros lenguajes sí tienen. Por ejemplo, Go no tiene herencia de clases como Java o C++. No tiene genéricos... aunque bueno, eso cambió recientemente. Pero durante mucho tiempo no los tuvieron porque querían que el lenguaje fuera fácil de aprender y de leer. Y eso se conecta con la infraestructura de la nube, ¿no? Sí, totalmente. En la nube, a menudo trabajas con equipos distribuidos, tal vez personas que están en diferentes zonas horarias, tal vez personas que tienen diferentes niveles de experiencia. Entonces, tener un lenguaje que sea fácil de leer y entender es muy valioso. Cuando alguien lee código Go, puede entender rápidamente lo que está pasando. ¿Pero crees que eso es suficiente para evitar que Go se vuelva heredado en el futuro? Bueno, creo que hay otra cosa importante: la comunidad. Go tiene una comunidad muy activa de desarrolladores que contribuyen al lenguaje y crean bibliotecas. Y mucho de eso es código abierto. Entonces, aun si Google dejara de trabajar en Go mañana, la comunidad podría seguir desarrollándolo. Esa es una buena diferencia con COBOL. COBOL era más cerrado en sus inicios. Exacto. Y además, Go se diseñó para la nube, que es una infraestructura que está en constante evolución. Las mainframes eran más estáticas. Una vez que instalabas una mainframe, podía durar décadas sin muchos cambios. Pero la nube cambia constantemente. Nuevos servicios, nuevas APIs, nuevas formas de hacer las cosas. Entonces, Go tiene que evolucionar también. ¿Y cómo se adapta Go a esos cambios? Pues el equipo de Go lanza nuevas versiones regularmente, cada seis meses más o menos. Y en cada versión incluyen mejoras en el rendimiento, nuevas bibliotecas estándar, corrección de errores. Pero siempre mantienen esa compatibilidad hacia atrás de la que hablamos. ¿Qué opinas de la evolución de los lenguajes en general? ¿Crees que los lenguajes modernos están mejor preparados para el futuro que los lenguajes del pasado? Creo que hemos aprendido mucho de los errores del pasado. Ahora entendemos mejor la importancia de las comunidades, de la documentación, de mantener los lenguajes simples y legibles. También entendemos mejor cómo diseñar APIs que no se rompan con el tiempo. ¿Pero hay algún riesgo de que estemos cometiendo errores nuevos? Por supuesto. Creo que uno de los riesgos es la fragmentación. Ahora hay muchísimos lenguajes nuevos, y a veces es difícil decidir cuál usar para un proyecto. También está el riesgo de que nos enfoquemos demasiado en la novedad y no suficiente en la estabilidad a largo plazo. ¿Cómo podemos encontrar ese equilibrio? Creo que es importante no adoptar nuevos lenguajes solo porque son nuevos. Hay que evaluar si realmente resuelven un problema que tienes, si tienen una comunidad activa, si tienen buena documentación. Y también hay que considerar el costo de migrar de un lenguaje a otro. Hablando de migración, ¿qué consejo le darías a las organizaciones que están atrapadas con COBOL heredado? Bueno, primero diría que no hay que entrar en pánico. COBOL no va a desaparecer mañana. Pero sí es importante tener un plan a largo plazo. Pueden empezar por documentar muy bien su código existente, entrenar a nuevos desarrolladores en COBOL, o crear APIs modernas que envuelvan su código COBOL antiguo. ¿Y para las organizaciones que están empezando nuevos proyectos? Para proyectos nuevos, yo recomendaría elegir lenguajes que tengan comunidades fuertes y que estén bien establecidos. No necesariamente el lenguaje más nuevo, sino uno que haya demostrado que puede evolucionar con el tiempo. Go es una buena opción para infraestructura, Python para ciencia de datos, JavaScript para desarrollo web. ¿Qué piensas del futuro de los lenguajes de programación en general? Creo que vamos a ver más especialización. En lugar de tener uno o dos lenguajes que traten de hacer todo, vamos a tener lenguajes que son muy buenos para cosas específicas. Go para infraestructura, Rust para programación de sistemas, Python para machine learning, etc. ¿Y eso no va a crear más fragmentación? Tal vez, pero creo que también va a crear herramientas mejores. Cuando un lenguaje se enfoca en hacer una cosa muy bien, puede optimizarse para esa tarea. Y las herramientas de desarrollo están mejorando para ayudarnos a trabajar con múltiples lenguajes en un mismo proyecto. Antes de que terminemos, quería preguntarte sobre algo específico. ¿Crees que los lenguajes que estamos diseñando ahora van a enfrentar los mismos problemas que COBOL en el futuro? Es posible. Pero creo que hay una diferencia clave: ahora estamos más conscientes del problema. COBOL se diseñó en una época en que nadie imaginaba que las computadoras iban a evolucionar tan rápido. Ahora sabemos que la tecnología cambia constantemente, entonces diseñamos nuestros lenguajes para que puedan adaptarse. ¿Y qué papel juega el código abierto en todo esto? El código abierto es fundamental. Cuando un lenguaje es de código abierto, no depende de una sola empresa para sobrevivir. La comunidad puede mantenerlo y hacerlo evolucionar aunque la empresa original deje de trabajar en él. Eso le da mucha más longevidad. ¿Hay algún ejemplo específico de esto? Sí, un buen ejemplo es Linux. Linus Torvalds ya no es el único que mantiene Linux, hay miles de desarrolladores de todo el mundo que contribuyen. Entonces, aunque Linus decidiera dejar de trabajar en Linux mañana, el proyecto seguiría adelante. ¿Y crees que esa es la dirección hacia donde van los lenguajes de programación? Sí, creo que sí. Los lenguajes más exitosos de los últimos años han sido de código abierto: Python, JavaScript, Go, Rust. Y creo que esa tendencia va a continuar. Una última pregunta: si tuvieras que darle un consejo a un desarrollador joven que está empezando su carrera, ¿qué le dirías sobre elegir lenguajes de programación? Le diría que no se preocupe demasiado por elegir el lenguaje "perfecto". Los conceptos fundamentales de programación se transfieren entre lenguajes. Es más importante aprender a resolver problemas y a escribir código limpio que dominar un lenguaje específico. Y también le diría que aprenda varios lenguajes, porque cada uno tiene sus fortalezas. ¿Y sobre el futuro? ¿Qué tendencias crees que van a ser importantes? Creo que vamos a ver más automatización en el desarrollo de software. Las herramientas de inteligencia artificial ya están empezando a ayudar a los desarrolladores a escribir código. También creo que la computación en la nube va a seguir evolucionando, y eso va a crear nuevas oportunidades para lenguajes como Go. ¿Crees que la inteligencia artificial va a reemplazar a los programadores? No creo que los reemplace completamente, pero sí creo que va a cambiar la naturaleza del trabajo. Los programadores van a pasar menos tiempo escribiendo código rutinario y más tiempo resolviendo problemas complejos y diseñando sistemas. ¿Y qué significa eso para los lenguajes de programación? Creo que los lenguajes van a necesitar ser aún más expresivos y fáciles de leer, para que las herramientas de IA puedan entenderlos mejor. También creo que va a haber más enfoque en la corrección y la seguridad del código. Antes de terminar, hay algo que me ha estado preguntando: ¿crees que algún día vamos a tener un lenguaje de programación universal que pueda hacer todo? Es una pregunta interesante. En teoría, cualquier lenguaje Turing-completo puede hacer cualquier cosa que otro lenguaje pueda hacer. Pero en la práctica, diferentes lenguajes son mejores para diferentes tareas. Creo que siempre va a haber valor en la especialización. ¿Pero no sería más eficiente tener un solo lenguaje? En cierto modo, sí. Pero también perdería mucho. Es como preguntar si sería mejor tener una sola herramienta en lugar de un martillo, un destornillador y una sierra. Técnicamente podrías hacer todo con un martillo, pero no sería muy efectivo. Esa es una muy buena analogía. ¿Y qué opinas sobre el equilibrio entre adoptar nuevas tecnologías y mantener las existentes? Creo que es uno de los desafíos más grandes que enfrentamos en tecnología. Por un lado, necesitamos innovar y adoptar nuevas herramientas que nos hagan más productivos. Por otro lado, tenemos sistemas existentes que funcionan y que no podemos simplemente tirar a la basura. ¿Cómo encontramos ese equilibrio? Creo que la clave está en la migración gradual. No tienes que reescribir todo de una vez. Puedes empezar por las partes nuevas de tu sistema, o por las partes que necesitan más mantenimiento. Y usar APIs para conectar lo viejo con lo nuevo. ¿Y para las organizaciones que están empezando desde cero? Ahí tienen más libertad, pero también más responsabilidad. Tienen que pensar no solo en lo que necesitan ahora, sino en lo que van a necesitar en cinco o diez años. Y tienen que elegir tecnologías que les den esa flexibilidad. Una reflexión final: ¿qué lección podemos aprender de la historia de COBOL? Creo que la lección principal es que las decisiones técnicas que tomamos hoy van a tener consecuencias durante décadas. Entonces, tenemos que pensar cuidadosamente en la sostenibilidad a largo plazo, no solo en resolver el problema inmediato. ¿Y eso cambia la forma en que deberíamos evaluar los lenguajes de programación? Definitivamente. No solo deberíamos preguntarnos "¿este lenguaje resuelve mi problema ahora?" sino también "¿va a ser fácil de mantener en el futuro? ¿tiene una comunidad fuerte? ¿cómo va a evolucionar?" Kelsey, muchas gracias por esta conversación tan interesante. Gracias a ti. Ha sido un placer hablar sobre estos temas. Kelsey Hightower es Developer Advocate en Google. Al escuchar a Kelsey, me queda claro que el futuro de los lenguajes de programación no se trata solo de crear herramientas mejores, sino de crear herramientas que puedan evolucionar con nosotros. La historia de COBOL nos enseña que las decisiones que tomamos hoy sobre infraestructura y lenguajes van a afectar a los desarrolladores durante décadas. Pero también me da esperanza. Los lenguajes modernos como Go están diseñados con las lecciones del pasado en mente. Son de código abierto, tienen comunidades fuertes, y están construidos para adaptarse al cambio. 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.

More about historia de la tecnología

Para imaginar el futuro, es importante mirar al pasado y descubrir historias de innovación que asombren e inspiren.

Publicación en blog

Presentación de OpenShift Service Mesh 3.2 con el modo ambient de Istio

17 de noviembre de 2025
  |  
Jamie Longmuir
APIs
Publicación en blog

Prepara a tu equipo. Reduce riesgos. Desarrolla habilidades escalables.

12 de enero de 2026
  |  
Karl Reynolds
Professional development
Podcast original

Command Line Heroes: Cuarta temporada: Una cosa más con Steve Wozniak

Historia de la tecnología
Podcast original

Command Line Heroes: Cuarta temporada: Hardware open source: la alianza de los fabricantes

Open source, Historia de la tecnología
Podcast original

Command Line Heroes: Cuarta temporada: Teléfonos más inteligentes: las aventuras de la computadora de mano.

Historia de la tecnología

Sobre el podcast

Command Line Heroes

During its run from 2018 to 2022, Command Line Heroes shared the epic true stories of developers, programmers, hackers, geeks, and open source rebels, and how they revolutionized the technology landscape. Relive our journey through tech history, and use #CommandLinePod to share your favorite episodes.