Si te gusta el té fuerte, he aquí un simple consejo: no le pongas azúcar o leche hasta que el té se haya disuelto por completo. Esto favorecerá que el agua tenga menos soluto, permitiéndole así disolver más cantidad de té.

Nostalgia - Los programadores de verdad no usan Pascal

Me he reencontrado recientemente con este texto en mis archivos. Releerlo ha sido una experiencia bastante nostálgica. He creído conveniente reproducirlo en versión castellana. La versión inglesa está todavía disponible en línea, así que ofrezco aquí mi traducción. Parece ser que fue publicado en 1983. Helo aquí en toda su gloria:

Los Programadores de Verdad No Usan Pascal

En los buenos tiempos, la "Edad de Oro" de los ordenadores, era fácil separar a los hombres de verdad de los críos (a veces en la literatura se les ha llamado "Hombres de Verdad" y "Comedores de Pastelitos"). Durante ese periodo, los Hombres de Verdad eran los que comprendían la programación de ordenadores y los Comedores de Pastelitos eran los que no. Un auténtico programador de ordenadores decía cosas como:

  DO 10 I = 1, 10

y

  ABEND

Hablaban en mayúsculas, ya me entienden. El resto del mundo decía cosas como "los ordenadores son demasiado complicados para mí", y "no puedo relacionarme con ordenadores: son tan impersonales...". Un escrito anterior (1) puntualiza que los Hombres de Verdad no se relacionan con nada, y no temen ser impersonales. Pero, como suele pasar, los tiempos cambian. Hoy nos enfrentamos a un mundo en el que las señoras tienen ordenadores en su horno de microondas, los niños de 12 años pueden vencer a los Hombres de Verdad jugando al Asteroids o al Pac-Man, y cualquiera puede comprar y comprender su propio ordenador personal. El Programador de Verdad está en peligro de extinción, en peligro de ser reemplazado por estudiantes universitarios con Commodores y Ataris. Hay una clara necesidad de puntualizar las diferencias entre un típico jugador junior de Pac-Man de universidad y el Programador de Verdad. Si se aclara esta diferencia, les dará a esos muchachos algo a lo que aspirar - un modelo, una figura paterna. También ayudará a explicar al que tenga contratado a un Programador de Verdad por qué sería un error reemplazar a los Programadores de Verdad de su plantilla por jugadores-de-PacMan-de-12-años (que le suponen un ahorro considerable).

1.1 Lenguajes

La forma más fácil de distinguir a un Programador de Verdad del resto es por el lenguaje de programación que él o ella usa. Los Programadores de Verdad usan Fortran. Los Comedores de Pastelitos usan Pascal. Nicklaus Wirth, el diseñador del Pascal, dio una conferencia una vez en la que le preguntaron: "¿Cómo pronuncia usted su nombre?" El respondió: "Pueden llamarme por mi nombre, pronunciándolo 'Virt', o pueden llamarme por mi valor, 'Worth'" [valioso, merecedor - N.del T.]. Enseguida se deduce de ese comentario que Nicklaus Wirth es un Comedor de Pastelitos. El único mecanismo de pase de parámetros que usan los Programadores de Verdad es la "llamada por valor - retorno", como se implementa en los compiladores de FORTRAN G y H del IBM/370. Los Programadores de Verdad no necesitan todos esos conceptos abstractos para hacer su trabajo: son perfectamente felices con un teclado perforador, un compilador FORTRAN IV, y una cerveza.

• Los Programadores de Verdad realizan Proceso de Listas en FORTRAN.
  [N.del T.: Proceso de Listas = List Processing, de donde viene el nombre del lenguaje de programación LISP]
• Los Programadores de Verdad realizan Manipulación de Cadenas en FORTRAN.
• Los Programadores de Verdad hacen Contabilidad (si es que la hacen) en FORTRAN.
• Los Programadores de Verdad hacen programas de Inteligencia Artificial en FORTRAN.

Si no puedes hacerlo en FORTRAN, hazlo en Lenguaje Ensamblador, o no merecerá la pena hacerlo.

1.2 Programación Estructurada

