¿Alguien vio TRON?

–Y el mundo de las computadoras en las peliculas–

Hay un cierto especial de halloween en los Simpson en el que Homero entra por accidente a un portal que lo conduce a la tercera dimensión (no olvidar que los dibujos animados tradicionales son bidimensionales). Homero se convierte en una animación tridimensional que se mueve por lo que parece un plano cartesiano y aunque no puede ver su propio mundo si puede ser escuchado por otros personajes que aún se encuentran en la segunda dimensión. En cierto momento, cuando le dicen a Homero que describa como es el lugar donde se encuenta este responde:

–¿Alguien vio TRON?– A lo que todos los personajes solo hacen expresión de no saber de lo que está hablando, excepto el Jefe Gorgori (el policía) que hace una mueca que sugiere que el fue el único que recuerda haber visto la película.

Y bien, esta nota aunque toca mucho el tema de la película TRON en realidad es sobre programación. Pues en Tron fue donde por primera vez vi como se representaban de forma mas o menos entendible por humanos muchos conceptos computacionales que no tienen representación en la realidad. Otra película que maneja esto bastante bien es Matrix, pero como Matrix es al Cyberpunk lo que Twilight es al mito de los vampiros (una representación muy bonita de algo que en su origen era horroroso) mejor me quedo con Tron que ya viene endulcorada de fabrica por los estudios disney.

Para empezar, tengo la teoría de que el nombre Tron tiene algo que ver con el viejo intérprete GW-BASIC de Microsof que contaba con un par de comandos para depuración llamados TRON y TROFF. Que era la abreviatura de Trap ON / Trap OFF. Nada que ver con el famoso IT’S A TRAP!!!. Estos comandos se usaban para detectar errores en el programa. Ahora regresando al tema de la programación, en la película se representaba la computadora como una especie de enorme fortaleza habitada por entidades humanoides que la mantenían en pie cual si se tratara de una tripulación de un barco o los obreros de una fábrica. Estas personitas eran los programas. Y aquí es donde comienza lo interesante, pues no todos los programas eran exactamente iguales. Unos se les veía trabajando directamente con las instalaciones mientras que otros daban órdenes a otros desde lo que parecían ser puestos de control. Otros tantos manejaban lo que parecían ser teminales montadas en las paredes de la fortaleza. Todo esto no parece tener mucha importancia para alguien no iniciado en computación (entre los que se cuentan aquellos que le buscan filosofía profunda a Matrix) pero si tomamos en cuenta que una computadora tiene tanto programas que controlan directamente el hardware (los drivers o módulos), que hay un nucleo principal del sistema operativo y que hay en medio una gran cantidad de programas que interactuan de modo jerárquico como sucede en una fábrica. Esta es la perfecta representación antropomorfa de como funciona un sistema de computación mas o menos elaborado. Por cierto, de seguro la computadora de Tron fuera algún tipo de servidor con capacidades multitarea y multiusuario probablemente unixoide.

Por otra parte las terminales repartidas por las paredes que aparecen en Tron representan los servicios del sistema operativo, llamadas API, interrupciones o como cada quien quiera llamarles, cuando algun programa resultaba herido mandaba una señal de auxilio igual que los verdaderos programas envian códigos de error cuando no terminan adecuadamente. Un par de personajes que no podían comunicarse con frases complejas y solo podían contestar SI o NO a las preguntas que les realizaban son hasta ahora la mejor representación del sistema de saltos condicionales basados en banderas como el registro EFLAGS de los procesadores intel (esa cosa con la que se dan de narices los ingenuos que buscan como hacer un IF en ensamblador).

