La revolución de C

Estamos al comienzo de una nueva ola de investigación. Nuestra capacidad creativa está aumentando.

Ruido. Ruido.

Esos hombres son ingenieros de diseño en Bell Telephone Laboratories.

En la década de los 60, Bell Labs era el epicentro de la innovación, y fue ahí, en Nueva Jersey, Estados Unidos, donde nuestro futuro tecnológico dio sus primeros pasos. Ahí desarrollaron el láser. Desarrollaron el transistor. Fue la cuna de la teoría de la información y, en 1968, toda esa innovación alcanzó un nuevo apogeo cuando un grupo de cuatro programadores produjo algo tan revolucionario que cambió de manera radical la forma en que funciona el mundo.

Esto es Command Line Heroes en español, un podcast original de Red Hat. Durante toda la temporada hemos visto algunas de las historias más importantes de los lenguajes de programación, y finalmente hemos llegado al último episodio de la temporada. Y para el final dejamos la cereza del pastel: la historia del lenguaje que hizo posibles todos los demás lenguajes. Hace 50 años, en Bell Labs, diseñaron C, un lenguaje de uso general tan importante que a veces se nos olvida que fue un logro verdaderamente extraordinario.

Para ver el panorama completo, tenemos que regresar a la década de 1960, justo antes de su surgimiento. Era un momento en que todo parecía posible.

En la década de 1960, Bell Labs era casi casi la tierra prometida. Era un laboratorio de investigación y desarrollo que no se compara con nada de la actualidad.

Escuchamos a Jon Gertner, autor de The Idea Factory: Bell Labs and the Great Age of American Innovation. Le pedimos que nos explicara lo que sucedía en ese entonces. En tu opinión, ¿qué fue lo que hizo que Bell Labs fuera una fábrica de ideas?

Mh, yo creo que actualmente pensamos que la competencia genera innovaciones maravillosas, pero yo no estoy seguro; de hecho, los logros de Bell Labs de una u otra manera refutan esa idea. Eran investigadores e ingenieros que no vivían mucha presión, y al mismo tiempo, como Bell Labs tenía un lugar jerárquico entre los laboratorios de investigación, podía contratar a los mejores, a los más inteligentes, y darles el tiempo suficiente y los fondos necesarios para trabajar en los problemas que les parecían interesantes. Si podías dar buenos motivos para realizar un proyecto de investigación que era pertinente para el ideal y el objetivo de la empresa telefónica, por ejemplo, pues obtenías el financiamiento para tu investigación.

Jon recalca que aunque Bell Labs era producto de una empresa con fines de lucro, tenía un espíritu más bien académico. Al permitir que los empleados utilizaran sus propias ideas, Bell practicó los principios de liderazgo abierto similares a los que podrías encontrar en las comunidades de código abierto.

Era una época antes de Apple, antes de Google, antes de Microsoft, por ejemplo. La historia de la informática muchas veces se concentra en los orígenes del Homebrew Computer Club y de lo que se generó a partir de ahí. Y yo creo que esto fue igual de importante. Y sucedió en lo que ahora nos parecería un lugar algo insólito para eso, la zona suburbana de Nueva Jersey. Pero eran científicos, investigadores e ingenieros informáticos que estaban haciendo grandes avances que luego tendrían repercusiones muy significativas y trascendentales para todo el mundo.

Uno de los proyectos trascendentales, que era un gran desafío, fue el concepto del tiempo compartido. ¿Podrían crear un sistema operativo que pudieran usar cientos e incluso miles de usuarios al mismo tiempo? Eso cambiaría todo el panorama. A partir de 1964, los cerebritos de Bell Labs se unieron a General Electric y al MIT para ver si podían avanzar hacia ese santo grial. En realidad el MIT había empezado un año antes, con una cosa que se llamaba Project MAC, pero pronto, varios de los mejores equipos empezaron a trabajar juntos para desarrollar un sistema operativo de mainframe con tiempo compartido.

De hecho, John McCarthy introdujo el concepto en 1959. Si quieres conocer la historia completa, escucha el episodio siete de esta temporada, que se trata de la inteligencia artificial. McCarthy se imaginó una gran máquina que pudiera repartir su atención entre varios usuarios. Pensó que una máquina de esas características podría expandir exponencialmente toda la cultura informática. O sea, imagínate eso. Si mil usuarios pueden trabajar en una máquina, se democratiza todo el mundo de la programación, todo el mundo de las computadoras. Entonces, ese equipo de pesos pesados se propuso hacer realidad el sueño de McCarthy, y le dieron un nombre a aquel sistema operativo imaginario. Se llamaba Multics.