Los académicos de la ciencia de computación se han hecho esclavos de la "Programación Estructurada" durante los últimos años. Afirman que los programas son más fácilmente comprensibles si el programador utiliza ciertas construcciones especiales del lenguaje, por supuesto, y los ejemplos que usan para mostrar su punto de vista caben invariablemente en una sola hoja de alguna que otra oscura publicación, ejemplo claramente insuficiente para convencer a nadie. Cuando salí de la escuela, pensaba que era el mejor programador del mundo. Podía escribir un programa invencible de tres en raya, usar cinco lenguajes de ordenador diferentes, y crear programas de 1000 líneas que funcionaban (¡de verdad!). Entonces salí al Mundo Real. Mi primer trabajo fue leer y comprender un programa en FORTRAN de 20.000 líneas, para acelerarlo al doble de su velocidad. Cualquier Programador de Verdad te dirá que toda la Programación Estructurada del mundo no te ayudará a solucionar un problema como ese: requiere auténtico talento. Algunas observaciones a bote pronto sobre los Programadores de Verdad y la Programación Estructurada:

• Los Programadores de Verdad no temen usar GOTO.
• Los Programadores de Verdad pueden escribir bucles DO de cinco páginas sin confundirse.
• Los Programadores de Verdad disfrutan con las sentencias IF aritméticas: hacen el código más interesante.
• Los Programadores de Verdad escriben código automodificable, especialmente si pueden ahorrar 20 nanosegundos en mitad de un bucle crítico.
• Los Programadores de verdad no necesitan comentarios: el código es obvio.

Aunque el FORTRAN no tiene sentencias IF, REPEAT...UNTIL ni CASE estructuradas, los Programadores de Verdad no se preocupan por no poder usarlos. Además, todas esas estructuras pueden ser simuladas mediante GOTOs cuando es necesario.

Las estructuras de datos también han recibido mucha atención últimamente. Los Tipos Abstractos, Estructuras, Punteros, Listas y Cadenas se han hecho muy populares en ciertos círculos. Nicklaus Wirth (el antes mencionado Comedor de Pastelitos) ha conseguido escribir todo un libro (2) defendiendo que se puede escribir un programa basándose en Estructuras de Datos en lugar de todo lo habitual. Como todos los Programadores de Verdad saben, la única estructura de datos útil es el ARRAY. Las cadenas, listas, estructuras, conjuntos... son sólo casos especiales de Arrays y pueden ser tratados de esa forma fácilmente sin necesidad de ensuciar el lenguaje de programación con todo tipo de complicaciones. Lo peor sobre los tipos de datos bonitos es que tienes que declararlos, y todos los Lenguajes de Programación de Verdad, como todos sabemos, tienen tipos implícitos basados en la primera letra del nombre (de seis caracteres) de la variable.

1.3 Sistemas Operativos

¿Qué tipo de sistema operativo usa el Programador de Verdad? ¿CP/M? Por favor, el CP/M, después de todo, es básicamente un sistema operativo de juguete. Hasta las señoras respetables y los estudiantes de primaria pueden usar y entender el CP/M. El UNIX es mucho más complicado, por supuesto: el típico hacker de UNIX nunca es capaz de recordar cómo se llama el comando de imprimir esta semana. Cuando se le conoce bien, el UNIX no es sino un video juego glorificado. La gente no hace trabajo serio en sistemas UNIX: envían chistes por el mundo a través de una red UUCP, y escriben juegos de aventuras y artículos de investigación. No, el Programador de Verdad usa OS/370. Un buen programador puede encontrar en el manual del JCL y comprender la descripción de un mensaje de error IJK3051 que acaba de aparecerle. Un gran programador puede escribir JCL sin recurrir al manual del JCL en absoluto. Un programador realmente bueno puede encontrar bugs enterrados en un volcado hexadecimal de seis Megabytes sin usar una calculadora hexadecimal. El OS/370 es un sistema operativo realmente destacable. Es posible destruir días de trabajo con un simple espacio fuera de lugar (nos ocurre hasta a los mejores), así que se favorece la alerta entre el personal de programación. La forma de acercarse más al sistema es mediante un teclado perforador. Hay gente que afirma que hay un sistema de Compartición de Tiempos que funciona en OS/370, pero tras un cuidadoso estudio he llegado a la conclusión de que estaban equivocados.

Referencias:

(1) Fierstein, B., Real Men Don't Eat Quiche, New York, Pocket Books, 1982
(2) Wirth, N., Algorithms+Data Structures=Programs, Prentice Hall, 1976

1.4 Herramientas de Programación

¿Qué tipo de herramientas usa un programador de verdad? En teoría, un programador de verdad podría ejecutar sus programas tecleándolos en el panel frontal de un ordenador. En los tiempos en los que los ordenadores tenían paneles frontales, esto se hacía en alguna ocasión. El típico programador de verdad se conocía de memoria la rutina de arranque en hexadecimal, y la reemplazaba cuando su programa destruía el arranque. Por entonces, la memoria era memoria: no se iba al quitar la alimentación. Hoy, la memoria bien olvida cosas que no quieres, o recuerda demasiado tiempo lo que sería mejor olvidar. Dice la leyenda que Seymour Cray (el inventor del superordenador Cray-1 y la mayoría de los ordenadores de Control Data) tecleó el primer sistema operativo del CDC-7600 en el panel frontal de memoria la primera vez que fue puesto en marcha. Seymour, por supuesto, es un programador de verdad.

Uno de mis programadores de verdad favoritos era un programador de sistemas de Texas Instruments. Un día, recibió una llamada de larga distancia de un usuario cuyo sistema se había venido abajo a mitad de salvar un trabajo importante. Jim fue capaz de reparar el daño por teléfono, consiguiendo que el usuario metiera las instrucciones de E/S de disco en el panel frontal, reparando las tablas del sistema en hexadecimal, leyendo los contenidos de los registros a través del teléfono. La moraleja de la historia: aunque un programador de verdad normalmente incluye un teclado perforador y una impresora de líneas entre sus herramientas, puede desenvolverse bien con sólo un panel frontal y un teléfono en caso de emergencia.

En algunas compañías, la edición de textos ya no consiste en diez ingenieros esperando en fila para usar un teclado perforador 029. De hecho, el edificio en que trabajo no tiene ni un solo teclado perforador. El programador de verdad, al verse en esa situación, tiene que trabajar con un programa de edición de textos. La mayoría de los sistemas proporcionan varios editores de textos entre los que seleccionar, y el programador de verdad debe tener cuidado de elegir el que más refleja su estilo personal. Mucha gente cree que los mejores editores de texto del mundo se escribieron en el Centro de Investigación Xerox de Palo Alto para usarse en sus ordenadores Alto y Dorado (3). Por desgracia, ningún programador de verdad usaría un ordenador con un sistema operativo llamado SmallTalk, y desde luego nunca le hablaría a un ordenador con un ratón.

Algunos de los conceptos de esos editores de Xerox han sido incorporados en editores que funcionan en sistemas más razonables, por ejemplo EMACS y VI. El problema con dichos editores es que los programadores de verdad consideran que "lo que ves es lo que hay" [también llamado WYSIWYG - N.del T.] es un concepto tan malo aplicado a los editores como lo es aplicado a las mujeres. No, el programador de verdad prefiere un editor tipo "tú lo has pedido, ahí lo tienes": complicado, críptico, potente, inolvidable, y peligroso. TECO para ser preciso.

Se ha observado que una secuencia de comandos de TECO se parece más al ruido de transmisión de línea que a texto legible (4). Un entretenido juego que se puede jugar con TECO es escribir tu nombre en la línea de comandos e intentar adivinar lo que hará. Casi cualquier error de escritura durante la comunicación con TECO destruirá probablemente tu programa, o aún peor, introducirá bugs misteriosos y sutiles en una subrutina que antes funcionaba.

Por esta razón, los programadores de verdad se muestran recelosos a la hora de editar un programa que está próximo a funcionar. Encuentran mucho más fácil editar el código objeto en binario directamente, usando un maravilloso programa llamado SUPERZAP. Este sistema funciona tan bien que muchos programas en funcionamiento en sistemas IBM no mantienen relación alguna con su código FORTRAN original. En muchos casos el código fuente original ya no está disponible. Cuando llega el momento de modificar un programa como ese, ningún director pensaría siquiera en enviar a cualquiera que no fuera un programador de verdad para hacer el trabajo. Ningún Programador Estructurado Comedor De Pastelitos sabría siquiera por dónde empezar. A esto se le llama Seguridad del Puesto.

He aquí algunas herramientas de programación que los programadores de verdad no usan:

• Preprocesadores de FORTRAN como MORTRAN o RATFOR. Son como las cocinas de la programación: ideales para hacer pastelitos. Ver arriba los comentarios sobre programación estructurada.
• Debuggers de Código Fuente. Los Programadores de Verdad pueden leer volcados hexadecimales.
• Compiladores con chequeo de límite en arrays. Ahogan la creatividad, destruyen la mayoría de los usos interesantes de la sentencia EQUIVALENCE, y hacen imposible modificar el sistema operativo mediante subíndices negativos. Y lo peor de todo, el chequeo de límite es ineficiente.
• Sistemas de mantenimiento de código fuente. Un programador de verdad mantiene su código cerrado con llave en un fichero de tarjetas, porque eso implica que el dueño no puede dejar programas importantes al descubierto (5).

(3) Xerox PARC Editors...
(4) Finseth, C. Theorey and Practice of Text Editors - or A Cookbook for an EMACS, B.S. Thesis, MIT/LCS/TM-165, Massachusetts Institute of Technology, May 1980.
(5) Weinberg, G. The Psychology of Computer Programming, New York, Van Nostrand Reinhold, 1971, p. 110.

1.5 El Programador de Verdad en el trabajo

¿Dónde trabaja el típico programador de verdad? ¿Qué tipo de programas merecen los esfuerzos de un individuo con tanto talento? Puede estar seguro de que no encontrará a ningún programador de verdad escribiendo programas de contabilidad en COBOL, u ordenando listas de correo para la revista People. Un programador de verdad quiere tareas de una importancia que haga temblar la tierra (¡literalmente!).

Hay Programadores de Verdad trabajando para el Laboratorio Nacional de Los Alamos escribiendo simulaciones de bomba atómica para superordenadores CRAY-1. Hay Programadores de Verdad trabajando para la Agencia de Seguridad Nacional, decodificando transmisiones rusas.

Fue gracias sobre todo al esfuerzo de miles de Programadores de Verdad que trabajaban para la NASA que los americanos llegaron a la luna antes que los rusos. Hay Programadores de Verdad trabajando para Boeing, diseñando sistemas operativos para misiles crucero.

Algunos de los más puros Programadores de Verdad de todos trabajan en el Jet Propulsion Laboratory de California. Muchos de ellos se saben el sistema operativo completo de las naves Pioneer y Voyager de memoria. Con la ayuda de grandes programas en FORTRAN desde tierra y pequeños programas en ensamblador desde la nave espacial, son capaces de hacer increíbles hazañas de navegación y de previsión: acertar en ventanas de diez kilómetros de anchura en Saturno tras seis años en el espacio, reparar o prescindir de plataformas sensoras, radios o baterías dañadas. Se cuenta que un programador de verdad consiguió meter un programa de comparación de patrones en unos cuantos cientos de bytes de memoria no usada en una nave espacial Voyager que buscó, localizó y fotografió una nueva luna de Júpiter. Los planes actuales de la nave espacial Galileo son usar una trayectoria asistida por gravedad a través de Marte en su camino hacia Júpiter. Esta trayectoria pasa a 80 más menos 3 kilómetros de la superficie de Marte. Nadie va a confiar en un programa en Pascal (o en un programador de Pascal, para el caso) para navegar con esas tolerancias.

Como puede imaginar, muchos de los Programadores de Verdad del mundo trabajan para el Gobierno americano, sobre todo en el Departamento de Defensa. Así es como debe ser. Desde hace poco, sin embargo, se ha formado una nube negra en el horizonte de los Programadores de Verdad. Parece que algunos Comedores de Pastelitos con un puesto importante en el Departamento de Defensa decidieron que todos los programas de Defensa deberían ser escritos en un gran lenguaje unificado llamado ADA. Durante un tiempo parecía que el ADA estaba destinado a convertirse en un lenguaje que iba contra todos los preceptos de la programación de verdad: un lenguaje con estructura, con tipos de datos, mucho tecleo, y puntos y comas. En definitiva, un lenguaje diseñado para inutilizar la creatividad del típico programador de verdad. Por suerte, el lenguaje que adoptaron tenía las suficientes cualidades como para hacerlo aprovechable: es increíblemente complejo, incluye métodos para cargarse el sistema operativo y reposicionar memoria, y a Edsger Dijkstra no le gusta (6). Dijkstra, como seguramente ya sabrá, es el autor de "el Go To considarado peligroso", que marcó época en la metodología de programación y fue aplaudido por programadores en Pascal y comedores de pastelitos. Y de todas formas, un programador de verdad puede escribir programas FORTRAN en cualquier lenguaje.