Otro tema que manejan bastante bien es el de las subrutinas, y aunque este término es original de los tiempos del BASIC se trata de un concepto que existe en todos los lenguajes de programación pero con diferente nombre: en ASM se le llama proceso, en C función, en Java método y se le llamará con otros nombres conforme nuevos lenguajes se pongan de moda. Aunque tengo que admitir que el término subrutina es el mejor de todos pues en su nombre describe que se trata de un proceso que en si mismo no es un programa. En Tron las subrutinas son los componentes que les dan a los programas que habitan en la computadora nuevas capacidades e incluso pueden combinarse entre si para formar tanto nuevas armas y herramientas como darles aumentar las cosas que un programa puede hacer.

El tema de la integridad y la seguridad de la información también se toca en Tron, pues las subrutinas integradas en los programas pueden corromperse o ser alteradas deliveradamente por virus informáticos. Y el hecho de que cuando uno de los programas moría o como dicen en la película, le hacían “derez” por un momento podían verse números sin significado que es exactamente en lo que se convierte un programa en memoria cuando ya ha dejado de ejecutarse. También se maneja el concepto de “data streams” (los que han leido libros sobre UNIX saben de lo que estoy hablando) que se representaban como ráfagas de componentes luminosos que se movían de aquí para allá por todas partes.

Por supuesto no podía faltar la famosa escena de las carreras de motos (light cycles para los mas geeks). En la película se trataba de una especie de carrera entre motocicletas que no podían detenerse y que dejaban tras de si una especie de pared de luz en la que no solo podían estrellarse los demás corredores sino incluso el mismo que la había creado. (si, ahora saben de donde salió la inspiración para ese viejo juego de la viborita que venía en los celulares antiguos). Exactamente esta misma situación es la que ocurre dentro de un sistema operativo multitarea cuando se tienen una gran cantidad de aplicaciones que tratan de tener acceso a los recursos. Pues al igual que las motos de Tron los programas no se pueden detener (sin consecuencias) y continuamente se disputan los recursos del sistema. Por lo que es necesario saber sincronizarlos bien para evitar que unos intenten usar los recursos que ya están en uso (las cuadros de la pista marcados por la pared luminosa) o de ser posible que el mismo programa sepa como tomar los recursos sin hacer que se caiga todo el sistema. De hecho hay cierto tipo de código malicioso que hace exactamente lo que los corredores tramposos de Tron hacían al tratar de bloquear los recursos usados por otros programas para hacer que el sistema entero se colapsase.

Bueno, ya hablé demasiado de la película Tron por hoy. Ya para terminar lo que quiero decir en esta entrada es sobre el tema de las abstracciones. Si miramos dentro de una memoria de computadora no vamos a ver otra cosa mas que un mas de números iguales a los que nos da un editor hexadecimal y si acaso algunos viejos CPU’s anteriores a la época de los 8 bits son visibles con potentes instrumentos ópticos. Pero si a partir de los datos creamos una imagen de las entidades digitales el resultado es muy similar a lo que se veía en Tron. De hecho es exactamente lo que ocurre con las gráficas por computadora que se representan de manera visual a partir de simples datos digitales sin forma. Sin embargo, parece que en esta época el razonamiento es inverso, pues hasta hace poco para aprender a programar era necesario saber como representar esos números aparentemente sin sentido en una imagen mental comprensible hoy en día las computadoras ya nos brindan esa representación antropomorfa y de apariencia visual física y para aprender a programar es necesario ser capaz de ver los números detrás de estas imágenes, tal y como Neo hacía al final de la primer película de Matrix, que fuera de todas mis burlas a este Cyberpunk suavizado es una de las mejores escenas que he visto relacionadas con películas sobre computadoras. Aunque de nuevo entran aquí los fanáticos que se espantan al ver una linea de comando y se ponen a inventar teorías raras sobre este tipo de escenas.

Volviendo al mundo del ensamblador, estoy en una posición de que ya poder terminar el primer reto de Poor Programmer pero necesitaría una semana de trabajo continuo de la que actualmente no dispongo. Puede que en estos días no tenga ocasión de escribir tanto como quisiera en este blog pero el ritmo de las notas volverá terminando este mes. Esto es lamentable porque tengo muchas cosas que me gustaría contarles con esto de la programación en ASM.