Trabajaron en el tiempo compartido durante muchos años, pero el proyecto tragaba dinero, y después de una década, la meta no se veía ni cerca. Para empeorar las cosas, el jefe de investigación, Bill Baker, era químico, así que no le interesaba mucho el departamento de informática de Bell. Y podemos sumar un problema más: un problema de orgullo.

Una cosa que se veía mucho en Bell Labs es que a menudo trabajaban en los proyectos solos. Había cierta sensación dentro de la empresa de que tenían a todas las personas que necesitaban y todas las ideas que necesitaban y las mejores tecnologías, y si había un problema que valía la pena resolver, tenían los recursos necesarios. Y lo que también puede haber sucedido es que en cierta medida Multics no haya sido un buen proyecto para Bell Labs, porque ese tipo de esfuerzo más grande y en colaboración no funcionaba bien dentro del sistema de Bell ni satisfacía a sus ejecutivos.

Jon Gertner es el autor de The Idea Factory. Su último libro se llama The Ice at the End of the World.

Bell Labs se retiró oficialmente del proyecto Multics en abril de 1969, así que... fin de la historia, ¿no? Para Bell Labs, el sueño del tiempo compartido Multics estaba muerto. ¿O no? Pues resulta que no todos los investigadores de Bell Labs renunciaron al proyecto del tiempo compartido. Todo el mundo le había dado la vuelta a la página, pero hubo cuatro rebeldes que se aferraron al sueño. Y esa es nuestra próxima historia.

Algunos sueños son tan grandes, que simplemente no pueden morir.

Era muy importante.

Esa era Joy Lisi Rankin. Es la autora de A People’s History of Computing in the United States. Joy y yo conversamos sobre el sueño del tiempo compartido y sobre el hecho de que era tan importante que no podíamos dejarlo ir.

Era muy importante, y muy ambicioso, porque hasta ese momento o, bueno, hasta que se lanzó el proyecto, la mayoría de los sistemas de tiempo compartido a principios de la década de los sesenta tenían quizás 40 o 50 terminales en una sola mainframe. Así que, aumentar esa cantidad era algo importante, y quizás más ambicioso de lo que la gente pensaba, así que el proyecto tuvo ciertas dificultades para cumplir su objetivo inicial, pero la idea del tiempo compartido siguió viva de varias maneras y, de hecho, progresó; no solo en el MIT, sino en otros lugares.

Sí. ¿Y quién impulsaba la necesidad del tiempo compartido en la década de los sesenta? Mencionaste al MIT, a GE, a Bell Labs. Entonces, ¿eran empresas? ¿O la comunidad académica? ¿Quién estaba detrás?

Creo que lo impulsaban tanto las comunidades académicas como las empresariales, además de algunas comunidades científicas, porque como decía, era una experiencia más interactiva y personalizada de la informática. Pero yo creo que los profesores también lo estaban impulsando. Y a nivel nacional hubo una conversación para crear un servicio público informático para todo el país. O sea, básicamente, una red nacional de tiempo compartido. Y, en realidad, ciertos líderes de pensamiento en Estados Unidos creían que el tiempo compartido sería tan importante como la electricidad o el servicio de teléfono o de agua.

Vaya.

Ajá, ¿verdad? Es…

Es muy importante.

¡Importantísimo!

Joy me ayudó a recordar que, aunque este episodio se concentra en el equipo que desarrolló C y UNIX, en Bell Labs, el esfuerzo general para lograr el tiempo compartido fue realmente un movimiento, y fue más grande que cualquiera de los equipos en particular. En realidad, era un esfuerzo para pensar en la informática como un servicio público, y tenía tantos héroes que no podemos mencionarlos a todos. Personas como Bob Albrecht y Martin Greenberger, entre muchos otros.

Bueno, ya que hice ese paréntesis, este es el resto de mi conversación con Joy.

Entonces, cuando John McCarthy habló por primera vez sobre el tiempo compartido públicamente en el MIT en un discurso que dio, lo comparó explícitamente a la electricidad y dijo: “Es una forma en que todos podrán acceder a la informática, no solo en las universidades, las escuelas o las empresas, sino también desde sus hogares”. Si retrocedemos y leemos artículos y documentos de ese momento, para muchas personas no había ninguna duda de que habría un servicio público informático que podría regularse y que, de hecho, estaría regulado. Así que hubo mucha fe y apoyo en esa especie de servicio público nacional de tiempo compartido.