Los Programadores de Verdad podrían comprometer sus principios y trabajar en algo ligeramente más trivial que la destrucción o la vida, si hay suficiente dinero implicado. Hay varios programadores de verdad escribiendo video juegos en Atari, por ejemplo (pero no jugando a ellos: un programador de verdad sabe cómo ganar en cualquier momento; eso no es un reto para ellos). Todos los de LucasFilm son programadores de verdad (sería de locos rechazar el dinero de cincuenta millones de fans de Star Trek). La proporción de programadores de verdad en gráficos por ordenador es ligeramente menor de lo normal, sobre todo porque nadie les ha encontrado un uso a los gráficos por ordenador todavía. Por otra parte, toda la programación de gráficos por ordenador está hecha en FORTRAN, así que hay cierto número de ellos dedicados a los gráficos sólo para evitar escribir programas en COBOL.

1.6 El Programador de Verdad Jugando

Generalmente, el programador de verdad juega de la misma forma que trabaja: con ordenadores. El programador de verdad está constantemente asombrado de que su jefe le pague por lo que él haría de todas formas (aunque tiene cuidado de no expresar esta opinión en voz alta). Ocasionalmente, un programador de verdad sale fuera de la oficina a tomar un respiro de aire fresco y una cerveza o dos. He aquí algunas pistas para reconocer a los programadores de verdad fuera de la sala de ordenadores:

• En una fiesta, los programadores de verdad son los que están en la esquina hablando sobre seguridad de sistemas y cómo saltársela.
• En un partido de fútbol, el programador de verdad es el que compara las jugadas con la simulación impresa en papel continuo de 11 por 14.
• En la playa, el programador de verdad es el que está dibujando diagramas de flujo en la arena.
• En un funeral, el programador de verdad es el que dice "Pobre George. Y eso que casi había conseguido hacer que su rutina de ordenación funcionara antes de su coronaria".
• En la tienda de ultramarinos, el programador de verdad es el que insiste en pasar él mismo las latas por el lector de barras, porque nunca confiaría en que un operador de teclado perforador lo hiciera bien la primera vez.

Piloto automático para naves espaciales

Algún afortunado lector quizá haya jugado con el sensacional Elite de Ian Bell y David Braben. o sus aún más sensacionales continuaciones, Elite II: The Frontier y Frontier: First Encounters. Los tres son simuladores espaciales. El primero no tiene un motor físico muy realista: en Elite, la velocidad no es relativa. Hay un sistema de referencia universal, y la nave tiene una velocidad máxima dentro de ese sistema de referencia.

En cambio, en los otros dos el motor de física es mucho más realista. La velocidad actual está indicada siempre con respecto a un sistema de referencia dado, que generalmente se corresponde con el astro o planeta más próximo, y puede cambiar cuando éste lo hace. Los motores de las naves pueden acelerar y frenar, lo que impone una aceleración máxima, como es lógico, pero no hay limitación para la velocidad. Como pega en contra de ese realismo, aunque a favor de la jugabilidad, cabe nombrar que la aceleración de la nave no depende de la masa de la misma, lo cual sí que ocurriría si los motores ejercieran una fuerza de empuje máxima (F=ma). Otros detalles, aunque de menos importancia, son la falta de efectos relativistas y la omnidireccionalidad del empuje, así como el hecho de que la aceleración a la que la nave es sometida (típicamente rondando los 20 g) no podría ser soportada por un cuerpo humano. Le concedemos esas licencias de buena gana, porque el producto resultante bien lo vale.

