Hasta el final del verano del 69 mi objetivo era ser ingeniero mecánico con la ilusión de poder diseñar motores y, obviamente, otros «mecanismos frutos del ingenio» pero en el segundo año de la carrera en la UTN (Universidad Tecnológica Nacional) de Buenos Aires había una asignatura en el plan de estudios, de flamante incorporación y que iba hacer cambiar mis objetivos: Computación digital. Para mis compañeros era simplemente un escollo más para superar: era aprender Fortran IV, hacer unas cuantas prácticas y un examen. No para mí; a partir de ese momento la computación, que en ese entonces aún no era informática, hizo que mi interés por la mecánica bajara varios peldaños. Por supuesto, jamás terminé la carrera de ingeniero mecánico y me pasé a una novísima y misteriosa carrera que se denominaba analista de sistemas. Y, pasadas más de cuatro décadas, no me arrepentí nunca.
Cabe reconocer que los primeros años fueron muy plácidos. El aprendizaje de Fortran IV era casi como transcribir fórmulas, de ahí su nombre, y tenía una docena de instrucciones para poder escribir funciones. Bibliotecas de funciones había, pero eran un manojo. En esa época la informática tenía otra velocidad… todo era muy estable, cada cambio o mejora en el lenguaje era todo un acontecimiento. Conservo aún el libro que me ayudó a aprender programación: Fortran IV de Daniel McCracken. Un fenómeno de ventas en una época en que casi no había competencia en el tema.
Fortran IV, de Daniel Mc Cracken (1967)
El Fortran era un lenguaje muy práctico para los ingenieros pero no me servía para hacer programas comerciales, que era donde había más posibilidades de trabajo. Así fue como, con otro libro de Daniel McCracken, aprendí Cobol: pero sólo por razones económicas. Tengo que reconocer que el Cobol nunca fue un lenguaje que gozara de mis preferencias, aunque para crear programas de aplicaciones ganaba ampliamente cuando se lo comparaba con el Fortran. Pero, un día, analizando una compilación de un programa Cobol en un sistema IBM/370, utilicé la opción DMAP y ante mis ojos apareció el despliegue de Assembler. Horrorizado comprobé que para un simple PERFORM VARYING de Cobol se necesitaban decenas de instrucciones de Assembler/370. En lugar de decir, como la mayoría: «Qué potente que es el PERFORM», dije: «¡Qué malgasto de procesador con este *** Cobol! Tengo que aprender Assembler para dominar lo que le hacemos hacer al sistema operativo.». Ese DMAP cambió mi modo de ver la computación: había que ir al detalle de las cosas.
Y así, tal como hacía de pequeño, cuando ya comenzaba a desarmar cosas para saber cómo las habían hecho – costumbre por la que pasé más de una situación incómoda- , al dedicarme a la programación no cambié.
Un tributo a aquellos años: ésta es una vista parcial de la prehistórica cartilla de instrucciones de Assembler IBM/360. En total eran doce páginas (se visualizan tres) y era un elemento imprescindible para programar.
System /360 Reference Summary
La cantidad de instrucciones, aunque considerable, era fácil de dominar; principalmente porque no existían muchas redundancias para hacer una determinada cosa.