Lo que es interesante es que, para 1970, IBM se retiró de la industria del tiempo compartido. Incluso GE vendió su departamento de computadoras mainframe, pero de hecho conservó su parte de tiempo compartido del negocio. ¿Podemos hablar de eso? ¿Qué sucedió en 1970?

Creo que 1970 se convirtió en una especie de marcador, tal vez artificial, que dio fin a la promesa de los servicios públicos informáticos o de la industria del tiempo compartido. Pero no es realmente así. Creo que, a fines de los sesenta, era evidente que el MIT y Multics tenían dificultades para crear el sistema de tiempo compartido para miles de terminales, y la cosa es que era un proyecto público muy famoso. Y al mismo tiempo, a fines de la década de 1960, ya había decenas de empresas de tiempo compartido, que ofrecían la informática como servicio público, que se habían esparcido por Estados Unidos y estaban en auge. Era una especie de burbuja tecnológica. Y luego, el entusiasmo se desvaneció; no por completo porque aunque GE vendió su negocio de computadoras mainframe de tiempo compartido, conservó el tiempo compartido como negocio de servicio público durante los setenta y los ochenta, y era rentable. Y también en los ochenta, ciertas universidades, como el MIT por ejemplo, siguieron ejecutando sistemas de tiempo compartido.

Creo que hay un recuerdo general de que el tiempo compartido fue una burbuja tecnológica que simplemente murió en la década de 1970, en parte porque había mucha atención en los desafíos que enfrentaba Multics. Pero, en realidad, si vemos cómo lo utilizaba la gente, cuán rentable era y cuánto éxito tenía, veremos que prosperó durante la década de 1970.

Ahora, volvamos a Bell Labs, en que había un grupo de cuatro tecnólogos que querían un sistema propio de tiempo compartido: Ken Thompson, Dennis Ritchie, Doug McIlroy y J.F. Ossanna. Pero no querían Multics; querían dar un salto hacia algo más limpio y poderoso, algo que recibió el nombre de UNIX.

Yo diría que Multics fue la inspiración para UNIX, en el sentido de que algunos de los programadores que trabajaban en Multics disfrutaban tanto de los beneficios de la programación en un sistema de tiempo compartido que, cuando se hizo evidente que Multics tenía dificultades, quisieron crear un entorno para ellos mismos. Eran programadores de Bell Labs, y decidieron crear su propio marco de programación y algo así como un sistema de tiempo compartido, que luego se convirtió en UNIX.

Joy Lisi Rankin es la autora de A People’s History of Computing in the United States.

Más tarde, Dennis Ritchie describiría al grupo que conformaban sus tres compañeros de Bell Labs y él como una fraternidad. Querían trabajar como un cuarteto unido de desarrolladores, y necesitaban el hardware que se adaptara a su programación. Pero Bell Labs realmente había dejado atrás el sueño del tiempo compartido, y por mucho que la empresa fuera una utopía para la investigación, en este caso habían llegado a su límite, así que rechazaron las propuestas para ese nuevo hardware. Simplemente era demasiado costoso. ¿Para qué correr el riesgo? Pero la fraternidad siguió adelante.

Thompson y Ritchie pidieron una máquina como la GE645, que habían usado para trabajar en Multics. Como no pudieron obtener la financiación necesaria, simplemente anotaron las ideas para los sistemas de archivos en papel. Finalmente, lograron implementar algunas de sus ideas en un juego al que le pusieron “Space Travel”, que se ejecutaba en una PDP7. Siguieron trabajando con la PDP7, que básicamente era de la misma clase que una Commodore 64. Trabajaron bit por bit, sin el apoyo de Bell, al menos al principio. Esa fraternidad le dio una nueva vida al sueño del tiempo compartido, una nueva creación a la que le pusieron UNIX.

Pero había un problema: el sistema operativo UNIX se estaba creando en lenguaje ensamblador. Es decir, estos muchachos estaban transfiriendo archivos a su PDP7 en cinta de papel, así que ya te imaginarás, estaban tratando de desarrollar algo revolucionario con herramientas que no eran adecuadas y, nuevamente, sin el apoyo de los jefes. UNIX estaba cobrando vida, pero le faltaba el lenguaje que lo hiciera brillar.

Ken Thompson escribió el primer intento de un nuevo lenguaje para UNIX, y le puso B.

Era un derivado del lenguaje de programación básico combinado, o BCPL.

Escuchamos a Andy Tanenbaum. Es profesor de ciencias de la computación en Ámsterdam y autor de muchos libros, incluido el clásico Computer Networks. Escucha la historia que cuenta sobre el lenguaje B de Thompson.

