¿Qué es un perform?
El artículo anterior lo cerré diciendo que programar era controlar el flujo. Me quedé con las ganas de contar dónde aprendí eso. No lo aprendí en un libro. Lo aprendí perdido.
Empecé como empezábamos todos: modificando programas que habían escrito otros. Nadie te sentaba a escribir uno desde cero el primer día; te daban el de un compañero y te decían «que ahora saque también esta columna». Y ahí empezaba el via crucis.
Porque el lenguaje era COBOL, y conviene decir una cosa sobre COBOL para quien no lo haya tocado: COBOL no es un lenguaje estructurado. Ni tipado, en el sentido de hoy. Ni orientado a objetos, faltaría más. COBOL es un lenguaje, y punto. Te deja saltar de cualquier sitio a cualquier sitio. Y lo que salía de ahí, la mayoría de las veces, era lo que hoy llamamos código espagueti: líneas y líneas que iban hacia adelante, hacia atrás, y volvían a un punto que ya no recordabas por qué existía.
No lo cuento con prepotencia. Ni con suficiencia, ni siquiera con nostalgia — aunque recuerde con mucho cariño a todos los compañeros con los que compartí aquellas máquinas. Ellos programaban como se programaba entonces, como me enseñaron a mí también. Simplemente era así: te perdías. Yo me pasaba días intentando corregir programas que, con toda honestidad, no entendía. Me perdía entre sus líneas. Buscaba dónde se calculaba un total, y el total aparecía tocado en cuatro sitios distintos.
Y entonces encontré una instrucción. Una sola. Se llamaba PERFORM.
PERFORM — y su hermano PERFORM THRU — te dejaba hacer algo que parece de tontos y lo cambió todo: meter un trozo de programa en un «párrafo» con nombre, llamarlo, y volver solo al punto exacto desde donde lo habías llamado. Ir y volver. Sin perderte.
Parece poco. Fue enorme. Por primera vez podía escribir el cuerpo de un programa y leerlo como se lee una frase:
perform cabecera
perform lineas
perform pie
exit.Y ya está. Ahí estaba el programa entero, a la vista. El flujo, visible. Cualquiera que leyera esas cuatro líneas sabía qué hacía el listado sin entender todavía cómo. El cómo venía después, y venía por su lado: ahora me siento a escribir la cabecera. Luego las líneas. Luego el pie. Y dentro de la cabecera busco los datos; y dentro de buscar los datos, abro el fichero. Cada cosa en su párrafo, cada párrafo con su nombre, cada nombre contando qué hace. El programa había dejado de ser un plato de espagueti para ser un índice.
Lo malo — siempre hay un malo — era el precio. Aquello significaba reescribir los programas enteros de otra manera. Y no cundía. Tardaba más en dejar ordenado lo que ya funcionaba desordenado que en sacar la columna que me habían pedido. Durante un tiempo trabajé el doble.
Hasta que dejó de ser el doble. Porque cuando tuve unos cuantos escritos así, me di cuenta de una cosa: el programa siguiente era el mismo. Otra cabecera, otras líneas, otro pie — pero la forma, idéntica. Y solo tenía que reescribir lo que cambiaba.
Y ahí llegó la segunda magia, todavía mayor que la primera: las funciones.
Una función es un perform que ha ido a la escuela. No solo va y vuelve: se lleva algo de la mano y trae algo de vuelta. Le dices «escríbeme la cabecera, de veinte de alto y treinta de ancho», y te devuelve la cabecera hecha — hoy, en mi oficio, el HTML de esa cabecera; entonces, lo que tocara imprimir. Le pasas valores, te devuelve un resultado. El párrafo con nombre se había convertido en una pieza con enchufes. Y con eso el control del flujo se volvió total: lo mismo, con distintas medidas, sin reescribir nada.
Aquí es donde debería aparecer alguien a recordarme que para eso están las clases. Y lleva media razón. Las clases están muy bien — las hacen otros, y te ahorran un tiempo enorme. Pero yo casi no las uso. Y no es una pose de viejo: no quiero supeditar mi aplicación a lo que otro decide, y cambia cuando le viene en gana.
Porque una clase, para mí, es una función en la que pierdes la pista del flujo. La llamas creyendo que va a hacer una cosa, y hace lo que tengan sus variables por dentro en ese momento — que no siempre es lo que tú crees. Le pides que sume; suma, o no, según cómo estén colocadas media docena de variables que ni ves. Claro que no todas las clases son iguales, ni la mitad son tan opacas como las pinto. Pero nunca terminé de entenderlas del todo, y creo saber por qué: nunca me fié de ellas.
Y si encima les añades namespaces, ya me pierdo del todo: Pepe no es Pepe, es Pepe del namespace de Juan, no confundir con Pepe del namespace de Raúl. En fin.
Así que llegaron las clases y yo seguí con mis funciones. De los objetos ni hablo — esos no los usé nunca. Seguramente por no tener un rato siquiera para asomarme a ellos: cuando vas siempre hasta arriba de trabajo pendiente, no te sobra tiempo para invertir en algo a lo que, mirándolo por encima, tampoco le acabas de ver la utilidad. Para un equipo grande de programadores seguro que la tiene. Para un programador solitario como yo, nunca se la quise encontrar.
Y me quedé — o mejor dicho, nunca me fui — con lo de siempre. Porque una función hace exactamente lo que aquel PERFORM que descubrí de joven: recibe, hace, devuelve, y te suelta justo donde estabas. Lo que entra se ve. Lo que sale se ve. El flujo, otra vez, visible.
No tengo nada contra las clases. Tengo algo a favor de poder leer un programa como se lee una frase. A los sesenta y cuatro años, después de todo lo que he visto pasar, mi programa favorito sigue siendo aquel:
perform cabecera
perform lineas
perform pie
exit.Solo que ahora las cabeceras las teje una IA. Y aquí está lo que no esperaba: a la IA le gustan mis funciones. Las entiende a la primera, las mejora, y cuando le toca escribir una nueva la hace con la misma lógica con la que la habría hecho yo. Mis programas cambian —los toca ella, no yo—, pero sigo entendiendo el código aunque casi ni lo lea. Sé lo que voy a encontrar antes de abrir el fichero.
Y eso no es casualidad. En el telar hay unas cuantas normas de programación escritas para que se programe como a mí me gusta, no como la IA decida en cada momento. Funciones, no clases. Un if honrado, no un ternario que hay que descifrar a la fuerza. Cosas de programador viejo — que a lo mejor solo me gustan y solo me funcionan a mí. Pero es mi aplicación, y quien tiene que entenderla soy yo.
El perform lo sigo poniendo yo.
— un viejo programador · 64 años · rss