Como algunas veces he escrito, una cosa lleva a otra, que lleva a otra y a otra… hasta que uno finalmente para o ya no encuentra con qué más seguir. A pesar que desde un inicio uno encontró lo que inicialmente buscaba.

Así me pasó con un post (que aparecerá mucho después a la publicación de éste) en el que terminé relatando mi vivencia en torno a la programación orientada a objetos, aunque inicialmente ese post estaba destinado a la programación orientada a aspectos. Pensando en ambas cosas, consideré que lo  más adecuado o… ¿justo?… era escribir sobre los paradigmas de programación que he … usado y vivido. Quizás algunos piensen que sólo debí escribir «usado» (y si lo pensé, de ahí los puntos suspensivos) pero estos modelos se «viven», no simplemente se «usan» (y, a menos que sean programadores, difícilmente lo comprenderán, y no me refiero a algo enteramente profesional).

Para cuando inicié mis estudios de licenciatura, a mediados de la década de los 80, ya había muchos paradigmas de programación, como así había ya muchos cientos de lenguajes de programación. El cómputo casero apenas iniciaba en México pero, fuera de las computadoras que se consideraban de juguete, como las Commodore, Atari o Sinclair, era algo que se equiparaba a tener un auto¹.

A través de los diferentes cursos del plan de estudio supimos (y aprendimos algunos de ellos) Fortran, APL, Modula, LISP, Prolog, Forth, ensamblador (para la legendaria PDP 11 y para el Intel 8088/8086), Dynamo, BASIC (BASIC 3000, GW BASIC, Basica), Pascal, COBOL y  C, realmente los tres últimos los que en aquel entonces se demandaban en el campo laboral. Particularmente en el entorno laboral alrededor de las PC, era BASIC y Pascal lo más demandado. Algunos de nosotros ya laborando nos toparíamos con cosas como Culprit,  Clarion, REXX, DCL, JCL, SQL, shells de Unix, Clipper, DBase, etcétera. Algunos otros se toparían con RPG, FoxBase y cosas peores.

Cuando ya estábamos en los últimos semestres de la licenciatura, la computación personal estaba ya abriéndose paso a pasos agigantados (pero no dejaba de ser cara). El IPN había iniciado un programa de autoequipamiento desarrollando su propio equipo, la IPN/e16 y la IPN/e32, que muchos criticaron porque ya para entonces IBM anunciaba la muerte de la PC y esta introduciendo sus «sistemas personales»: los PS/2 (con ese «2» que remarcaba que se trataba de algo que era posterior o superior a cualquier cosa que hubiera habido antes) e introduciendo «novedosamente» los discos de 3.5″ de 720KB (aunque claro, los equipos Macintosh ya lo hubieran hecho algunos años antes, y dando 80 KB de espacio adicional en su formateo para un total de 800KB). Con todo los equipos del IPN dieron batalla a muchas generaciones de estudiantes pero al ser una institución educativa no se dio abasto con la demanda de producción y mantenimiento y algunos años después de abandonó este proyecto, dejando a IBM ser uno de los primeros proveedores de equipos de cómputo. Por esas fechas la SEP también intentó algo similar, terminando en un verdadero fracaso al producir equipos que resultaban incluso de menores prestaciones a una Commodore. Todo un escándalo que fue ese asunto.

En fin, regresando  a los paradigmas de programación, ya  en los últimos semestres de la licenciatura, nuestras pláticas y debates eran sobre las novedades de cómputo y cosas. Que si DBase era un lenguaje o un paquete, si era un manejador de archivos o una manejador de bases de datos; si Clipper era un lenguaje o meramente un compilador de DBase; si descompilar o desensamblar era lo mismo y si era posible uno o ambos (algo similar ocurría con el RDBMS SQL/DS).

Mencioné con anterioridad a Culprit, que ahora identifico como parte de un «reporteador» que era distribuido por Cullinet. Aquel fue uno de mis primeras frustraciones profesionales, muchas horas de pruebas y muchas más rastreando errores, sin aprender realmente cómo funcionaba. Vendrían después muchas más experiencias similares.

No fue hasta que empecé a dar clases en la maestría, impartiendo la cátedra de «Diseño de Compiladores» que profundicé en el estudio de paradigmas de programación, no de lenguajes, viendo que el enfoque correcto de la verdadera explotación de las herramientas de programación no reside en el aprendizaje del lenguaje con el que se trabaja sino en el paradigma del que proviene. «Entiende al paradigma y rápidamente aprenderás a programar con cualquier lenguaje que pertenezca a esta familia, » fue la lección aprendida.

La Wikipedia tiene un buen artículo (aunque no exhaustivo) para iniciarse en el tema.

————————–

1. De hecho, muchos distribuidores de equipo PC en aquel entonces, pedían la factura de un auto en garantía para los planes de crédito que ofrecían.