¿Entonces B es un derivado de BCPL?

El cual fue un intento de hacer un compilador de CPL, que realmente funcionara, y que se basó en ALGOL 60, que por supuesto, venía de ALGOL 58, que a su vez fue un intento por mejorar FORTRAN.

¿Entendiste? La cosa es que B venía con mucho equipaje. No era precisamente distinto de todos sus antecesores, así que no... estaba a la altura del desafío de hacer brillar a UNIX. Para empezar, B no entendía los distintos tipos de datos, y además, los lenguajes ensambladores similares seguían produciendo programas más rápido de lo que era posible, con la técnica de código enhebrado del compilador de B.

BCPL y B tenían un solo tipo de dato: la palabra. Pero las palabras eran perfectas para la IBM 704, la 709, la 7090 y la 7094, porque eran máquinas orientadas a las palabras. Pero a partir de la 360 y de todas las minicomputadoras, ya eran máquinas orientadas a los bytes, y tenían un solo tipo de datos. Así que la palabra no era buena idea. Era una pésima opción para las computadoras modernas. Así que B seguro no iba a funcionar.

Todas las máquinas en las que el equipo había trabajado antes estaban orientadas a las palabras, pero el que las cosas estuvieran orientadas hacia un solo objeto de un solo tamaño, como dijo Andy, no iba a funcionar. Afortunadamente, en este momento el alto mando de Bell Labs volvió a sumarse al proyecto, porque sintieron que algo emocionante iba a suceder. Financiaron una PDP-11 de $65 mil dólares, que era una máquina que no estaba orientada a las palabras, sino a los bytes. Ya con la PDP-11, Dennis Ritchie podía tomar el toro por los cuernos y hacerse cargo del problema del lenguaje.

Entonces tomó algunos aportes de Ken, y básicamente decidió escribir un nuevo lenguaje que era mucho más estructurado y tenía otros tipos de datos, como los caracteres, los enteros, los enteros largos, etc.

Entonces de 1971 a 1973, Dennis Ritchie se dedicó a modificar el lenguaje B. Agregó un tipo de carácter y creó un nuevo compilador para ya no tener que seguir usando el código enhebrado. Al final de esos dos años, B se había transformado en un nuevo lenguaje que se llamaba C.

Era un poderoso híbrido muy funcional, pero además tenía características detalladas que permitían que los usuarios programaran sistemas operativos. Le dio al clavo. Como no dependía tanto de la máquina, se ajustaba a otras máquinas también. Resulta que C no solo era un lenguaje con el que uno podía divertirse con aplicaciones. Era una herramienta casi universal para la programación, que mostraba la misma capacidad tanto en una computadora personal como en una supercomputadora, lo cual era muy importante porque la revolución de las computadoras personales estaba a la vuelta de la esquina.

Cuando quedó claro que este nuevo lenguaje era la opción correcta, el núcleo de UNIX y muchos de sus componentes se reescribieron en C. Así que si querías usar UNIX, tenías que usar C. El éxito de C y el de UNIX estaban entrelazados.

Aunque C era un mejor lenguaje que B, esa no fue la razón por la que se hizo popular. Se hizo popular porque era el lenguaje en el que se escribió UNIX, y cuando UNIX se distribuyó ampliamente, venía con un compilador de C y luego con dos compiladores de C. Y, bueno, las personas que usaban UNIX, que después de un tiempo eran muchas, tenían un compilador de C; además, todo lo que había en UNIX, todas sus funciones estaban escritas en C. Y C era un lenguaje muy bueno, para el arranque, y como venía con UNIX, ¿por qué buscar otra cosa?

A partir de entonces, el valor de C no dejó de crecer.

Al principio, C y UNIX dependían el uno del otro porque UNIX estaba escrito en C y tenía un compilador de C, así que, de algún modo, crecieron juntos. Llegó un momento en que C era muy popular en los sistemas UNIX, así que Steve Johnson, por ejemplo, escribió el compilador portátil de C, que podía producir códigos para otras máquinas. Y luego se escribió un compilador de C para otros sistemas operativos además de UNIX, y la gente comenzó a usarlo para escribir todo tipo de software, desde sistemas de bases de datos hasta quién sabe qué, porque estaba disponible, funcionaba y era eficiente.

Así que pronto llegaron cosas que no tenían nada que ver con UNIX y que se escribían en C, porque los beneficios del lenguaje eran obvios. Andy nos explica qué tan definitivo era el dominio de C.

