La raíz de la programación

¿Te suena Star Travel?

¿Es una simulación por ordenador?

¿Qué dices? Es un juego que lo petó en 1969.

¿Un juego? ¿Y de qué se supone que va?

Hay que estar muy metido en el juego para entenderlo.

¡Qué nerd suena eso!

Lo hizo un gran programador barbudo.

Pero si la mayoría tienen barba. ¿A cuál te refieres?

Ken Thompson.

Mmm... Me suena haberlo visto en una foto a la derecha de un chico serio. ¿Es el sonriente?

No, ese es Dennis Ritchie.

Ahora que lo dices, me suena mucho sus nombres. ¿Estos no fueron los creadores de UNIX?

Exacto, pero no solo eso.

¡Ah! Los creadores del lenguaje C. No me digas que hicieron todo esto por un juego.

Pues no te lo digo.

Vale, ¿cómo fue la historia?

Antes de continuar, un inciso. ¿Te gustaría apoyar a nuestro canal? No olvides que puedes suscribirte y activar la campanita para no perderte futuro contenido. También se agradecen me gustas. Y además, si nos prefieres en formato podcast, podemos acompañarte desde Spotify. Ahora sí, continúa.

Pues en principio, en los años 60, la computación se hacía a través de unas máquinas enormes llamadas mainframes.

¿Hablas de esos computadores que ocupaban toda la habitación y parecían armarios?

Sí. En esos computadores comenzaron a hacerse populares los sistemas operativos de tiempo compartido.

¿Cómo que de tiempo compartido?

Sí, son sistemas operativos que permiten ejecutar varias tareas de forma concurrente.

¿Concurrente? ¿Vamos a volver a hablar de gofers?

Pues es curioso que lo digas porque Ken Thompson fue uno de los creadores de Go, pero no, no hablaremos de gofers hoy.

¡Aww!

No hablaremos de gofers, pero sí, la idea es la misma. El sistema operativo mantiene un registro de los programas en ejecución y divide el reloj en una serie de fragmentos asignándole cada porción de tiempo a un programa. De esta forma todos pueden trabajar.

Ajá, y como la máquina es rápida haciendo esa tarea da la sensación de que todas las tareas se hacen al mismo tiempo.

Sí, se crea esa ilusión.

Así que los usuarios se conectaban a estos mainframes para trabajar, Pero, ¿cómo lo hacían?

A través de unos terminales. Cada mainframe podía tener varios usuarios conectados y cada uno empleaba parte de la potencia de ese computador, abaratando costes.

Muy inteligente. Pero, ¿qué tiene que ver esto con el juego que comentábamos?

Como decía, el juego lo petó en 1969. Llegó a tener algo más de 100 usuarios jugando en el mismo computador a través de estas terminales.

Jaja, petarlo para ti es solo ¿100 jugadores?

¡Ey! Algo más de 100, pero teniendo en cuenta que era un juego en 1969, uno de los primeros, tuvo muchos jugadores. No había aún ordenadores personales.

Vale, un juego con más de 100 jugadores, lo aceptamos como juego blockbuster, ¡todo un triple A!

¡Ey! Debido a este furor por jugar, los directivos de Bell les dieron un toque a los trabajadores. ¡Nada de jugar con el computador principal!

Bueno, y no es para menos. Anda que jugar en el trabajo...

Claro, jugar en el trabajo nunca se ha visto. Billar, futbolín... ¿Videoconsolas? No, eso no se hace.

Bueno, vale, tienes razón. La gente juega en el trabajo. ¿Qué hicieron para poder seguir jugando?

Pues como la restricción no era acerca de jugar, sino tan solo acerca de utilizar el computador principal, se hicieron con uno de los computadores que ya no se empleaban tanto para poner el juego.

¿Solo eso? Pues vaya una gran historia.

Creo que no has entendido aún el problema.

¿Qué problema? ¿Instalar el juego en el otro ordenador no era sencillo?

Pues la verdad es que no. Los computadores muchas veces no tenían la misma arquitectura, incluso siendo de la misma compañía.

Pero el creador del juego trabajó en Bell, tenían el código fuente. ¿No pudieron compilar en el nuevo computador?

Había 3 problemas que encontraron por el camino. El sistema operativo. En principio debían adaptar el sistema operativo y como la máquina no era tan potente debían simplificar el sistema operativo.

¿Dices que debían reescribir el sistema operativo? Uf, suena complicado.

Afortunadamente empleaban un sistema operativo hecho por ellos mismos, un Multics.

Multics, me suena. Fue llamado así por ser multiusuario, ¿no?

Sí, también multiprograma, por eso de que podía ejecutar muchos programas de forma concurrente.

Vale, entonces, ¿tomaron el código y lo recortaron?

No, en lugar de eso lo simplificaron. Tomaron los mismos conceptos pero simplificaron muchos de ellos para hacerlos asequibles al nuevo computador.

Eso es bueno. Tuvieron entonces un Multicsimple.

De hecho, les hizo gracia la simplificación y aunque seguía siendo multiusuario y multiprograma Por hacer la broma lo llamaron UNIX.

Muy nerd, pero me suena ese sistema. ¿No es en el que se basan todos los BSD y Linux actuales?

Es la raíz, sí.

Vale, entonces me estás diciendo que por querer jugar a un juego, que por cierto ni se entiende bien, crearon un sistema operativo.

En verdad no pudieron crearlo.

No, pero se acaba de decir que necesitaban una versión simple del sistema operativo.

Pero es que surgió otro problema más: el lenguaje de programación. Multics se escribió principalmente en ensamblador. Escribir así es un dolor, toma mucho tiempo.

