El rey Fortran

El Fortran es un lenguaje de programación diseñado en 1954 por un equipo de IBM que lideraba John Backus. Su nombre significa Formula Translator. Fue el primer lenguaje de programación de alto nivel que se impuso comercialmente, la herramienta para evitarse la engorrosa tarea de programar un ordenador en su lengua nativa, el código máquina. Solo los que han programado alguna vez en código máquina calibran la diferencia entre ambos mundos, no tan abismal como la que separa a la literatura de los premios Planeta de los últimos años, pero aun así enorme.

Los modelos de clima están escritos en Fortran. Los algoritmos de los satélites que miden la precipitación desde el espacio, también. La mayor parte del código que está detrás de nuestras herramientas, de los sistemas de información geográfica o de los grandes modelos atmosféricos y oceanográficos; el código de los algoritmos de la física de la Tierra sigue siendo un Fortran que nadie quiere cambiar porque funciona y es rapidísimo.

Llevo más de treinta años programando en Fortran. Como tantos otros, empecé allá en un lejano 1988 con el BASIC de un CPC464 de Amstrad (un bicho que costaba el equivalente a 1300 euros; una fortuna), pero enseguida pasé al Fortran 77 en un VAX de la facultad de ciencias en el que tuvieron a bien abrirme una cuenta (en aquellos días no había muchos interesados y además intentaban atraer a la ciencia a los chicos de BUP de la asociación de astronomía). Desde entonces, he ejecutado programas de Fortran en mi cabeza, en el duermevela, y me he peleado durante días con un trozo de código que debía hacer una cosa y hacía otra. En 1999 programé mi primera red neuronal en ese lenguaje para mi tesis, una red que sigue funcionando tan bien como las actuales. El año pasado publiqué un artículo demostrándolo.

No obstante, mis estudiantes de doctorado fruncen invariablemente el ceño cuando les digo que tienen que aprender Fortran si es que quieren sacar algo de mí. Todo conspira alrededor para que no me hagan caso. Buscan en internet y leen que es una antigualla, que lo que mola ahora es Python o Julia, y que no hay demanda de programadores Fortran en las empresas. Algunos, pobrecitos, hasta me dicen que lo que quieren aprender es Java o Perl porque han visto que algún chiringuito cuñadiero financiado con dinero público da cursos de esas cosas. Se equivocan, invariablemente, pero para cuando quieren darse cuenta ya es tarde y ha pasado un año. No importa. Forma parte de su proceso de aprendizaje. Luego, cuando tienen que adaptar un programa de transferencia radiativa, o un modelo de clima o de tiempo, se arrepienten, pero nunca es tarde para hacer caso a tu director de tesis. Cada generación se cree más lista que las anteriores y su arrogancia es, además de inevitable, buena en el contexto académico. También lo es aprender que la experiencia es un grado.

¿Qué ventajas tiene sobre el lenguaje más usado hoy en las universidades, el Python? Inumerables. En primer lugar, es más rápido, muchísimo más rápido cuando el compilador (gfortran, ifort, etc.) hace su magia. Una gran ventaja es que está diseñado desde el día uno para cómputo numérico pesado: los bucles y los arrays (matrices y vectores) son nativos y se optimizan solos. Otros lenguajes del mismo tipo, como el C, te obligan a gestionar memoria a mano y a escribir tres veces más líneas para hacer lo mismo que Fortran hace en diez. Igual con Python. La cantinela de que «NumPy es casi tan rápido» es una milonga. NumPy está escrito en C, pero una parte crucial de su velocidad proviene de las rutinas de Fortran en las que se apoya para los cálculos más pesados; cuando lanzas operaciones vectorizadas, el grueso del trabajo lo ejecuta ese código nativo heredado de décadas de optimización numérica, mientras Python se limita a ofrecer la interfaz.

Fortran sigue siendo el rey para las cosas serias de la ciencia. El rendimiento en cómputo numérico pesado es brutal, que dicen ahora. Un bucle DO bien escrito en Fortran moderno vuela diez o veinte veces más rápido que el equivalente en Python puro, y sigue siendo entre dos y cinco veces más rápido que el mejor código NumPy/JAX optimizado, porque el compilador sabe exactamente qué estás haciendo con los arrays y puede aplicar vectorización, aliasing analysis y optimizaciones que en Python ni sueñas. Si tienes que hacer millones de bucles DO por segundo —como en, por ejemplo, la microfísica de la precipitación de los modelos de tiempo y clima—, la diferencia es obtener el resultado final en unas pocas semanas o tener que esperar hasta la parusía.

Este lenguaje nunca ha muerto, y ahora que se han inventado la etiqueta de marketing de «ciencia de datos» para lo que no deja de ser informática con estadística de toda la vida, algunos han vuelto su mirada a él. Y es que el Fortran maneja de una manera muy eficiente grandes volúmenes de información. Puedes tener arrays de cientos de gigabytes contiguos en memoria sin que el garbage collector te dé un infarto cada dos por tres. En Python, aunque uses Dask o Zarr, al final estás peleándote con fragmentación, con referencias y con un overhead que en simulaciones que duran meses se traduce en semanas perdidas.

No es sorprendente que sea así. El Fortran está optimizado para aplicaciones científicas e ingenieriles porque fue creado por y para científicos e ingenieros. No es un lenguaje que luego se adaptó a la ciencia; nació ahí. Las operaciones matemáticas son de primera clase, no un añadido de biblioteca. El manejo de arrays no es algo nuevo, es excelente desde 1957. En Fortran los arrays tienen forma, rango y tamaño conocido en tiempo de compilación. Puedes hacer A = B + C * sin(D) en una sola línea y el compilador genera código vectorial perfecto. En Python eso genera temporales, copia de datos y el llenado del caché L3 (lo más rápido que tienes) con basura. En Fortran, si declaras todo bien, solo necesitas hacer una pasada por memoria. Además, desde Fortran 2008 tienes coarrays nativos, que son una maravilla para paralelismo distribuido sencillo. Y para el paralelismo más complejo dispones de OpenMP con directivas que funcionan de verdad y un MPI que lleva treinta años madurando con las mismas llamadas que usabas en los Cray de los noventa. Todo sigue funcionando.