Es decir, C estuvo en el lugar correcto en el momento adecuado. En la década de 1970, la informática era mucho más pequeña de lo que es ahora. La persona promedio no tenía computadora ni sabía nada de computadoras, pero las universidades y las grandes empresas sí tenían, y muchas de ellas tenían UNIX y venían con C, así que usaban C. Entonces simplemente creó una base muy grande de software, y una gran base de programadores. Si una empresa quería contratar a un programador C, publicaba un anuncio y encontraba a varios interesados. Pero si buscaba un programador para B, nadie solicitaba el puesto.

En el mundo del lenguaje C, había infraestructura: había software, bibliotecas, archivos de cabecera y muchas herramientas, y eso creó un círculo virtuoso.

Así que simplemente se volvió cada vez más popular.

Ahora, el surgimiento de Internet planteó inquietudes de seguridad sobre C, que se abordan parcialmente en variantes como C Sharp. A veces parece que ponemos todo nuestro entusiasmo en lenguajes nuevos como Python o Go. Pero una de las cosas que tratamos de hacer en este podcast es recordar que estamos muy ligados a nuestra historia, y la influencia de C sigue siendo increíble.

C dejó su marca en muchas cosas, pero una de las más obvias y actuales es Linux®, el ahijado de UNIX, que, sí, está escrito en C. Incluso la GCC (GNU Compiler Collection), que es el compilador estándar para proyectos Linux, está escrito en C. Puede que no sea obvio, pero todos los programadores de código abierto de la actualidad, que se la pasan en Linux, están vinculados a un lenguaje que se desarrolló para ellos hace casi medio siglo, y cuyo reinado crece cada año.

Resulta que actualmente los dos sistemas operativos dominantes en el mundo son Android, que se ejecuta en Linux, que es una reescritura de UNIX y iOS, que es un Berkeley UNIX 4.4. Entonces, tanto Android como iOS son UNIX, de hecho. Yo sospecho que casi todos los servidores del mundo se ejecutan en alguna versión de UNIX o Linux. Tiene una enorme influencia detrás de las cámaras: cualquier sistema que ejecute UNIX va a estar orientado a C, y todo lo que se escriba para ese sistema estará en C. Realmente está en todas partes.

Andy Tanenbaum es profesor de ciencias informáticas y autor de Computer Networks. Y un dato divertido: también es el creador de MINIX, una versión gratuita de UNIX de código abierto, que luego inspiró a Linus Torvalds a crear Linux, de hecho. Y sí, Andy escribió MINIX en C.

Hoy en día, C está en cada rincón de nuestras vidas, desde los róvers de Marte hasta los navegadores de nuestras computadoras de escritorio. Ha influido en muchos de los lenguajes que vimos esta temporada, como Go, JavaScript y Perl. Y gracias a su estrecho vínculo con UNIX, C muy probablemente sea el lenguaje más presente en todo el mundo.

Los ganadores de la Medalla Nacional de las Ciencias de 1998: el equipo de Kenneth L. Thompson y Dennis M. Ritchie, de Bell Laboratories, Lucent Technology.

Allá por la década de 1960, los cuatro empleados de Bell Labs —Ken Thompson, Dennis Ritchie, Doug McIlroy y J.F. Ossanna— tuvieron que suplicar que les dieran un poquito de reconocimiento y financiamiento. Pero en 1998, Thompson y Ritchie recibieron la Medalla Nacional de Ciencias de los Estados Unidos por su trabajo en C y UNIX. También compartieron el premio Turing de un millón de dólares. Nada mal.

Durante toda la temporada, hemos seguido los movimientos y la magia de algunos de nuestros lenguajes de programación favoritos. Ya sea que comenzaran ligados a un sistema operativo, como C, o que aprovecharan una nueva infraestructura, como Go, hay una constante: los lenguajes tienen vida. Nacen. Crecen, maduran. A veces, envejecen y mueren. Cuanto más aprendemos sobre ellos, más claro nos queda que son fuerzas vitales que están en constante cambio para adaptarse a los tiempos. Nuestro trabajo es percibir ese cambio y responder del mismo modo. Nuestros lenguajes a menudo son las mejores herramientas que tenemos para construir el mundo que queremos.

Así termina la tercera temporada de Command Line Heroes en español, un podcast original de Red Hat. Espero que hayas disfrutado esta temporada tanto como nosotros disfrutamos prepararla. La cuarta temporada ya está en proceso, y pronto tendrás noticias.

Hasta la próxima, sigan programando.