Ya me imagino, uff. ¿Qué hicieron entonces?

Convertir el código ensamblador de Multics a una versión simplificada del lenguaje B.

¿El lenguaje B? No me suena.

Eso es porque no has leído aún la historia del lenguaje B que viene en el libro de Historia de los Lenguajes de Programación de Altenberger.

¡Ahhh!

¿Incluye la historia de este lenguaje?

No solo este. Tiene 28 lenguajes de la década de 1960, entre los que destacan BASIC, ALGOL, FORTRAN, COBOL, LISP... y por supuesto BCP/L y B, que son los lenguajes hechos en los laboratorios Bell.

Vale. Tradujeron Multics al lenguaje B y así se libraron del lenguaje ensamblador. ¿Qué pasó después?

Pues que el lenguaje B no tenía todas las herramientas necesarias para construir un sistema operativo.

Pero este era un lenguaje creado en los laboratorios Bell y por ellos mismos. ¿Lo simplificaron también? ¡Exacto!

La filosofía tras el nuevo lenguaje era que cada sentencia se pudiese traducir en muy pocas instrucciones de ensamblador y así tener un control muy preciso del código.

¿No sería este lenguaje el lenguaje C?

¡Por supuesto! Lo llamaron lenguaje C como el lenguaje que sigue a B.

Muy nerd. Aunque el lenguaje C me suena. ¿No fue la base del lenguaje C++?

Realmente este lenguaje terminó siendo tan buena idea que muchos otros lo utilizaron posteriormente y muchas décadas más tarde como base. Los usos del lenguaje C.

¿Que lo usaron como base? ¿Dónde?

¿Sabes en qué lenguaje está hecho Ruby?

¿En C?

¡Premio! ¿Y Python?

¿En C también?

¡Doble! ¿Y PHP?

¿En C?

¡Vamos para bingo! Y aún más difícil aún... ¿Java?

¡No me digas! ¿También en C?

En realidad esta es una pequeña parte en C y otra en C++.

Entonces, ¿la base de todos los lenguajes actuales está hecha en C?

Hay pocos que estén escritos en otros lenguajes. Por ejemplo, los lenguajes que tratan de ser un sucesor de C intentan autocompilarse a sí mismos.

¿Cómo es esto posible?

El lenguaje C también lo hace. Se hace a través de una pequeña porción del compilador específicamente diseñada para compilar la base del compilador, y una vez se tiene esta pequeña base, entonces ya se puede compilar el resto del compilador.

Suena a singularidad.

¡Sí, menudo trabalenguas!

Es verdad, pero no nos desviemos. Con estos elementos, ¿ya así consiguieron todas las herramientas necesarias y pudieron tener su juego para sus tiempos muertos?

Sí, completaron su misión. Después de crear su propio sistema operativo UNIX, su propio lenguaje C y portar sus juegos a este sistema y lenguaje, ya pudieron jugar. Y no solo eso, utilizaron estas herramientas de forma cotidiana.

Así que cada vez que veían que faltaba algo en su entorno de juegos, lo creaban.

Y gracias a esta práctica consiguieron hacer crecer de forma orgánica el sistema UNIX y el lenguaje C. Vaya, vaya, vaya, ¿cómo puede crecer un proyecto por una Hay muchos proyectos que surgieron de esta forma, como Slack. Era la herramienta de comunicación interna de la empresa y cuando su producto principal fracasó decidieron tomar como producto su sistema de comunicación.

Oye, ¿y también pasó esto con Git? Tengo entendido que Torvalds necesitó un sistema de control de versiones versátil y, por una serie de motivos diferentes, tuvo que crear Git para poder trabajar de forma distribuida con el código de Linux.

Ese es otro buen ejemplo. E incluso Torvalds es un buen ejemplo de uso del lenguaje C.

¿El kernel de Linux está escrito en C? ¿No en ensamblador?

Sí, Linux está escrito principalmente en C, aunque como es lógico tiene un bootstrap, un código inicial escrito en ensamblador.

Y digo yo, si emplea C, ¿no podría utilizar también C++?

Torvalds no se destaca por sus buenas palabras cuando tocas temas que le exasperan. C++ es uno de estos temas y responde siempre de forma grosera. Considera a C++ un lenguaje que genera mucha basura, un código ineficiente y en realidad no le gusta nada la orientación a objetos.

Pero Rust ha hecho su aparición en Linux. ¿Este lenguaje no les costó agregarlo al proyecto entonces? ¿Es mejor que C++?

Rust es mejor que C++ para el bajo nivel, pero Tollefors no anda muy convencido de momento, solo se puede emplear para construir módulos, y creo que de momento no hay ningún módulo oficial en el kernel escrito en Rust.

Pero entró, es decir, Rust está ya dentro del kernel, aún sin existir código, está la posibilidad, solo queda que demuestre su valía y poco a poco se irá haciendo hueco, ¿no?

Es posible, quizás hablemos de Rust en otro capítulo. De momento creo que ya quedó claro lo que queríamos decir acerca de C. ¿No? Conclusiones. El lenguaje C es la base de mucho software escrito hoy en día. De hecho, muchos de los lenguajes actuales como Perl, Python, Ruby, PHP, Erlang, Java y muchos otros no podrían existir sin C.

Podemos considerar al lenguaje C como la raíz de la programación actual, pero ¿crees que vale la pena aprender a programar en C hoy en día?

¿Tiene sentido que sigan intentando buscar un sucesor para el lenguaje C?

Déjanos tu comentario.