Algo muy importante es que un lenguaje maduro y estable con bibliotecas inmensas para la física y las matemáticas (y por lo tanto, para las ingenierías): LAPACK, BLAS, FFTW (que tiene binding perfecto), IMSL, NAG. Aquí encontramos décadas de código depurado, probado en supercomputadoras y validado hasta la extenuación, no ocurrencias de anteayer que luego vemos que eran una mala idea por la razón más tonta del mundo y que resultan difíciles de tracear.

Hay ciertas aplicaciones, como el estudio del cambio climático, en las que la confianza en el resultado es tan importante como el resultado mismo. Afortunadamente, el ecosistema de Fortran es sólido, mucho más que la jeta de algunos periodistas. Las optimizaciones del compilador te dejan con la boca abierta: Intel oneAPI, NVIDIA HPC SDK, AOCC, Flang; todos los fabricantes de chips se pelean por sacarle el máximo jugo al Fortran porque saben que ahí está el dinero gordo de la supercomputación. Este lenguaje tiene, además, una portabilidad casi absoluta: el mismo código fuente compila y corre igual de rápido en un Mac con Apple Silicon, en un cluster AMD Epyc, en un supercomputador con procesadores Fujitsu A64FX o en IBM Power. Sin tocar una línea. Tengo código de 1998, escrito en Fortran 66, que compila hoy con gfortran -std=legacy y que corre más rápido que nunca en un procesador moderno. Intenta eso con Python. Fortran tiene, por si fuera poco, un overhead cero en tiempo de ejecución: no hay intérprete, no hay JIT que te caliente los nodos, no hay recolector de basura que te pare el modelo tres horas porque decidió hacer una limpieza general justo cuando una dana se estaba desarrollando sobre la Comunidad Valenciana. Python es ideal para hacer dibujos chulos (yo lo uso constantemente para eso), pero para hacer las cuentas de verdad en aplicaciones en las que hay vidas en juego, Fortran.

Fortran es fácil de aprender. Lejos de ser esotérico (como el COBOL), uno se hace con él en poco tiempo. En una semana, si eres listo y trabajador. Y sirve como puerta de entrada a lenguajes más específicos. De hecho, cuando aprendías Fortran lo normal era aprender también C o C++ con el libro clásico, el de Kernighan y Ritchie. No era raro llegar a la carrera sabiendo programar, y, de hecho, muchos de mis compañeros en primero de Matemáticas ya conocían esos lenguajes cuando los tuvimos que estudiar para la asignatura de Informática. En la carrera de Física el Fortran se estudiaba como primera opción seria de programación numérica, pero las cosas han cambiado, y hoy algunos planes de estudio lo orillan, o lo dejan para cursos de posgrado. Incluso cuando uno mismo diseña el plan de estudios de Física y pone Fortran en letras mayúsculas en la memoria de verificación, luego vienen los informáticos y enseñan lo que les da la gana.

El COBOL, por cierto, tiene su propia leyenda urbana que dice que, como es el lenguaje en el que están muchos de los registros de los bancos, los programadores de COBOL jubilados son los únicos que pueden tocar ciertos sistemas críticos y cobran a precio de oro la hora de trabajo. Creo que es un mito, pero informáticos tiene la Jot Down que sabrán responder, como dijeron en el Concilio de Trento.

Hay otra frase famosa que viene al caso, esta de Edsger W. Dijkstra (aunque la cita exacta varía y algunos la atribuyen a otros). Dice, más o menos: «No sé cuál será el lenguaje de programación del futuro, pero seguro que se llamará Fortran». De momento, y al menos en la física de la Tierra, la cosa va por ahí. Si tu trabajo consiste en mover miles de millones de números flotantes durante semanas seguidas para saber si lloverá más o menos a mediados de siglo, o si el casquete polar se va al carajo, sigues necesitando Fortran o teniendo una gran ventaja si lo dominas. Todo lo demás es un juguete muy bonito, pero un juguete al fin y al cabo. Cuando algún estudiante me dice «profesor, ¿y por qué no lo reescribimos todo en Julia?», yo solo sonrío, le paso un listado de 80000 líneas de Fortran 90 que lleva corriendo sin un solo crash desde 2003, y le pregunto: «¿Cuánto tiempo tienes, exactamente?».

Otra cosa es que ahora ya no sea tan necesario saber programar, porque le puedes decir a una IA que te cree una pieza del código que necesitas y ya está. Bueno, es una opción. Yo no la recomiendo, pero ahí está. Mis estudiantes más recientes es lo que hacen nada más llegar: intentar venderme gato por liebre, como si no supiera más el diablo por viejo que por diablo, o como si a estas alturas no se hubieran pasado ya todas las trampas del libro y todas las pantallas. Es un error. Conseguirás un código que funciona y seguramente óptimo, pero si no dominas una lengua, no podrás pensar en ella y no podrás innovar. Te condenas a ser un copión. No pasa nada, se han sacado muchas cátedras universitarias siendo un mero epígono y publicando artículos endebles en MDPI, o yendo de vigésimo autor de una lista de veintidós, pero no se puede pretender escribir como Shakespeare o Cervantes —innovando a cada línea— si tu inglés o tu español se limita a traducir párrafos con una IA. Ese camino es rápido, pero no conduce a los verdes valles de la creatividad, sino a la tierra baldía de la imitación.