Como los dos títulos comparten la palabra Frontier y no hay diferencias entre ellos en la parte que aquí nos interesa, me referiré a ambos colectivamente usando dicha palabra. Frontier cuenta con un piloto automático, cuyo principio de funcionamiento exacto desconozco, para viajar de un punto a otro del espacio. Sin embargo, yo al menos soy fan de desconectar el piloto automático y volar a mano, porque disfruto haciéndolo, y porque el piloto automático utiliza el motor delantero para frenar, que siempre tiene menos potencia, mientras que yo doy la vuelta a la nave para hacerlo y así puedo alcanzar una velocidad mayor y frenar a tiempo. (Es un error típico de novatos el acelerar continuamente hasta llegar al destino... y pasarse de largo por mucho, porque la potencia de frenado es la misma que la de aceleración y por lo tanto requiere el mismo tiempo acelerar que frenar).

Cuando quiero ir de punto a punto, observo la distancia al objetivo; entonces acelero hasta la mitad del trayecto y decelero hasta llegar. Los resultados suelen ser bastante buenos; en la primera aproximación quizá no me quede lo bastante cerca, pero con una o dos aproximaciones más (cada vez más cortas) el éxito está prácticamente garantizado.

Sin embargo, las batallas suelen aparecer en medio del viaje, y cuando lo hacen, me estropean los planes de navegación, porque debido a la inercia que llevo, voy acercándome al objetivo mientras dura la batalla, lo cual, cuando se va a 12.000 km/s, resulta significativo. Esto me hizo preguntarme: ¿y cómo calcular entonces el punto de frenada, para llegar cuanto antes al objetivo? La respuesta resulta no ser muy fácil para el caso de una dimensión. Cuando se da la eventualidad de una batalla, los movimientos laterales son pequeños, lo que permite considerar el caso 1D como una buena aproximación.

El método entonces sería el siguiente. El espacio necesario para frenar dada la velocidad actual viene dado por la fórmula v²/(2a), donde a es la aceleración máxima con la que podemos frenar y v la velocidad con la que se reanuda el viaje. Por razones que me costaría explicar, el punto de frenada viene dado por (x₀ - v|v|/(2a))/2, donde x₀ es el punto inicial, y el punto destino se asume 0. Puede ser que ya nos hayamos pasado de dicho punto, en cuyo caso es inevitable que nos pasemos de largo y tengamos que frenar hasta pararnos.

Pero, ¿qué pasa si estoy de camino hacia un planeta y de repente cambio de opinión y quiero dirigirme a otro? En ese caso, tengo una velocidad inicial cuya alineación probablemente no coincida para nada con el destino final, por lo cual no podemos usar el truco de 1D. ¿Qué puedo hacer, si quiero llegar cuanto antes?

Anticipo que no sé la respuesta. Si para el caso 1D no era fácil, para 3D es diabólico. Esto es lo que sé. Con un cambio de sistema de referencia, siempre se puede transformar el problema en uno en dos dimensiones. Se formularía así: dados un punto inicial, p₀, una velocidad inicial, v₀, y una aceleración máxima, a_max, determinar la función que da la aceleración a aplicar en cada instante, tal que se alcance el punto (0, 0) a velocidad nula en el menor tiempo posible.

O, alternativamente, partiendo parados desde el punto (0, 0), hallar la función de aceleración necesaria para alcanzar el punto p_F a una velocidad v_F (como vector), en el mínimo tiempo posible. Es lo mismo pero haciendo el camino al revés e invirtiendo la velocidad.

Es un problema frustrante porque, pese a su simple planteamiento y aspecto inocente, resulta bastante esquivo. La aproximación más inmediata, que es resolverlo en 1D para cada eje, no funciona porque al aplicar la aceleración máxima por cada eje, el módulo de la aceleración es mayor que la aceleración máxima. Podemos dividir la aceleración por √2 para compensar, pero es que no es la única pega: nada nos garantiza que el tiempo que se tarda en cada eje coincida. Así que tenemos además que encontrar una aceleración máxima por eje, que cumpla dos requisitos: que el tiempo sea el mismo en cada eje, y que la suma de los cuadrados de las aceleraciones máximas coincida con el cuadrado de la aceleración máxima dada.

¿Es óptima esa solución? Pues una de dos: o no lo es, o hay infinitas soluciones óptimas. Para demostrarlo, basta ver que si rotamos el sistema de referencia en el problema original, deberíamos obtener una versión rotada de la solución, cosa que no ocurre. Los cuatro posibles vectores de la solución forman siempre un rectángulo alineado con los ejes.

En fin, ando quebrándome la cabeza con este problema.